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

global
    nuster cache on data-size 100m
    nuster nosql on data-size 200m
    master-worker # 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

docker pull nuster/nuster
docker run -d -v /path/to/nuster.cfg:/etc/nuster/nuster.cfg:ro -p 8080:8080 nuster/nuster

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 как кэш-сервер**

**Как RESTful NoSQL кэш-сервер**

### **Команды**

#### **global: nuster manager**

Синтаксис:
*nuster manager on|off [uri URI] [purge-method method]*

По умолчанию: off

Контекст: global

Определяет и включает manager/stats/purge API, uri и purge method.

По умолчанию выключено. Если включено, обратите внимание на включение контроля доступа (см. раздел FAQ).

Для получения дополнительной информации см. раздел «Управление».

*uri*

Настраиваемый URI менеджера, по умолчанию — `/nuster`.

*purge-method*

HTTP метод, используемый для очистки, по умолчанию — `PURGE`.

#### **global: 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]*

По умолчанию: нет

Контекст: глобальный

Управляет включением или отключением кэша или nosql.

Будет выделена общая память размером data-size + dict-size для хранения HTTP-заголовков, данных, ключей и т. д., а временные данные будут выделены из системной памяти.
Если памяти недостаточно, новые запросы не будут кэшироваться до тех пор, пока не освободится память.

*data-size*

Совместно с dict-size определяет размер блока памяти.

Можно использовать m, M, g и G. По умолчанию — 1 МБ, что также является минимальным значением.

*dict-size*

Определяет размер хеш-таблицы.

Можно использовать m, M, g и G. По умолчанию — 1 МБ, что также является минимальным значением.

Этот параметр определяет размер корзины хеш-таблицы, а не размер ключа, который хранится в общей памяти.

Размер dict-size (количество корзин) не равен количеству ключей. Даже если количество ключей превышает размер dict-size, новые ключи могут быть добавлены, если есть свободное место в общей памяти. Однако, если количество ключей больше размера dict-size (количества корзин), производительность может снизиться. Размер dict-size можно установить примерно равным максимальному количеству ключей, умноженному на 8. Конечно, чем больше, тем лучше.

Чтобы просмотреть статистику API:

Если значение dict.nosql.used больше значения dict.nosql.length, рекомендуется увеличить размер dict-size.

> В будущих версиях dict-size будет удалён, и автоматическое расширение будет выполнено так же, как и в первой версии.

*dir*

Устанавливает корневой каталог для файлов кэша на жёстком диске, который необходимо настроить для включения функции кэширования на жёстком диске.

Если включён chroot, то фактический путь будет chroot+dir. Например:

Тогда фактическое расположение кэша будет: /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).

Дополнительную информацию см. в разделе «Хранилище».

*clean-temp on|off*

В каталоге, определённом параметром dir, автоматически создаётся каталог .tmp для хранения временных файлов.

Эта опция определяет, следует ли удалять каталог .tmp при запуске. По умолчанию отключено.

*always-check-disk on|off*

Определяет, всегда ли проверять наличие файлов кэша на жёстком диске, особенно когда несколько экземпляров совместно используют жёсткий диск и кэширование может не сработать.

По умолчанию отключено.

#### **proxy: nuster cache|nosql**

Синтаксис:

*nuster cache [on|off]*

*nusternosql [on|off]*

По умолчанию: включено

Контекст: backend

Определяет, включать ли cache/nosql в этом бэкэнде.
Если в этом разделе есть фильтр, не забудьте разместить его последним.

#### **proxy: nuster rule**

Синтаксис:

*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]*

По умолчанию: нет

Контекст: бэкэнд

Определяет условия активации cache/nosql, требуется определить хотя бы одно правило.

Можно определить несколько правил, которые будут сопоставляться в порядке определения.

Правило path01 никогда не будет сопоставлено.

*name*

Определяет имя правила. Начиная с версии 5, оно должно быть уникальным в глобальном масштабе.

*key KEY*

Определяет ключ cache/nosql, состоящий из следующих ключевых слов, соединённых точкой:

 * method:       http метод, GET/POST...
 * scheme:       http или https
 * host:         хост в запросе
 * uri:          первый слэш до конца URL
 * path:         URL-путь **CACHE и NoSQL: принципы работы с запросами**

* **Delimiter**: '?' если запрос существует, иначе пусто.
* **Запрос**: вся строка запроса.
* **Header_NAME**: значение заголовка NAME.
* **Cookie_NAME**: значение cookie NAME.
* **Param_NAME**: значение параметра NAME в запросе.
* **Тело**: тело запроса.  

