По умолчанию бэкенд — MySQL-кластер
Бэкенд MySQL-кластера:
Как HTTP/HTTPS-балансировщик нагрузки
Фронтенд веб-балансировщика нагрузки:
Бэкенд приложений:
В качестве HTTP-кэширующего сервера
Глобальные настройки:
Фронтенд FE:
Бэкенд BE:
В роли RESTful NoSQL-кэширующего сервера
Глобальные настройки:
Фронтенд FE:
Бэкенд BE:
Директива
Глобальная настройка: менеджер Nuster.
Синтаксис:
Менеджер/API статистики очистки включается для определения URI и метода purge. По умолчанию отключён, при включении необходимо ограничить доступ (см. раздел «Как ограничить доступ»).
Подробности в разделе «Управление».
URI: определение URI, значение по умолчанию /nuster.
Purge-метод: определение HTTP-метода. Значение по умолчанию PURGE.
Глобальное включение: Nuster cache|nosql.
Синтаксис:
Значение по умолчанию: нет. Контекст: глобальный.
Определяет, будет ли использоваться кэш или NoSQL.
Данные HTTP и ключи сохраняются в общей памяти размером data-size + dict-size. Если памяти недостаточно, новые запросы не кэшируются. Временные данные запрашиваются из пула памяти.
Data-size: определяет размер совместно используемой памяти вместе с dict-size.
Единицы измерения m, M, g и G. Значение по умолчанию 1 мегабайт, минимальное значение также 1 мегабайт.
Dict-size: определяет размер хеш-таблицы.
Единицы измерения m, M, g и G. Значение по умолчанию 1 мегабайт, минимальное значение также 1 мегабайт. Это не количество ключей, а размер сегментов. Ключи находятся в общей памяти.
Количество сегментов (dict-size) может превышать количество ключей, но если количество ключей превышает dict-size, производительность может снизиться. Рекомендуется, чтобы dict-size был примерно равен 8 * максимальному количеству ключей.
В API статистики:
dict.nosql.length: 131072
dict.nosql.used: 0
Если значение dict.nosql.used больше dict.nosql.length, рекомендуется увеличить dict-size.
В будущих версиях dict-size может быть удалён, и будет возвращена первоначальная функция автоматического изменения размера.
Dir: устанавливает корневой каталог для сохранения состояния. Требуется для сохранения состояния.
С chroot: фактическое местоположение сохранения — chroot + dir. Например:
chroot /data
nuster cache on dir /cache
Фактическое местоположение кэша: /data/cache.
Dict-cleaner: проверяет максимум dict-cleaner записей за один раз и удаляет недействительные записи (по умолчанию 1000).
Data-cleaner: проверяет максимум data-cleaner данных за один раз и удаляет недопустимые данные (по умолчанию 1000).
Рекомендуется не изменять это значение, так как удаление ускоряется, когда недействительных данных становится более 20 %.
Disk-cleaner: проверяет максимум disk-cleaner файлов за один раз и удаляет недействительные файлы (по умолчанию 100).
Disk-loader: после запуска проверяет максимум disk-loader файлов за один раз и загружает информацию (по умолчанию 100).
Для USE_THREAD: загружается одним потоком, этот параметр игнорируется.
Disk-saver: проверяет максимум disk-saver данных за один раз и сохраняет необходимые данные на диск (по умолчанию 100).
Подробнее в разделе Store.
Clean-temp on|off: автоматически генерирует временный каталог .tmp в определённом каталоге dir.
Решает, удалять ли временные файлы при запуске. Значение по умолчанию off.
Always-check-disk on|off: всегда проверять дисковый кэш. Особенно полезно, если диск используется несколькими экземплярами и кэш может быть повреждён. Значение по умолчанию off.
Прокси: Nuster cache|nosql.
Синтаксис:
Значение по умолчанию: включено. Контекст: бэкенд.
Включает или отключает кэш/NoSQL. Другие фильтры ставятся последними.
Прокси: правило Nuster.
Синтаксис:
Значение по умолчанию: отсутствует. Контекст: бэкенд.
Устанавливает условия для включения кэша/NoSQL, требуется хотя бы одно условие.
Пример:
nuster cache on
# Кэшировать запрос `/asdf` на 30 секунд
nuster rule asdf ttl 30 if { path /asdf }
# Кэширование, если путь запроса
``` **begins with /img/**
nuster rule img if { path_beg /img/ }
# cache if the response header `cache` is `yes`
acl resHdrCache res.hdr(cache) yes
nuster rule r1 if resHdrCache
複数のruleを定義できる、定義順序で実行する。
acl pathA path /a.html
nuster cache on
nuster rule all ttl 3600
nuster rule path01 ttl 60 if pathA
rule allはすべてをマッチングするので、rule path01
は実行しない。
このruleのnameを定義する。v5以降はグローバルユニーク。
cache/nosqlのkeyを定義する。下記のkeywordと.
との組み合わせ。
NAME
NAME
NAME
CACHEのディフォルトkeyは method.scheme.host.uri
で, NoSQLのディフォルトkeyはGET.scheme.host.uri
.
Example
GET http://www.example.com/q?name=X&type=Y
http header:
GET /q?name=X&type=Y HTTP/1.1
Host: www.example.com
ASDF: Z
Cookie: logged_in=yes; user=nuster;
下記を生成する:
ディフォルトkeyはGET\0http.www.example.com\0/q?name=X&type=Y\0
で key method.scheme.host.path.header_ASDF.cookie_user.param_type
は GET\0http.www.example.com\0/q\0Z\0nuster\0Y\0
.
\0
はNULLキャラクター リクエストのkeyが同じなら、キャッシュを返す。
生存期限を定義する。単位は d
, h
, m
とs
で、 ディフォルトは0
秒。
0
の場合は失効しない。
auto
を使う場合、 ttl は自動的にcache-control
headerのs-maxage
か max-age
の値に設定する。
cache-control
の他のディレクティブは処理してない。 ttlのMaxは2147483647
extend
でttlを自動的に延長できる。
自動的にttlを延長する。
extend on|off|n1,n2,n3,n4
ディフォルト: off.
n1,n2,n3,n4: 100未満の整数, n1 + n2 + n3も100未満. 4つの時間帯を定義する:
time: 0 ttl ttl * (1 + n4%)
access: | A1 | A2 | A3 | A4 | |
percentage: |<- (100 - n1 - n2 - n3)% ->|<- n1% ->|<- n2% ->|<- n3% ->|<- n4% ->|
下記満たさればttlは自動的に延長する:
ttl
と ttl * (1 + n4%)
の間に新たなリクエストが発生
on
は 33,33,33,33
同時に来た同じなリクエストがキャッシュ完成するのを待つかどうか。 wait on
はキャッシュ完成するまでまつ、 wait TIME
はTIME秒待ってからバックエンドにフォーワードする。
ディフォルトは待たずに全部バックエンドにフォーワードする(wait off
)。
最初のリクエストが初期化をするまで他の同じなリクエストが来た場合は待たずにフォーвордする。
Nosqlモードではwaitしない。順番に処理して最後のリクエストの内容を保存する。 最大値:2147483647.
キャッシュが更新されているときや、バックエンドのサーバーダウンで更新失敗した時に、失効済みのキャッシュを使うかどうかを決める。
use-stale on
: キャッシュが更新されている時、失効済みのキャッシュを使う。
use-stale off
(ディフォルト): wait off
の場合、同じなリクエストがバックエンドにフォーワードする, wait on|TIME
の場合は待つ。
use-stale TIME
: バックエンドのサーバーダウンで更新失敗した時に、失効済みのキャッシュをTIME秒間を使う。
最大値:2147483647.
指定した期間を過ぎてアクセスがない場合キャッシュが削除される。ディフォルトはoff(0)。 TIMEを過ぎると必ず削除されるというわけではない、cleanプロセスが先にcacheをアクセスする場合、削除されるけど、新しいリクエストが先に来る場合、キャッシュの最終アクセス時間が更新されキャッシュは削除されない。ディスクファイルの場合はファイルのアクセス時間使ってないため、nusterが再起動すると、最終アクセス時間はロード時間に設定する。 最大値:2147483647.
ディフォルトは200のリスポンスしかキャッシュしない、ほかのものをキャッシュしたい場合は
定義する。 all
の場合は全てキャッシュする。
cache-rule only200
cache-rule 200and404 code 200,404
cache-rule all code all
メモリに保存するかどうか、ディフォルトon 詳細はStore
ディスクに保存するかどうやって保存するか、ディフォルトoff
disk sync
を使うにはmemory on
を設定する必要がある。
詳細はStore
etag条件付きリクエストの処理、 ETag
なければ、追加する.
ディフォルトoff.
last-modified条件付きリクエストの処理、 Last-Modified
なければ、追加する.
ディフォルトoff.
HAProxy ACLを使う。 ACLはリクエストとリスポンスの二段階で評価する 下記満たせばキャッシュする:
Например:
Кэшировать запросы, начинающиеся с /img/
nuster rule img if { path_beg /img/ }
На этапе запроса, если ACL равен true, то кэшируем, иначе (false) — на этапе ответа не кэшируем из-за отсутствия пути.
Кэшировать ответы с Content-Type
равным image/jpeg
nuster rule jpeg if { res.hdr(Content-Type) image/jpeg }
Так как на этапе запроса нет res.hdr, то значение равно false. На этапе ответа значение может быть как true, так и false.
Не работает следующее правило:
nuster rule img if { path_beg /img/ } { res.hdr(Content-Type) image/jpeg }
Значение равно false на этапе запроса из-за отсутствия res.hdr и равно false на этапе ответа из-за отсутствия пути, поэтому ACL также равен false.
Работает следующее правило:
http-request set-var(txn.pathImg) path
acl pathImg var(txn.pathImg) -m beg /img/
acl resHdrCT res.hdr(Content-type) image/jpeg
nuster rule r3 if pathImg resHdrCT
Или nuster.path (v5):
nuster rule r3 if { nuster.path -m beg /img } { res.hdr(Content-Type) image/jpeg }
/api/
Не работает следующее правило:
acl NoCache path_beg /api/
nuster rule r3 if !NoCache
На этапе ответа отсутствует путь, поэтому NoCache равен false, а !NoCache всегда равен true. В результате все запросы кэшируются.
Следующее правило работает корректно:
http-request set-var(txn.path) path
acl NoCache var(txn.path) -m beg /api/
nuster rule r1 if !NoCache
7. Использование ACLs и получение образцов
Раздел в конфигурации HAProxy также рекомендуется к изучению.
Nuster можно использовать как кэш-сервер, который динамически или статически кэширует HTTP-контент, подобно Varnish или Nginx.
Помимо функций SSL, HTTP, HTTP2, перезаписи и перенаправления, HAProxy предлагает следующие возможности:
global
nuster cache on data-size 200m
frontend fe
bind *:8080
default_backend be
backend be
nuster cache on
nuster rule r1 if { path /a1 }
nuster rule r2 key method.scheme.host.path.delimiter.query.cookie_userId if { path /a2 }
nuster rule r3 ttl 10 if { path /a3 }
nuster rule r4 disk on if { path /a4 }
server s1 127.0.0.1:8081
Правила проверяются по порядку, сначала создаётся ключ для поиска. Если ключ найден, возвращается кэш. Если нет, проверяется ACL, и если он пройден, то возвращается ответ от бэкэнда.
Nuster также можно использовать в качестве RESTful NoSQL кэш-сервера, где можно регистрировать, получать и удалять ключи и значения через HTTP POST/GET/DELETE.
curl -v -X POST -d value1 http://127.0.0.1:8080/key1
curl -v -X POST --data-binary @icon.jpg http://127.0.0.1:8080/imgs/icon.jpg
curl -v http://127.0.0.1:8080/key1
curl -v -X DELETE http://127.0.0.1:8080/key1
Проверьте код состояния.
Заголовки, поддерживаемые в запросе:
Имя | значение | описание |
---|---|---|
content-type | любое | будет возвращено как есть в GET-запросе |
cache-control |
s-maxage или max-age
|
используется для установки ttl, когда rule.ttl равен auto
|
Используя заголовки или cookie, можно сохранить данные для каждого пользователя в одном и том же endpoint.
nuster rule r1 key method.scheme.host.uri.header_userId if { path /mypoint }
nuster rule r2 key method.scheme.host.uri.cookie_sessionId if { path /mydata }
curl -v -X POST -d "333" -H "userId: 1000" http://127.0.0.1:8080/mypoint
curl -v -X POST -d "555" -H "userId: 1001" http://127.0.0.1:8080/mypoint
curl -v -X POST -d "userA data" --cookie "sessionId=ijsf023xe" http://127.0.0.1:8080/mydata
curl -v -X POST -d "userB data" --cookie "sessionId=rosre329x" http://127.0.0.1:8080/mydata
curl -v http://127.0.0.1:8080/mypoint
< 404 Not Found
curl -v -H "userId: 1000" http://127.0.0.1:8080/mypoint
< 200 OK
333
curl -v --cookie "sessionId=ijsf023xe" http://127.0.0.1:8080/mydata
< 200 OK
userA data
Можно использовать любой HTTP-инструмент или библиотеку, которые могут делать запросы: curl
, postman
, python requests
, go net/http
и др.
Управлять Nuster можно во время выполнения через API. Определяя URI, можно управлять этим URI, отправляя HTTP-запросы.
Определение
nuster manager on uri /internal/nuster purge-method PURGEX
METHOD | Endpoint | описание |
---|---|---|
GET | /internal/nuster | получить статистику |
POST | Статистика |
Использование
curl http://127.0.0.1/nuster
Вывод
**NUSTER**
nuster.cache: on
nuster.nosql: on
nuster.manager: on
**MANAGER**
manager.uri: /nuster
manager.purge_method: PURGE
**DICT**
dict.cache.size: 1048576
dict.cache.length: 131072
dict.cache.used: 0
dict.cache.cleanup_idx: 0
dict.cache.sync_idx: 0
dict.nosql.size: 1048576
dict.nosql.length: 131072
dict.nosql.used: 0
dict.nosql.cleanup_idx: 0
dict.nosql.sync_idx: 0
**STORE MEMORY**
store.memory.cache.size: 2098200576
store.memory.cache.used: 1048960
store.memory.cache.count: 0
store.memory.nosql.size: 11534336
store.memory.nosql.used: 1048960
store.memory.nosql.count: 0
**STORE DISK**
store.disk.cache.dir: /tmp/nuster/cache
store.disk.cache.loaded: yes
store.disk.nosql.dir: /tmp/nuster/nosql
store.disk.nosql.loaded: yes
**STATS**
stats.cache.total: 0
stats.cache.hit: 0
stats.cache.fetch: 0
stats.cache.bypass: 0
stats.cache.abort: 0
stats.cache.bytes: 0
stats.nosql.total: 0
stats.nosql.get: 0
stats.nosql.post: 0
stats.nosql.delete: 0
**PROXY cache app1**
app1.rule.rule1: state=on memory=on disk=off ttl=10
app1.rule.rule2: state=on memory=on disk=on ttl=10
app1.rule.rule3: state=on memory=on disk=sync ttl=10
app1.rule.rule4: state=on memory=off disk=on ttl=10
app1.rule.rule5: state=on memory=off disk=off ttl=10
**PROXY nosql app2**
app2.rule.ruleA: state=on memory=on disk=off ttl=10
app2.rule.ruleB: state=on memory=on disk=on ttl=10
app2.rule.ruleC: state=on memory=on disk=sync ttl=10
app2.rule.ruleD: state=on memory=off disk=on ttl=10
app2.rule.ruleE: state=on memory=off disk=off ttl=10
Заголовки
Заголовок | Значение | Описание |
---|---|---|
state | enable | Включить |
disable | Отключить | |
name | rule NAME | Включить или отключить правило с именем NAME |
proxy NAME | Включить или отключить все правила для прокси с именем NAME | |
* | Включить или отключить все правила |
Примеры
Отключить правило r1
curl -X POST -H "name: r1" -H "state: disable" http://127.0.0.1/nuster
Отключить все правила прокси app1b
curl -X POST -H "name: app1b" -H "state: disable" http://127.0.0.1/nuster
Включить все правила
curl -X POST -H "name: *" -H "state: enable" http://127.0.0.1/nuster
Изменяет срок жизни (TTL) существующего кэша, не затрагивая существующий кэш.
Заголовки
Заголовок | Значение | Описание |
---|---|---|
ttl | new TTL | Новое значение TTL |
name | rule NAME | Изменить TTL для правила с именем NAME |
proxy NAME | Изменить TTL всех правил для прокси с именем NAME | |
* | Изменить TTL для всех правил |
Примеры
curl -X POST -H "name: r1" -H "ttl: 0" http://127.0.0.1/nuster
curl -X POST -H "name: r2" -H "ttl: 2h" http://127.0.0.1/nuster
curl -X POST -H "name: r1" -H "ttl: 0" -H "state: enabled" http://127.0.0.1/nuster
Существует два режима:
purge-method MYPURGE
на желаемый PATH для удаленияcurl -XPURGE http://127.0.0.1/imgs/test.jpg
Правило генерирует ключ, ищет кэш и удаляет его, если он найден. Только кэш, созданный с помощью GET, является действительным.
Обратите внимание на хост, например, для кэша http://example.com/test
, используйте:
curl -XPURGE -H "Host: example.com" http://127.0.0.1/test
Можно использовать как кэш, так и nosql. В случае nosql используется тот же метод, что и для DELETE.
Правила, прокси или *
можно использовать для удаления.
Заголовки
Заголовок | Значение | Описание |
---|---|---|
name | rule NAME | Правило |
В тексте запроса есть код на языке программирования YAML, который представляет собой конфигурацию приложения. Этот код не связан с запросом и не требует перевода. ###
[кэш|NoSQL] nuster.uri: строка
Аналогично HAProxycapture.req.uri
.
[Кэш|NoSQL] nuster.path: строка
Аналогично HAProxypath
, но может использоваться как для запроса, так и для ответа.
[Кэш|NoSQL] nuste.query: строка
Аналогично HAProxyquery
, но может использоваться как для запроса, так и для ответа.
Установите master-worker
в global
или запустите с -W
.
Запустите nuster
с параметром -d
.
Сообщения, связанные с nuster, содержат [nuster
.
Настройте option http-buffer-request
.
Используйте пользовательский ключ, содержащий body
.
Обратитесь к разделу option http-buffer-request в конфигурации HAProxy, так как тело POST может быть неполным.
Возможно, лучше создать отдельный бэкенд для POST.
acl network_allowed src 127.0.0.1
acl purge_method method PURGE
http-request deny if purge_method !network_allowed
bind :443 ssl crt pub.pem alpn h2,http/1.1
global
nuster manager on uri /_/nuster purge-method MYPURGE
nuster cache on data-size 100m
nuster nosql on data-size 100m
# daemon
defaults
retries 3
option redispatch
timeout client 30s
timeout connect 30s
timeout server 30s
frontend web1
bind *:8080
mode http
acl pathPost path /search
use_backend app1a if pathPost
default_backend app1b
backend app1a
balance roundrobin
# mode must be http
mode http
# http-buffer-request must be enabled to cache post request
option http-buffer-request
acl pathPost path /search
# enable cache for this proxy
nuster cache
# cache /search for 120 seconds. Only works when POST/PUT
nuster rule rpost key method.scheme.host.uri.body ttl 120 if pathPost
server s1 10.0.0.10:8080
backend app1b
balance roundrobin
mode http
nuster cache on
# cache /a.jpg, not expire
acl pathA path /a.jpg
nuster rule r1 ttl 0 if pathA
# cache /mypage, key contains cookie[userId], so it will be cached per user
acl pathB path /mypage
nuste rule r2 key method.scheme.host.path.delimiter.query.cookie_userId ttl 60 if pathB
# cache /a.html if response's header[cache] is yes
http-request set-var(txn.pathC) path
acl pathC var(txn.pathC) -m str /a.html
acl resHdrCache1 res.hdr(cache) yes
nuster rule r3 if pathC resHdrCache1
# cache /heavy for 100 seconds if be_conn greater than 10
acl heavypage path /heavy
acl tooFast be_conn ge 100
nuster rule heavy ttl 100 if heavypage tooFast
# cache all if response's header[asdf] is fdsa
acl resHdrCache2 res.hdr(asdf) fdsa
nuster rule resCache ttl 0 if resHdrCache1
server s1 10.0.0.10:8080
frontend web2
bind *:8081
mode http
default_backend app2
backend app2
balance roundrobin
mode http
# disable cache on this proxy
nuster cache off
nuster rule all
server s2 10.0.0.11:8080
frontend nosql_fe
bind *:9090
default_backend nosql_be
backend nosql_be
nuster nosql on
nuster rule r1 ttl 3600
Copyright (C) 2017-present, Jiang Wenyuan, < koubunen AT gmail DOT com >
Все права защищены.
Лицензия GPL, такая же, как у HAProxy.
Уведомления об авторских правах HAProxy и других источников: смотрите соответствующие отдельные файлы.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )