Слияние кода завершено, страница обновится автоматически
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/ для установки, получения или удаления объекта 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 никогда не будет соответствовать, поскольку первое правило будет кэшировать всё.
Определите имя для этого правила. Должно быть глобально уникальным начиная с версии v5.
Определите ключ для кэша/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 | TTL * (1 + n4%) |
Доступ:
| A1 | A2 | A3 | A4 | ||
|---|---|---|---|---|---|
| Процент: | <- (100 - n1 - n2 - n3)% -> | <- n1% -> | <- n2% -> | <- n3% -> | <- n4% -> |
TTL будет продлён, если:
wait on|off|TIME [только кэш]
Когда включено, только один запрос за раз будет передаваться на сервер бэкенда для создания кэша. Другие идентичные запросы либо будут ожидать, пока кэш не будет создан (wait on), либо истечёт время ожидания (wait TIME) и будут перенаправлены на сервер бэкенда.
По умолчанию идентичные запросы перенаправляются на сервер бэкенда, и первый из них создаст кэш (wait off).
Обратите внимание, что другие идентичные запросы не будут ждать, пока первый запрос завершит процесс инициализации (например, создаст запись в кэше).
В режиме nosql нет режима ожидания. Несколько идентичных запросов POST обрабатываются в порядке их поступления, а тело последнего запроса будет сохранено как содержимое.
Максимальное значение ожидания — 2147483647.
use-stale on|off|TIME [только кэш]
Определяет, следует ли обслуживать устаревший кэш клиентам, если он обновляется или сервер бэкенда недоступен.
Если use-stale включён, устаревший кэш будет использоваться для обслуживания клиентов.
Если use-stale выключен (что является режимом по умолчанию), те же запросы будут передаваться серверу бэкенда при обновлении кэша, если wait off установлен, иначе — ожидание, если wait on|TIME установлен.
use-stale TIME позволяет использовать устаревший кэш для обслуживания клиентов в течение TIME секунд, если кэш не может быть обновлён из-за ошибки сервера бэкенда.
Максимальное значение use-stale — 2147483647.
inactive off|TIME
Определяет, следует ли удалять кэш, который не был доступен в течение TIME секунд независимо от его действительности. По умолчанию inactive установлен в положение off (0).
Обратите внимание, что не гарантируется, что кэш будет удалён после неактивного TIME. Если процесс очистки сначала обращается к кэшу, то данные удаляются. Если новый запрос приходит первым, то последнее время доступа кэша обновляется, и кэш не удаляется. В случае с дисковым файлом время atime файла не используется, поэтому при перезапуске nuster время загрузки устанавливается как время последнего доступа.
Максимальное значение inactive — 2147483647.
code CODE1,CODE2...
Кэшировать только в случае, если статус ответа — CODE.
По умолчанию кэшируется только ответ 200. Вы можете использовать all для кэширования всех ответов.
nuster rule only200 nuster rule 200and404 code 200,404 nuster rule all code all
memory on|off
Сохранять данные в памяти или нет, по умолчанию — on.
См. раздел «Хранилище» для получения дополнительной информации.
disk on|off|sync
Сохранить данные на диск или нет и как, по умолчанию — off.
Для использования режима disk sync необходимо установить memory on.
См. раздел «Хранилище» для получения дополнительной информации.
etag on|off
Включить обработку условных запросов etag. Добавить заголовок ETag, если отсутствует.
Выключено по умолчанию.
last-modified on|off
Включить обработку условных запросов last-modified. Добавить заголовок Last-Modified, если отсутствует.
Выключено по умолчанию.
if|unless условие
Определить, когда выполнять кэширование, используя ACL HAProxy.
Оценка включает два этапа: этап запроса и этап ответа.
Кэш будет выполнен, если:
Пожалуйста, будьте очень осторожны, если вы используете отрицание в условии или образцы недоступны на определённом этапе.
Например:
Кэшируйте, если путь запроса начинается с /img/.
nuster rule img if { path_beg /img/ }
Это будет работать, потому что оценка на этапе запроса будет либо истинной, либо ложной и никогда не будет истинной на этапе ответа, поскольку path не доступен на этапе ответа. 2. Кэшируйте, если Content-Type в ответе — image/jpeg.
nuster rule jpeg if { res.hdr(Content-Type) image/jpeg }
Это будет работать, потому что оценка... Текст запроса написан на английском языке.
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.
See Sample fetches for sample fetches introduced by nuster.
See 7. Using ACLs and fetching samples section in HAProxy configuration.
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-размеру + data-размер
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
# Общее количество пропущенных запросов
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
Примечание: в запросе присутствуют фрагменты кода на языке YAML, которые не удалось перевести. Отключение правила
Правило можно отключить во время выполнения через менеджер 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
Состояние и 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 |
Примеры:
# Удалить все кэши, путь которых /imgs/test.jpg
curl -X DELETE -H «путь: /imgs/test.jpg» http://127.0.0.1/nuster
# Удалить все кэши, путь которых /imgs/test.jpg, а хост 127.0.0.1:8080
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 |
Пример:
# удалить все кэши, путь которых начинается с /imgs и заканчивается на .jpg
curl -X DELETE -H «регулярное выражение: ^/imgs/.jpg$» http://127.0.0.1/nuster
# удалить все кэши, путь которых начинается с /imgs и заканчивается на .jpg, а хост 127.0.0.1:8080
curl -X DELETE -H «регулярное выражение: ^/imgs/.jpg$» -H «127.0.0.1:8080» http://127.0.0.1/nuster
ОСТОРОЖНОСТЬ ОЧИСТКИ
name, path & host, path, regex & host, regex, host
curl -X DELETE -H «имя: rule1» -H «путь: /imgs/a.jpg»: очистка по имениcurl -X DELETE -H «name: rule1» -H «name: rule2»: очистка по rule1
regex — НЕ ШАБЛОН
Например, все файлы jpg под /imgs должны быть ^/imgs/.jpg$, а не /imgs/*.jpg
Nuster (как кеш, так и nosql) поддерживает различные серверные хранилища. В настоящее время поддерживаются память и диск. Будет добавлено больше хранилищ.
Данные хранятся в области памяти, размер которой определяется параметром data-size. Данные не сохраняются в памяти и теряются после перезапуска.
Данные сохраняются на диске и находятся в пути, определённом параметром dir. Данные сохраняются после перезапусков.
Существует 3 режима:
memory on, чтобы использовать этот режим. Сначала сохраните данные в памяти, а затем они будут синхронизированы с диском позже главным процессом. Одна итерация данных disk-saver проверяется и сохраняется на диск.Nuster представил следующие примеры выборки:
Возвращает логическое значение, указывающее, является ли это HIT, и может использоваться следующим образом:
http-response set-header x-cache hit if { nuster.cache.hit }
То же самое, что HAProxy req.hdr(Host), за исключением того, что nuster.host можно использовать как в запросе, так и в ответе.
То же, что и HAProxy capture.req.uri.
То же, что и HAProxy path, за исключением того, что nuster.path можно использовать в обоих этапах запроса и ответа.
То же, что и... HAProxy
Установите master-worker в разделе global, или запустите nuster с -W.
Запустите nuster с параметром -d.
Включите опцию 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.
Также может быть хорошей идеей разместить его отдельно в выделенном бэкэнде, как это сделано в примере.
Вы можете использовать мощный ACL HAProxy, например:
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
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 )