Слияние кода завершено, страница обновится автоматически
Nuster
Высокопроизводительный HTTP-прокси-сервер кэширования и RESTful NoSQL-сервер кэширования на основе HAProxy.
Nuster — это высокопроизводительный HTTP-прокси-сервер кэширования и RESTful NoSQL-сервер кэширования, основанный на HAProxy. Он на 100% совместим с HAProxy и использует все возможности ACL в HAProxy для предоставления детальной политики кэширования в зависимости от содержимого запроса, ответа или состояния сервера.
Nuster можно использовать в качестве балансировщика нагрузки HTTP/TCP, как HAProxy.
Nuster также можно использовать как прокси-сервер кэширования HTTP, такой как Varnish или Nginx, для кэширования динамических и статических ответов HTTP.
Nuster также может использоваться как RESTful кэш-сервер NoSQL, используя HTTP POST/GET/DELETE для установки/получения/удаления объектов Key/Value. Его можно использовать в качестве внутреннего кэша NoSQL между вашим приложением и базой данных, такого как Memcached или Redis, а также в качестве пользовательского кэша NoSQL, который находится между конечным пользователем и вашим приложением. Он поддерживает заголовки, файлы cookie, поэтому вы можете хранить данные для каждого пользователя в одной конечной точке.
Nuster очень быстр, некоторые тесты показывают, что nuster почти в три раза быстрее, чем nginx при использовании одного ядра, и почти в два раза быстрее, чем nginx, и в три раза быстрее, чем varnish при использовании всех ядер.
См. подробный тест производительности.
Загрузите стабильную версию со страницы Download для производственного использования, в противном случае клонируйте исходный код.
make TARGET=linux-glibc USE_LUA=1 LUA_INC=/usr/include/lua5.3 USE_OPENSSL=1 USE_PCRE=1 USE_ZLIB=1
make install PREFIX=/usr/local/nuster
Используйте
USE_PTHREAD_PSHARED=1, чтобы использовать библиотеку pthread.
Опустите
USE_LUA=1 LUA_INC=/usr/include/lua5.3 USE_OPENSSL=1 USE_PCRE=1 USE_ZLIB=1, если они не нужны.
Смотрите HAProxy INSTALL для получения дополнительной информации.
Минимальный файл конфигурации: nuster.cfg
global
nuster cache on data-size 100m
nuster nosql on data-size 200m
master-worker # since v3
defaults
mode http
frontend fe
bind *:8080
#bind *:4433 ssl crt example.com.pem alpn h2,http/1.1
use_backend be2 if { path_beg /_kv/ }
default_backend be1
backend be1
nuster cache on
nuster rule img ttl 1d if { path_beg /img/ }
nuster rule api ttl 30s if { path /api/some/api }
server s1 127.0.0.1:8081
server s2 127.0.0.1:8082
backend be2
nuster nosql on
nuster rule r1 ttl 3600
nuster слушает на... Nuster
Порт 8080 принимает HTTP-запросы.
Запросы, начинающиеся с /_kv/, направляются на бэкенд be2. С помощью запросов POST/GET/DELETE к /_kv/any_key можно устанавливать, получать и удалять объекты K/V.
Другие запросы направляются на бэкэнд be1 и передаются серверам s1 или s2. Среди этих запросов /img/* будет кэшироваться в течение 1 дня, а /api/some/api — в течение 30 секунд.
/usr/local/nuster/sbin/nuster -f nuster.cfg
docker pull nuster/nuster
docker run -d -v /path/to/nuster.cfg:/etc/nuster/nuster.cfg:ro -p 8080:8080 nuster/nuster
Nuster основан на HAProxy, все директивы HAProxy поддерживаются в nuster.
Существует четыре основных раздела: global, defaults, frontend и backend, как вы можете узнать из приведённого выше конфигурационного файла.
nuster cache on или nuster nosql on должны быть объявлены в этом разделе, чтобы использовать функции кэша или nosqlfrontend, backend
frontend или backend
nuster cache on или nuster nosql on должен быть объявлен в этом разделеnuster rule должен быть объявлен здесьМожно определить несколько разделов frontend или backend. Если объявлено nuster cache|nosql off или не объявлено nuster cache|nosql on|off, nuster действует так же, как HAProxy, в качестве TCP и HTTP балансировщика нагрузки.
Хотя listen является полноценным прокси с объединёнными частями frontend и backend в одном разделе, вы не можете использовать nuster в listen, используйте пары frontend и backend.
Вы можете найти документацию HAProxy в /doc и онлайн-документацию HAProxy.
frontend mysql-lb
bind *:3306
mode tcp
default_backend mysql-cluster
backend mysql-cluster
balance roundrobin
mode tcp
server s1 10.0.0.101:3306
server s2 10.0.0.102:3306
server s3 10.0.0.103:3306
frontend web-lb
bind *:80
#bind *:443 ssl crt XXX.pem
mode http
default_backend apps
backend apps
balance roundrobin
mode http
server s1 10.0.0.101:8080
server s2 10.0.0.102:8080
server s3 10.0.0.103:8080
#server s4 10.0.0.101:8443 ssl verify none
global
nuster cache on data-size 200m
frontend fe
bind *:8080
mode http
default_backend be
backend be
mode http
nuster cache on
nuster rule all
server s1 127.0.0.1:8081
global
nuster nosql on data-size 200m
frontend fe
bind *:8080
mode http
default_backend be
backend be
nuster nosql on
mode http
nuster rule r1 ttl 3600
синтаксис:
nuster manager on|off [uri URI] [purge-method method]
по умолчанию: off
контекст: global
Включите менеджер/статистику/очистку API, определите конечную точку и метод очистки.
По умолчанию он отключён. Когда он включён, не забудьте ограничить доступ (см. FAQ).
См. раздел Менеджер для получения подробной информации.
Определите конечную точку URI, /nuster по умолчанию.
Определите настраиваемый HTTP-метод для очистки, по умолчанию это PURGE.
синтаксис:
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]
по умолчанию: none
контекст: global
Определяет, следует ли использовать кэш/nosql или нет.
Будет создана зона памяти размером data-size + dict-size. Будет создан.
За исключением временных данных, создаваемых и уничтожаемых в рамках запроса, все данные кэша, включая данные ответа HTTP, ключи и служебные данные, хранятся в этой области памяти и совместно используются всеми процессами.
Если больше нельзя выделить память из этой зоны памяти, новые запросы, которые должны быть кэшированы в соответствии с определёнными правилами, не будут кэшироваться, пока не освободится какая-либо память.
Временные данные хранятся в пуле памяти, который динамически выделяет память от системы в случае отсутствия доступной памяти в пуле.
Глобальный внутренний счётчик отслеживает использование памяти всеми данными ответа HTTP во всех процессах, новые запросы не будут кэшироваться, если счётчик превышает data-size.
Определяет размер области памяти вместе с dict-size.
Принимает единицы измерения, такие как m, M, g и G. По умолчанию размер составляет 1024 * 1024 байта, что также является минимальным размером.
Определяет объём памяти, используемый хеш-таблицей.
Принимает единицы измерения, такие как m, M, g и G. По умолчанию размер составляет 1024 * 1024 байта, что также является минимальным размером.
Обратите внимание, что он определяет только память, используемую сегментами хеш-таблицы, а не ключами. Фактически, ключи хранятся в области памяти, которая ограничена data-size.
dict-size (количество сегментов) отличается от количества ключей. Новые ключи всё ещё можно добавлять в хеш-таблицу, даже если количество ключей превышает dict-size (количество сегментов), пока есть достаточно памяти.
Тем не менее это может привести к потенциальному снижению производительности, если количество ключей больше, чем dict-size (количество сегментов). Приблизительное количество ключей, умноженное на 8 (обычно), как dict-size, должно подойти. В принципе, чем больше, тем лучше.
Включите API статистики и проверьте следующие статистические данные:
dict.nosql.length: 131072
dict.nosql.used: 0
Если dict.nosql.used больше, чем dict.nosql.length, то увеличение dict-size было бы хорошей идеей.
dict-size будет удалён в будущем выпуске, автоматическое изменение размера хеш-таблицы в первой версии будет добавлено обратно.
Укажите корневой каталог дискового хранилища. Это необходимо установить, чтобы использовать дисковое хранилище. Если также установлен chroot, реальный каталог — это chroot+dir. Например:
chroot /data
nuster cache on dir /cache
Кэш сохраняется в /data/cache.
До версии v2.x задачи менеджера, такие как удаление недействительных данных кэша и сброс записей dict, выполнялись итерациями в каждом запросе HTTP. Соответствующие индикаторы или указатели увеличивались или продвигались вперёд на каждой итерации.
В версии v3.x эти задачи перемещены в главный процесс и также выполняются итерациями, и эти параметры можно настроить для управления количеством выполнений определённой задачи за одну итерацию.
Во время одной итерации проверяется не более dict-cleaner записей, недействительные записи будут удалены (по умолчанию 1000).
Во время одной итерации проверяется не более data-cleaner данных, недействительные данные будут удалены (по умолчанию 1000).
Когда соотношение недействительных данных превышает 20%, внутренний механизм ускорит процесс очистки, поэтому рекомендуется не изменять это значение по умолчанию.
Если включено дисковое хранение, данные сохраняются в файлах. Эти файлы проверяются главным процессом и будут удалены, если они недействительны, например, просрочены.
Во время одной итерации проверяется не более disk-cleaner файлов, недействительные файлы будут удалены (по умолчанию 100).
После запуска nuster главный процесс загрузит информацию о данных, ранее сохранённых на диске, в память.
Во время одной итерации загружается не более disk-loader файлов (по умолчанию 100).
Если используется USE_THREAD, будет создан отдельный поток для загрузки файлов диска, и этот параметр игнорируется.
Главный процесс периодически сохраняет данные кэша disk sync.
Во время одной итерации проверяется и сохраняется на диск не более disk-saver данных (по умолчанию 100), если это необходимо.
См. раздел Хранилище для получения дополнительной информации.
Под каталогом, определённым параметром dir, временный... Каталог .tmp будет создан для хранения временных файлов.
Используйте эту опцию, чтобы определить, следует ли удалять эти временные файлы при запуске.
По умолчанию она отключена.
Первоначальная загрузка кэшированных данных на диск происходит только при запуске и имеет место, если работа ведётся в сценарии, где диск используется совместно несколькими экземплярами, это может привести к пропущенным вызовам кэша. Используя эту опцию, диск всегда проверяется на наличие кэшированных данных. По умолчанию отключено.
Синтаксис: nuster cache [on|off] nuster nosql [on|off] По умолчанию: on Контекст: backend Определяет, использовать ли кэш/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] По умолчанию: нет Контекст: backend Определите правило, чтобы указать условия создания кэша/nosql, свойства. Следует определить хотя бы одно правило.
nuster cache on
# кэш запроса `/asdf` на 30 секунд
nuster rule asdf ttl 30 if { path /asdf }
# кэш, если путь запроса начинается с /img/
nuster rule img if { path_beg /img/ }
# кэш, если заголовок ответа `cache` равен `yes`
acl resHdrCache res.hdr(cache) yes
nuster rule r1 if resHdrCache
Можно и рекомендуется объявлять несколько правил в одном разделе. Порядок важен, потому что процесс сопоставления останавливается при первом совпадении.
acl pathA path /a.html
nuster cache on
nuster rule all ttl 3600
nuster rule path01 ttl 60 if pathA
Правило path01 никогда не будет соответствовать, поскольку первое правило будет кэшировать всё.
Определите имя для этого правила. Должен быть уникальным во всём мире, начиная с версии 5.
Определите ключ для кэша/nosql. Это строка, состоящая из следующих ключевых слов, разделённых символом .:
По умолчанию ключ CACHE — method.scheme.host.uri, а ключ NoSQL по умолчанию — GET.scheme.host.uri.
Пример
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;
Должно получиться:
Таким образом, ключ по умолчанию выдаёт GET\0http\0www.example.com\0/q?name=X&type=Y\0, а key method.scheme.host.path.header_ASDF.cookie_user.param_type выдаёт GET\0http\0www.example.com\0/q\0Z\0nuster\0Y\0.
\0— символ NULL
Если запрос имеет тот же ключ, что и кэшированные данные HTTP-ответа, то кэшированные данные будут отправлены клиенту.
Установите TTL для ключа, после истечения TTL ключ будет удалён.
Он принимает такие единицы измерения, как d, h, m и s. По умолчанию ttl равен 0, что означает, что ключ не истекает.
Когда используется auto, ttl устанавливается равным значению s-maxage или max-age директивы в заголовке cache-control.
Другие директивы
cache-controlне обрабатываются. Максимальное значение ttl составляет 2147483647. ttl можно автоматически продлить с помощью ключевого словаextend.
Автоматически продлевает срок действия ttl.
extend on|off|n1,n2,n3,n4 По умолчанию: отключено. n1, n2, n3 — положительные целые числа меньше 100, а n1 + n2 + n3 меньше 100. Вместе они определяют четыре временных интервала следующим образом:
| Время | TTL |
|---|---|
| 0 |
Доступ:
| A1 | A2 | A3 | A4 | ||
|---|---|---|---|---|---|
| Процент: | <- (100 - n1 - n2 - n3)% -> | <- n1% -> | <- n2% -> | <- n3% -> | <- n4% -> |
TTL будет продлён, если:
onравно 33,33,33,33.
Когда включено, только один запрос за раз будет передаваться на сервер бэкенда для создания кэша. Другие идентичные запросы либо будут ожидать, пока кэш не будет создан (ожидание on), либо истечёт время (ожидание TIME) и будут перенаправлены на сервер бэкэнда.
По умолчанию идентичные запросы передаются на сервер бэкэнда, и первый создаст кэш (ожидание off).
Обратите внимание, что другие идентичные запросы не будут ждать, пока первый запрос завершит процесс инициализации (например, создаст запись в кэше).
В режиме nosql нет режима ожидания. Несколько идентичных POST-запросов обслуживаются в порядке их получения, а тело последнего запроса будет сохранено как содержимое.
Максимальное значение ожидания — 2147483647.
Определяет, следует ли обслуживать устаревший кэш клиентам, если он обновляется или сервер бэкэнда недоступен.
Если использовать устаревшее включено, устаревший кэш будет использоваться для обслуживания клиентов.
Если использование устаревших отключено, что является режимом по умолчанию, те же запросы будут передаваться серверу при обновлении кэша, если установлено ожидание off, в противном случае — ожидание, если установлено ожидание on|TIME.
Использование устаревшего TIME позволяет использовать устаревший кэш для обслуживания клиентов в течение TIME секунд, если кэш не может быть обновлён из-за ошибки сервера.
Максимальное значение использования устаревшего — 2147483647.
Определяет, следует ли удалять кэш, который не был доступен в течение TIME секунд независимо от действительности. По умолчанию неактивное установлено на off(0).
Обратите внимание, что не гарантируется, что кэш будет удалён после неактивного TIME. Если процесс очистки сначала обращается к кэшу, то данные удаляются. Если сначала приходит новый запрос, то последнее время доступа кэша обновляется, и кэш не удаляется. В случае файла диска время atime файла не используется, поэтому при перезагрузке nuster время загрузки устанавливается как время загрузки.
Максимальное значение неактивного — 2147483647.
Кэшировать только в том случае, если статус ответа равен CODE.
По умолчанию кэшируется только ответ 200. Вы можете использовать all для кэширования всех ответов.
nuster rule only200
nuster rule 200and404 code 200,404
nuster rule all code all
Сохранять данные в памяти или нет, по умолчанию включено.
См. раздел «Хранилище» для получения подробной информации.
Сохранять данные на диск или нет и как, по умолчанию отключено.
Для использования режима disk sync необходимо установить memory on.
См. раздел «Хранилище» для получения подробной информации.
Включить обработку условных запросов etag. Добавить заголовок ETag, если отсутствует.
Отключено по умолчанию.
Включение обработки условных запросов last-modified. Добавить заголовок Last-Modified, если отсутствует.
Отключено по умолчанию.
Определите, когда выполнять кэширование с помощью HAProxy ACL.
Оценка включает два этапа: этап запроса и этап ответа.
Кэш будет выполнен, если:
Пожалуйста, будьте очень осторожны, если вы используете отрицание в условии или образцы недоступны на определённом этапе.
Например,
Кэшируйте, если путь запроса начинается с /img/
nuster правило img if { path_beg /img/ }
Это будет работать, потому что оценка на этапе запроса будет либо истинной, либо ложной и никогда не будет истинной на этапе ответа, поскольку путь не доступен на этапе ответа.
Кэшировать, если Content-Type в ответе — image/jpeg
nuster правило jpeg if { res.hdr(Content-Type) image/jpeg }
Это будет работать, потому что оценка в запросе будет либо истинной, либо ложной, и она всегда будет истинной в ответе, поскольку Content-Type всегда присутствует в ответе. Текст запроса написан на английском языке.
evaluation in the request stage is always false as res.hdr is not available in the request stage, and will be either true or false in the response stage.
/img/ and Content-Type in response is image/jpeg.It won't work if you define the rule as:
nuster rule img if { path_beg /img/ } { res.hdr(Content-Type) image/jpeg }
because path is not available in the response stage and res.hdr is not available in the request stage, so the evaluation will never be true.
In order to make this work, path needs to be allocated for further use in the response stage:
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
Or use nuster.path(v5):
nuster rule r3 if { nuster.path -m beg /img } { res.hdr(Content-Type) image/jpeg }.
/api/.It won’t work neither:
acl NoCache path_beg /api/
nuster rule r3 if !NoCache
Because the evaluation of NoCache against /api/ in the request stage is true, and the negation is false, which is the desired state, but in the response stage, the evaluation of NoCache is always false as path is not available in the response stage, and it will be cached as the negation !NoCache is true.
This will work:
http-request set-var(txn.path) path
acl NoCache var(txn.path) -m beg /api/
nuster rule r1 if !NoCache.
nuster can be used as an HTTP proxy cache server like Varnish or Nginx to cache dynamic and static HTTP response.
You can use HAProxy functionalities to terminate SSL, normalize HTTP, support HTTP2, rewrite the URL or modify headers and so on, and additional functionalities provided by nuster to control cache.
global
nuster cache on data-size 200m
frontend fe
bind *:8080
mode http
default_backend be
backend be
mode http
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
When a request is accepted, nuster will check the rules one by one. Key will be created and used to lookup in the cache, and if it’s a HIT, the cached data will be returned to the client. Otherwise the ACL will be tested, and if it passes the test, response will be cached.
nuster can be used as a RESTful NoSQL cache server, using HTTP POST/GET/DELETE to set/get/delete Key/Value object.
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.
Check status code.
Supported headers in request
| Name | value | description |
|---|---|---|
| content-type | any | Will be returned as is in GET request |
| cache-control |
s-maxage or max-age
|
used to set ttl when rule.ttl is auto
|
By using header or cookie in key, you can save per-user data to the same 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 }
... ### Get
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
| МЕТОД | Конечная точка | описание |
|---|---|---|
| GET | /internal/nuster | получить статистику |
| POST | /internal/nuster | включить и отключить правило, обновить ttl |
| DELETE | /internal/nuster | расширенная очистка кэша |
| PURGEX | /any/real/path | базовая очистка |
Доступ к статистике Nuster можно получить, отправив HTTP-запрос GET на конечную точку, определённую параметром uri.
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 в байтах, определяется параметром dict-size
dict.cache.size: 1048576
# Длина массива кеша dict
dict.cache.length: 131072
# Количество использованных записей в кеше dict
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**
# Размер кэш-памяти хранилища в байтах, приблизительно равен размеру dict-size + data-size
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
# Общее количество успешных запросов HIT
stats.cache.hit: 0
# Общее количество неудачных запросов MISS
stats.cache.fetch: 0
# Общее количество пропущенных запросов bypass
stats.cache.bypass: 0
# Общее количество прерванных запросов abort
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.ruie.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.ruie.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
Правило можно отключить во время выполнения через менеджер URI. Отключённое правило не будет обрабатываться, и кэш, созданный этим правилом, также не будет создан.
Заголовки
| Заголовок | Значение | Описание |
|---|---|---|
| state | enable | Включить правило |
| disable | Отключить правило | |
| name | rule 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. Это влияет только на TTL ответов, которые будут кэшироваться, не обновляет TTL существующих кэшей.
Заголовки
| Заголовок | Значение | Описание |
|---|---|---|
| ttl | new TTL | См. ttl в nuster rule
|
| name | rule NAME | Правило для изменения |
| proxy NAME | Все правила прокси NAME | |
| * | Все правила |
Примеры
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
Состояние и TTL можно обновить одновременно
curl -X POST -H "name: r1" -H "ttl: 0" -H "state: enabled" http://127.0.0.1/nuster
Очистка
Есть два режима очистки: базовый и расширенный.
purge-method MYPURGE, по пути, который вы хотите удалить.uri.Базовая очистка
Этот метод удаляет конкретный URL, который запрашивается, например:
curl -XPURGE http://127.0.0.1/imgs/test.jpg
Ключ создаётся так же, как и при создании кэша, за исключением того, что method — это GET.
По умолчанию ключ кэша содержит Host, если вы кэшируете запрос типа http://example.com/test и очищаете его с localhost, вам необходимо указать заголовок Host:
curl -XPURGE -H "Host: example.com" http://127.0.0.1/test
Это работает как для кэша, так и для nosql, это псевдоним DELETE в режиме nosql.
Расширенная очистка: очистка по имени
Кэш можно очистить, отправив HTTP-запросы DELETE менеджеру URI вместе с заголовком name.
Заголовки
| Заголовок | Значение | Описание |
|---|---|---|
| name | nuster rule NAME | Кэши, созданные правилом ${NAME}, будут очищены |
| proxy NAME | Кэши прокси ${NAME} |
Пример
# Очистить все кэши прокси applb
curl -X DELETE -H "name: app1b" http://127.0.0.1/nuster
# Очистить все кэши правила r1
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 |
Пример
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: imgs, ключ метода.scheme.host.path, если { path_beg /imgs}
В этом случае будет создан только один кэш, и вы сможете выполнить очистку без запроса:
curl -XPURGE http://127.0.0.1/imgs/test.jpg
Это не сработает, если требуется часть запроса.
Удалить по правилу NAME
curl -X DELETE -H "name: imgs" http://127.0.0.1/nuster
Не работает, если определено правило nuster, например, nuster rule static if { path_beg /imgs/ /css/ }.
Этот метод предоставляет способ очистки только по пути:
| Заголовок | Значение | Описание |
|---|---|---|
| путь | PATH | Очистка кэшей с помощью ${PATH} |
| хост | HOST | И хост равен ${HOST} |
| nuster-host | HOST | Хост nuster имеет более высокий приоритет над хостом |
| режим | кеш, nosql | Очистить кеш или данные nosql |
Примеры:
curl -X DELETE -H «путь: /imgs/test.jpg» http://127.0.0.1/nuster
curl -X DELETE -H «путь: /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 имеет более высокий приоритет над хостом |
| режим | кэш, nosql | очистить кеш или данные nosql |
Примеры:
curl -X DELETE -H «регулярное выражение: ^/imgs/..jpg$» http://127.0.0.1/nuster
curl -X DELETE -H «регулярное выражение: ^/imgs/..jpg$} -H «127.0.0.1:8080» http://127.0.0.1/nuster
ОСТОРОЖНОСТЬ ОЧИСТКИ
ВКЛЮЧИТЕ ОГРАНИЧЕНИЕ ДОСТУПА
Если есть смешанные заголовки, используйте приоритет имени, пути и хоста, регулярного выражения и хоста, регулярного выражения, хоста.
curl -X DELETE -H «имя: rule1» -H «путь: /imgs/a.jpg»: очистка по имени
Если есть повторяющиеся заголовки, используется первое вхождение.
curl -X DELETE -H «имя: rule1» -H «имя: rule2»: очистка по rule1
Регулярное выражение — это НЕ шаблон
Например, все файлы jpg под /imgs должны быть ^/imgs/.\.jpg$, а не /imgs/*.jpg
Очистка файлов кэша по имени прокси, имени правила, хосту, пути или регулярному выражению работает только после завершения процесса загрузки диска. Вы можете проверить статус через URL статистики.
Nuster (как кеш, так и nosql) поддерживает различные серверные хранилища. В настоящее время поддерживаются память и диск. Будет добавлено больше хранилищ.
Данные хранятся в области памяти, размер которой определяется параметром data-size. Данные не сохраняются в памяти и будут потеряны после перезапуска.
Данные сохраняются на диск по пути, определённому параметром dir. Данные сохраняются после перезапусков.
Существует 3 режима:
memory on, чтобы использовать этот режим. Сначала сохраните данные в памяти, а затем мастер-процесс синхронизирует данные с диском. За одну итерацию проверяется и сохраняется на диск disk-saver. HAProxy: часто задаваемые вопросы
Не удаётся запустить: не в режиме master-worker
Установите master-worker в разделе global, или запустите nuster с -W.
Как отлаживать?
Запустите nuster с параметром -d.
Что может быть причиной ошибки 504 gateway timeout?
Пожалуйста, проверьте настройки вашего бэкэнда. Вы указали порт в директиве сервера? Если порт указан, все соединения будут отправляться на этот порт. Если порт не указан, будет использоваться тот же порт, к которому подключился клиент.
backend be
mode http
server s1 10.0.0.3:80
Как кэшировать POST-запрос?
Включите опцию option http-buffer-request и установите body в правиле кэша key.
По умолчанию ключ кэша не включает тело запроса, не забудьте указать body в поле ключа.
Обратите внимание, что размер тела запроса должен быть меньше, чем tune.bufsize - tune.maxrewrite - request_header_size, который по умолчанию равен 16384 - 1024 - request_header_size.
Подробнее см. разделы option http-buffer-request и tune.bufsize в документации HAProxy (doc/configuration.txt).
Также может быть хорошей идеей выделить его отдельно в специальном бэкэнде, как показано в примере.
Как ограничить доступ?
Вы можете использовать мощный ACL HAProxy, например:
acl network_allowed src 127.0.0.1
acl purge_method method PURGE
http-request deny if purge_method !network_allowed
Как включить HTTP2?
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
master-worker # since v3
# 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
nuster 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 )