По умолчанию ключ CACHE — `method.scheme.host.uri`, а ключ NoSQL — `GET.scheme.host.uri`.

Пример:

Генерируется следующее:

 * **method**: GET.
 * **scheme**: http.
 * **host**: www.example.com.
 * **uri**: /q?name=X&type=Y.
 * **path**: /q.
 * **delimiter**: ?.
 * **query**: name=X&type=Y.
 * **header_ASDF**: Z.
 * **cookie_user**: nuster.
 * **param_type**: Y.
 * **body**: (пусто).

По умолчанию создаётся ключ `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-символ.

Запросы с одинаковыми ключами будут сразу возвращаться из кэша клиенту.

### TTL auto|TTL

Устанавливает время жизни кэша, после истечения которого кэш будет удалён. Можно использовать `d`, `h`, `m` и `s`. По умолчанию — 0 секунд. Если не хотите, чтобы срок действия истёк, установите его равным нулю.

При использовании `auto` TTL автоматически использует значение `cache-control` header `s-maxage` или `max-age`.

> Другие команды `cache-control` не обрабатываются.

Максимальное значение TTL — 2147483647.

Можно установить `extend` для автоматического продления срока действия кэша.

### Extend EXTEND

Автоматически продлевает срок действия кэша TTL.

#### Формат

extend on|off|n1,n2,n3,n4.

По умолчанию: off.

n1, n2, n3, n4: целые числа меньше 100, сумма n1 + n2 + n3 также меньше 100. Они определяют четыре временных интервала:

Кэш будет продлён, если выполняются следующие условия:

1. A4 > A3 > A2.
2. В промежутке между `ttl` и `ttl * (1+n4%)` есть новый запрос.

> `on` фактически равно 33,33,33,33.

### Wait on|off|TIME [только кэш]

Если одновременно есть одинаковые запросы, ждать ли завершения кэширования. `wait on` означает ожидание до завершения других запросов на кэширование, `wait TIME` означает ожидание TIME секунд, и если кэширование ещё не завершено, перенаправлять на серверную часть.

По умолчанию не ждёт, все запросы перенаправляются на серверную часть, первый запрос генерирует кэш (`wait off`).

Обратите внимание, что только после выполнения некоторых начальных задач для первого запроса другие запросы будут ожидать.

> В режиме NoSQL ожидание не происходит, все запросы обрабатываются по очереди, содержимое последнего запроса сохраняется.

Максимум — 2147483647.

### Use-stale on|off|TIME [только кэш]

Определяет, следует ли использовать устаревший кэш при обновлении и следует ли использовать его при сбое серверной части.

Когда use-stale включён, устаревший кэш используется при обновлении.

Когда use-stale выключен, если `wait off`, то все запросы будут перенаправлены на серверную часть; в противном случае они будут ожидать.

`use-stale TIME` позволяет продолжать использовать кэш в течение TIME секунд после сбоя обновления из-за сбоя серверной части.

Максимум — 2147483647.

### Inactive off|TIME

Если в течение TIME секунд не было обращений, кэш удаляется. По умолчанию отключено.

Обратите внимание, что после TIME секунд без обращения кэш не обязательно будет удалён. Если процесс очистки запускается раньше нового запроса к кэшу, то кэш будет удалён; если новый запрос происходит раньше процесса очистки, то последнее время доступа кэша обновляется, и он не будет удалён. Не используется доступное время файла кэша на диске, и после перезапуска Nuster последнее время доступа кеша устанавливается на время загрузки кеша.

Максимум: 2147483647.

### Code CODE1,CODE2...

По умолчанию кэшируются только ответы со статусом 200. Если требуется кэшировать другие статусы, их можно добавить. `all` кэширует любые статусы.

### Memory on|off

Сохраняет ли данные в памяти, по умолчанию включено.

См. раздел «Хранилище».

### Disk on|off|sync

Сохраняются ли данные на диск, как они сохраняются, по умолчанию отключено.

Необходимо установить `memory on`, чтобы использовать `disk sync`.

См. раздел «Хранилище».

### Etag on|off

Определяет, обрабатывается ли условие etag. Если нет `ETag`, добавляется.

По умолчанию отключено.

### Last-modified on|off

Определяет, обрабатывается ли условие last-modified. Если нет `Last-Modified`, добавляется.

По умолчанию отключено.

### If|unless condition

Определяют условия ACL.

ACL выполняются отдельно на этапе запроса и на этапе ответа.

Если условие на этапе запроса истинно, или условие на этапе ответа истинно, а на этапе запроса ложно, то происходит кэширование.

**При использовании отрицательного ACL или некоторых методов выборки данных необходимо соблюдать особую осторожность**.

Например:

1. Кэширование запросов, начинающихся с `/img/`.

    nuster rule img if { path_beg /img/ }

На этапе запроса условие либо истинно, либо ложно, поскольку на этапе ответа невозможно получить `path`, поэтому оно всегда ложно.

2. Кэширование ответов с заголовком `Content-Type`, равным `image/jpeg`.

    nuster rule jpeg if { res.hdr(Content-Type) image/jpeg }

Поскольку на этапе запроса невозможно получить `res.hdr`, условие всегда ложно; на этапе ответа условие может быть истинным или ложным.

3. Кэширование запросов, начинающихся с `/img/` и ответов с заголовком `Content-Type`, равным `image/jpeg`.

Если определено следующее правило, оно не сработает:

    nuster rule img if { path_beg /img/ } { res.hdr(Content-Type) image/jpeg }

Потому что на этапе ответа нельзя получить `path`, так что условие всегда ложно, а на этапе запроса нельзя получить `res.hdr`, так что условие тоже всегда ложно, и это условие никогда не будет соответствовать.

Требуется определить следующим образом:

    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 }

4. Другой пример: кэширование всех запросов, не начинающихся с `/api/`.

Ниже неверно:

    acl NoCache path_beg /api/
    nuster rule r3 if !NoCache

Так как хотя на этапе ответа `path` не существует, `NoCache` всегда ложен, а `!NoCache` истинен, все запросы кэшируются.

Нужно изменить на: **HTTP-запрос set-var (txn.path) path**

ACL NoCache var (txn.path) — m beg /api/
Nuster rule r1 if !NoCache

* *Подробности выборки образца см. в разделе «Выборка образцов»*.

Подробнее см. раздел «Конфигурация HAProxy» документа «Конфигурация» **7. Использование ACL и выборка образцов**.

# Кэш

Nuster также может использоваться в качестве HTTP-кэша, подобного Varnish или Nginx, для кэширования динамических или статических HTTP-ресурсов. Помимо SSL, HTTP, HTTP2, перезаписи, перенаправления, добавления, удаления и изменения заголовков и т. д., предоставляемых HAProxy, он также предоставляет следующие функции:

server s1 127.0.0.1:8081

Nuster последовательно проверяет правила, сначала генерирует ключ, а затем ищет его. Если ключ найден, то возвращает кэш, в противном случае проверяет ACL. Если ACL проходит, то сохраняет ответ в кэше.

# NoSQL

Nuster можно использовать в качестве RESTful NoSQL-кэширующего сервера, используя HTTP POST/GET/DELETE для добавления/получения/удаления Key/Value.

## Основные операции

### Set

### Get

`curl -v http://127.0.0.1:8080/key1`

