Слияние кода завершено, страница обновится автоматически
Высокопроизводительный HTTP-кэш-сервер и RESTful NoSQL-сервер.
Nuster был разработан на основе HAProxy и может использоваться в качестве:
Особенности:
HAProxy-подобный HTTP/TCP балансировщик нагрузки:
Динамический и статический HTTP-кеширующий сервер:
RESTful NoSQL кеш-сервер:
Тесты показали, что nuster работает в 3 раза быстрее nginx на одном ядре и в 2 раза быстрее varnish на нескольких ядрах.
Более подробную информацию о тестах производительности можно найти в разделе «Benchmark».
Для начала работы с nuster необходимо выполнить следующие шаги:
Также можно использовать Docker для запуска nuster.
Nuster основан на HAProxy, поэтому он поддерживает все его функции. Основные разделы конфигурации включают global, defaults, frontend и backend.
В разделе global устанавливаются глобальные параметры. В разделе defaults задаются значения по умолчанию для других разделов. Раздел frontend определяет сторону, которая принимает запросы от клиентов, а backend — сторону, которая распределяет полученные запросы на серверы.
Важно отметить, что для использования функций кэширования и NoSQL необходимо включить соответствующие настройки в разделах backend. Также необходимо определить правила кэширования с помощью nuster rule. По умолчанию бэкенд — MySQL-кластер
Бэкенд MySQL-кластера:
Как HTTP/HTTPS-балансировщик нагрузки
Фронтенд web-lb:
Бэкенд apps:
Как кэш-сервер HTTP
Глобальный:
Фронтенд fe:
Бэкенд be:
Как RESTful NoSQL кэш-сервер
Глобальный:
Фронтенд fe:
Бэкенд be:
Директивы
Глобальная: менеджер nuster
Синтаксис: nuster manager on|off [uri URI] [purge-method method].
По умолчанию: off.
Контекст: глобальный.
Менеджер/API статистики очистки включается для определения URI и метода purge.
По умолчанию отключено, при включении необходимо ограничить доступ (см. раздел «Как ограничить доступ»).
Подробности в разделе «Управление».
URI: определение URI. По умолчанию /nuster.
Purge-метод: определение HTTP-метода. По умолчанию PURGE.
Глобальное: nuster cache|nosql
Синтаксис: nuster cache on|off [data-size size] [dict-size size] [dir DIR] [dict-cleaner n] [data-cleaner n] [disk-cleaner n] [disk-loader n] [disk-saver n] [clean-temp on|off] [always-check-disk on|off]
nuster nosql on|off [data-size size] [dict-size size] [dir DIR] [dict-cleaner n] [data-cleaner n] [disk-cleaner n] [disk-loader n] [disk-saver n] [clean-temp on|off] [always-check-disk on|off].
По умолчанию: нет.
Контекст: глобальный.
Определяет, использовать ли cache или 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.
Решает, удалять ли временные файлы при запуске. По умолчанию выключено.
Always-check-disk on|off: всегда проверять дисковый кэш. Особенно полезно, если диск используется несколькими экземплярами и кэш может стать недействительным.
По умолчанию выключен.
Прокси: nuster cache|nosql
Синтаксис: nuster cache [on|off] nuster nosql [on|off].
По умолчанию: включено.
Контекст: бэкенд.
Включает или отключает cache/nosql. Другие фильтры должны быть последними.
Прокси: правило nuster
Синтаксис: nuster rule name [key KEY] [ttl auto|TTL] [extend EXTEND] [wait on|off|TIME] [use-stale on|off|TIME] [inactive off|TIME] [code CODE] [memory on|off] [disk on|off|sync] [etag on|off] [last-modified on|off] [if|unless condition].
По умолчанию: нет.
Контекст: бэкенд.
Устанавливает условия для включения кэша, требуется хотя бы одно условие.
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と.との組み合わせ。
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の場合は失効しない。
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未満. ４つの時間帯を定義する：
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, то кэшировать, иначе — на этапе ответа, если путь не существует, то ACL также равен false и кэширование не происходит.
Кэшировать ответы с Content-Type равным image/jpeg
nuster rule jpeg if { res.hdr(Content-Type) image/jpeg }
Так как на этапе запроса нет res.hdr, то значение равно false. На этапе ответа значение может быть true или false.
/img/, а ответ имеет Content-Type, равный image/jpeg, то кэшироватьПриведённый ниже код не работает корректно:
nuster rule img if { path_beg /img/ } { res.hdr(Content-Type) image/jpeg }
На этапе запроса 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
Новый способ получения образцов описан в разделе «Получение образцов» (Sample fetches).
Также рекомендуется ознакомиться с разделом «Использование ACLs и получение образцов» в документации по настройке HAProxy (HAProxy configuration doc/configuration.txt).
Кэширование
Nuster можно использовать как кэш-сервер для динамических и статических HTTP-контентов, подобно Varnish и Nginx. Помимо функций SSL, HTTP, HTTP2, рерайта и редиректа, которые предоставляет HAProxy, nuster предлагает следующие возможности:
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, и если он пройден, то возвращается ответ от бэкэнда.
NoSQL
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, когда правило.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 и отправить HTTP-запрос на этот URI.
Определение
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 по пути, который необходимо удалить;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 используется тот же метод, что и для удаления.
Правила, прокси или * можно удалить с помощью name. Текст запроса:
${NAME} で生成したキャッシュをPurge | | proxy NAME | proxy ${NAME}のキャッシュをPurge | | * | すべてのキャッシュをPurge
Перевод текста на русский язык:
Очистка кэша, созданного с помощью ${NAME}. | | Прокси NAME | Кээш прокси NAME очистить | | | * | Очистить весь кэш |
Примеры
# Очистить весь кэш
curl -X DELETE -H "name: *" http://127.0.0.1/nuster
# Очистить кэш прокси app1b
curl -X DELETE -H "name: app1b" http://127.0.0.1/nuster
# Удалить кэш, созданный nuster-rule r1
# То есть очистить кэш /imgs/*
# nuster-rule r1 imgs if { path_beg /imgs/ }
curl -X DELETE -H "name: r1" http://127.0.0.1/nuster
Можно очистить весь кэш хоста.
Заголовки
| Заголовок | Значение | Описание |
|---|---|---|
| host | HOST | хост ${HOST} |
| nuster-host | HOST | nuster-host имеет более высокий приоритет, чем host |
| mode | cache, nosql | очистить кэш или данные nosql |
Примеры
# Очистить весь кэш 127.0.0.1:8080
curl -X DELETE -H "nuster-host: 127.0.0.1:8080" http://127.0.0.1/nuster
По умолчанию, если запросы различаются, то и сгенерированные кэши будут различаться.
Например, nuster-rule imgs if {path_beg /imgs/}, а затем
curl http://127.0.0.1/imgs/test.jpg?w=120&h=120
curl http://127.0.0.1/imgs/test.jpg?w=180&h=180
будут созданы два кэша.
Помимо очистки по пути, существует несколько способов очистки.
По одному
curl -XPURGE http://127.0.0.1/imgs/test.jpg?w=120&h=120
curl -XPURGE http://127.0.0.1/imgs/test.jpg?w=180&h=180
Но это невозможно, если запрос неизвестен.
Если запрос не важен, используйте пользовательский ключ
nuster rule imgs key method.scheme.host.path if { path_beg /imgs }, тогда будет создан только один кэш. И можно очистить без запроса.
curl -XPURGE http://127.0.0.1/imgs/test.jpg
Но если запрос важен, это невозможно.
Очистить с помощью правила
curl -X DELETE -H «name: imgs» http://127.0.0.1/nuster
Тогда будет очищен не только /imgs/test.jpg, но и другие /imgs/*.
Поэтому очистка по пути:
заголовки
| заголовок | значение | описание |
|---|---|---|
| путь | PATH | кэши с ${PATH} будут очищены |
| хост | HOST | и хост — это ${HOST} |
| nuster-host | HOST | nuster-host имеет более высокий приоритет, чем host |
| режим | cache, nosql | очистить кеш или данные nosql |
Примеры
# очистить кэш с путём /imgs/test.jpg
curl -X DELETE -H "path: /imgs/test.jpg" http://127.0.0.1/nuster
# очистить кэш с путём /imgs/test.jpg и хостом 127.0.0.1:8080
curl -X DELETE -H "path: /imgs/test.jpg" -H "nuster-host: 127.0.0.1:8080" http://127.0.0.1/nuster
Заголовки
| Заголовок | Значение | Описание |
|---|---|---|
| регулярное выражение | REGEX | кэши, путь которых соответствует ${REGEX}, будут очищены |
| хост | HOST | и хост — это ${HOST} |
| nuster-host | HOST | nuster-host имеет более высокий приоритет, чем host |
| режим | cache, nosql | очистить кэш или данные nosql |
Примеры
# очистить кэши файлов .jpg в /img
curl -X DELETE -H "regex: ^/imgs/.\*\.jpg$" http://127.0.0.1/nuster
#/img файлы .jpg и хост 127.0.0.1:8080 очистить
curl -X DELETE -H "regex: ^/imgs/.\*\.jpg$" -H "127.0.0.1:8080" http://127.0.0.1/nuster
Примечание об очистке PURGE
Обязательно для контроля доступа
Если присутствует несколько заголовков, обработка выполняется в порядке name, path & host, path, regex & host, regex, host.
curl -X DELETE -H "name: rule1" -H "path: /imgs/a.jpg": очистить по имени
Если есть повторяющиеся заголовки, используется первый заголовок.
curl -X DELETE -H "name: rule1" -H "name: rule2": очистить с помощью rule1
regex — это не glob.
Файлы .jpg в каталоге /imgs не /imgs/*.jpg, а ^/imgs/.\*\.jpg$.
Очистка кэшей с помощью proxy name или rule name или host или path или regex должна выполняться после завершения загрузки диска. Завершение загрузки диска можно проверить с помощью URL статистики.
Nuster (cache и nosql) поддерживает несколько мест хранения. Сейчас есть только memory и disk.
Определённый размером data-size кэш сохраняется в памяти. При перезапуске данные исчезают.
Сохраняется в директории dir на диске. Данные сохраняются даже при перезапуске.
memory on обязательно. Мастер-процесс сохраняет данные в память, а затем периодически сохраняет disk-saver кэшей на диск. ###[кэш|NoSQL] nuster.uri: строка
Аналогично HAProxycapture.req.uri.
[Кэш|NoSQL] nuster.path: строка
Аналогично HAProxy path, но может использоваться как для запроса, так и для ответа.
[Кэш|NoSQL] nuster.query: строка
Аналогично HAProxy query, но может использоваться как для запроса, так и для ответа.
Установите 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 должен быть включён для кэширования POST-запросов
option http-buffer-request
acl pathPost path /search
# включить кэш для этого прокси
nuster cache
# кэширование /search на 120 секунд. Работает только при 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
# Кэширование /a.jpg без срока действия
acl pathA path /a.jpg
nuster rule r1 ttl 0 if pathA
# Кэширование /mypage, ключ содержит cookie[userId], поэтому он будет кэшироваться для каждого пользователя
acl pathB path /mypage
nuster rule r2 key method.scheme.host.path.delimiter.query.cookie_userId ttl 60 if pathB
# Кэширование /a.html, если заголовок ответа[cache] равен 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
# Кэширование /heavy на 100 секунд, если be_conn больше 10
acl heavypage path /heavy
acl tooFast be_conn ge 100
nuster rule heavy ttl 100 if heavypage tooFast
# Кэшировать всё, если заголовок ответа[asdf] равен 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
# отключить кэш на этом прокси
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 )