### Delete

`curl -v -X DELETE http://127.0.0.1:8080/key1`

## Ответ

Проверьте код состояния.

* 200 OK
  * POST/GET: успешно
  * DELETE: всегда
* 400 Bad request
  * Пустое значение
  * Неправильное ACL, правила и т.д.
* 404 Not Found
  * POST: проверка правила не удалась
  * GET: не найдено
* 405 Method Not Allowed
  * Другие методы
* 500 Internal Server Error
  * Произошла неизвестная ошибка
* 507 Insufficient Storage
  * Превышен размер данных

## Заголовки

Поддерживаемые заголовки в запросе

| Имя | Значение | Описание
| --- | --- | ---
| content-type | Любое | Будет возвращено как есть в GET-запросе
| cache-control | s-maxage или max-age | Используется для установки ttl, когда правило.ttl равно auto

## Данные для разных пользователей

Добавляя заголовок, cookie и другие данные в ключ, можно хранить данные разных пользователей по одному и тому же пути.

### Set

### Get

## Клиент

Поддерживает любой клиент, поддерживающий HTTP, библиотеки: curl, postman, python requests, go net/http и др.

# Управление

Можно определить endpoint с помощью uri и отправить HTTP-запрос для управления.

**Определение и включение**

## Методы ##

| Метод | Endpoint | Описание
| ------ | -------- | -----------
| GET | /internal/nuster | Получение статистики
| POST | /internal/nuster | Включение/отключение правил, обновление ttl
| DELETE | /internal/nuster | Расширенная очистка
| PURGEX | /any/real/path | Базовая очистка

## Статистика

Можно получить статистическую информацию, отправив GET запрос на определённый endpoint.

### Использование

`curl http://127.0.0.1/nuster`

### Вывод

**Перевод данных на русский язык:**

Хранилище. Диск. NoSQL. Каталог: /tmp/nuster/nosql
Загружено хранилище. Диск. NoSQL: Да

STATS
Статистика. Кэш. Всего: 0
Статистика. Кэш. Попадание: 0
Статистика. Кэш. Извлечение: 0
Статистика. Кэш. Обход: 0
Статистика. Кэша. Прерывание: 0
Статистика. Кэш. Байты: 0
Статистика. NoSQL. Всего: 0
Статистика. NoSQL. Получить: 0
Статистика. NoSQL. Опубликовать: 0
Статистика. NoSQL. Удалить: 0

PROXY кэш app1
Правило app1. Правило. Rule1: состояние = включено, память = включено, диск = выключено, TTL = 10
Правило app1. Правило. Rule2: состояние = включено, память = включено, диск = включено, TTL = 10
Правило app1. Правило. Rule3: состояние = включено, память = включено, диск = синхронизировано, TTL = 10
Правило app1. Правило. Rule4: состояние = включено, память = выключено, диск = включено, TTL = 10
Правило app1. Правило. Rule5: состояние = включено, память = выключено, диск = выключенное, TTL = 10

PROXY NoSQL app2
Правило app2. Правило. RuleA: состояние = включено, память = включено, диск = выключено, TTL = 10
Правило app2. Правило. RuleB: состояние = включено, память = включено, диск = включено, TTL = 10
Правило app2. Правило. RuleC: состояние = включено, память = включено, диск = синхронизировано, TTL = 10
Правило app2. Правило. RuleD: состояние = включено, память = выключено, диск = включено, TTL = 10
Правило app2. Правило. RuleE: состояние = включено, память = выключено, диск = выключенное, TTL = 10
## Включение и выключение правила

Правила можно динамически включать и выключать через manager URI. Выключенные правила больше не будут обрабатываться.

Заголовки
| Заголовок | Значение | Описание
| --------- | -------- | -----------
| Состояние | Включить | Включить правило
| | Выключить | Выключить правило
| Имя | Правило ИМЯ | Правило для включения/выключения
| | Прокси ИМЯ | Все правила прокси ИМЯ
| | * | Все правила

Все правила с одинаковым именем будут включены или выключены.

Примеры
* Выключить правило r1
  `curl -X POST -H "имя: r1" -H "состояние: выключить" http://127.0.0.1/nuster`

* Выключить все правила backend app1b
  `curl -X POST -H "имя: app1b" -H "состояние: выключить" http://127.0.0.1/nuster`

* Включить все правила
  `curl -X POST -H "имя: *" -H "состояние: включить" http://127.0.0.1/nuster`
## Изменение времени жизни

Изменение TTL влияет только на последующие новые кэши, но не на существующие кэши.

Заголовки
| Заголовки | Значение | Описание
| ---------- | ------- | -----------
| TTL | Новый TTL | См. `ttl` в `nuster rule`
| Имя | Правило ИМЯ | Правило, которое нужно изменить
| | Прокси ИМЯ | Все правила прокси ИМЯ
| | * | Все правила

Примеры

### Одновременное установка состояния и TTL

Одновременная установка состояния и TTL.

## Очистка

Существует два режима очистки:

* Базовая очистка: отправка метода `purge-method MYPURGE`, определённого для удаления пути
* Расширенная очистка: отправка DELETE на manager URI

### Базовая очистка: удаление одного конкретного URL

`curl -XPURGE http://127.0.0.1/imgs/test.jpg`

На основе правила генерируется ключ и удаляется этот ключ. Это применимо только к кэшам, созданным при GET запросах.

По умолчанию ключ содержит `Host`. Если кэш был создан с использованием `http://example.com/test`, а удаление выполняется на localhost, необходимо использовать заголовок `Host`:

`curl -XPURGE -H "Host: example.com" http://127.0.0.1/test`

Это применимо как к кэшу, так и к NoSQL, где режим NoSQL эквивалентен `DELETE`.

### Расширенная очистка: по имени

Можно удалить, используя заголовок `name`.

Заголовки
| Заголовок | Значение | Описание
| ------ | ----- | -----------
| имя | nuster правило ИМЯ | кэши правила ИМЯ будут удалены
| | прокси ИМЯ | кэши прокси ИМЯ
| | * | все кэши

Примеры

### Расширенная очистка: по хосту

Используя заголовок `nuster-host`, можно удалить все данные, принадлежащие этому хосту.

Заголовки
| Заголовок      | Значение        | Описание
| -----      | -----        | -----------
| Хост        | HOST         | хост ${HOST}
| nuster-host | HOST         | если существует nuster-host, то используется nuster-host
| Режим        | кэш, nosql | очистить кэш или данные nosql

Примеры

### Расширенная очистка: по пути

По умолчанию часть запроса также включается в ключ, поэтому разные запросы с одним и тем же путём, но разными параметрами запроса, создают разные кэши.

Например, `nuster правило imgs, если { path_beg /imgs/ }`, затем запрос

Создаст два кэша, потому что запросы разные.

Если эти кэши должны быть удалены, можно **Если известен весь query, то можно удалять по одному:**

В большинстве случаев не известен весь query.  

**Если часть query не важна, то её можно удалить из ключа:**  

Определить `nuster rule imgs key method.scheme.host.path if { path_beg /imgs }`, тогда будет создан только один кэш, и не нужно будет удалять query для очистки кэша.  

`curl -XPURGE http://127.0.0.1/imgs/test.jpg`  

В большинстве случаев query важен.  

**Удалить через название правила:**  

`curl -X PURGE -H "name: imgs" http://127.0.0.1/nuster/cache`  

Но если правило определено как `nuster rule static if { path_beg /imgs/ /css/ }`, то нельзя удалить только imgs.  

Поэтому можно удалить через путь.  

**Заголовки:**  
| Заголовок | Значение | Описание |  
|:---------|:---------|:--------|  
| path | PATH | Кэши с ${PATH} будут удалены |  
| host | HOST | И host равен ${HOST} |  
| nuster-host | HOST | nuster-host имеет более высокий приоритет над host |  
| mode | cache, nosql | Очистить кэш или данные nosql |  

**Примеры:**  

### Расширенная очистка: удаление через регулярное выражение  

Можно также удалить через регулярное выражение, все соответствующие регулярному выражению кэши будут удалены.  

**Заголовки:**  
| Заголовок | Значение | Описание |  
|:---------|:---------|:--------|  
| regex | REGEX | Кэши, путь которых соответствует ${REGEX}, будут удалены |  
| host | HOST | И host равен ${HOST} |  
| nuster-host | HOST | nuster-host имеет более высокий приоритет над host |  
| mode | cache, nosql | Очистить кэш или данные nosql |  

**Примеры:**  

*Примечание: в тексте запроса есть код на языке программирования YAML, но он не содержит информации, необходимой для перевода.* # HTTP-буферный запрос должен быть включён для кэширования POST-запроса
    option http-buffer-request

    acl pathPost путь /search

    # включить кэш для этого прокси
    nuster cache

    # кэшировать /search на 120 секунд. Работает только при POST/PUT
    nuster rule rpost ключ method.scheme.host.uri.body ttl 120 если pathPost

    сервер s1 10.0.0.10:8080
бэкенд app1b
    баланс roundrobin
    режим http

    nuster cache on

    # кэширование /a.jpg, без истечения срока действия
    acl pathA путь /a.jpg
    nuster правило r1 ttl 0 если pathA

    # кэширование /mypage, ключ содержит cookie[userId], поэтому он будет кэшироваться для каждого пользователя
    acl pathB путь /mypage
    nuster правило r2 ключ method.scheme.host.path.delimiter.query.cookie_userId ttl 60 если pathB

    # кэширование /a.html, если заголовок ответа [cache] равен yes
    http-запрос set-var(txn.pathC) путь
    acl pathC var(txn.pathC) -m str /a.html
    acl resHdrCache1 res.hdr(cache) yes
    nuster правило r3 если pathC resHdrCache1

    # кэширование /heavy на 100 секунд, если be_conn больше 10
    acl heavypage путь /heavy
    acl tooFast be_conn ge 100
    nuster правило heavy ttl 100 если heavypage tooFast

    # кэширование всего, если заголовок ответа [asdf] равен fdsa
    acl resHdrCache2 res.hdr(asdf)  fdsa
    nuster правило resCache ttl 0 если resHdrCache1

    сервер s1 10.0.0.10:8080

фронтенд web2
    привязать *:8081
    режим http
    default_backend app2
бэкэнд app2
    баланс roundrobin
    режим http

    # отключить кэш на этом прокси
    nuster cache off
    nuster правило all

    сервер s2 10.0.0.11:8080

фронтенд nosql_fe
    привязать *:9090
    default_backend nosql_be
бэкэнд nosql_be
    nuster nosql on
    nuster правило r1 ttl 3600