menuTicketing
light_mode
languageРусский
close
Введение
Принцип работы
Протокол (API)
Протокол (кластер)
Библиотеки
Сервис

Развёртывание Ticketing Server

Docker Hub / Github
Окружение
Режим
expand_moreДополнительно (сокет · sweep)
bash
Пример клиентского подключения
rust
Быстрая проверка через nc
bash

Переменные окружения ​

Каждый параметр (опционального) ticketing.toml можно также задать через переменную окружения. Приоритет: переменная окружения > ticketing.toml > значение по умолчанию, ключи и булевы значения регистронезависимы. Docker-образ основан на scratch, поэтому конфигурация через переменные окружения — вариант по умолчанию (чтобы использовать файл конфигурации, смонтируйте его и укажите путь через CONFIG).

Переменная окруженияПо умолчаниюОписание
PORT (SERVER_PORT)5225TCP-порт прослушивания. Игнорируется в кластерном режиме — используется порт из CLUSTER_SELF
DEBUG (SERVER_DEBUG)зависит от сборки1/true — включает debug-логирование
SOCKET_BIND0.0.0.0Адрес прослушивания
SOCKET_NODELAYtrueTCP_NODELAY
SOCKET_READ_BUF_LEN4096Буфер чтения на соединение (байт)
SOCKET_REPLY_QUEUE1024Длина очереди ответов на соединение
SOCKET_REPLY_BATCH64Максимальное число ответов, объединяемых в одной операции write
SWEEP_INTERVAL_SECS5Периодичность очистки истёкших ключей (сек.)
CLUSTER_SELF(нет)Адрес объявления этого узла host:port. Если задан — кластерный режим
CLUSTER_PEERS(нет)Список адресов узлов (через запятую). Порядок = приоритет повышения, должен включать self, минимум 2
CONFIG./conf/ticketing.tomlПуть к файлу конфигурации

Single vs Cluster ​

  • Single (1 узел): если [cluster] (или CLUSTER_*) не задан — одиночный узел. Самый быстрый вариант, но при перезапуске возникает короткий простой, а состояние хранится в памяти и исчезает при перезапуске (lease служит страховкой).
  • Cluster (без простоя): минимум 2 узла. Каждый узел имеет одинаковый CLUSTER_PEERS (в порядке приоритета) и CLUSTER_SELF, указывающий на самого себя. Среди живых узлов тот, у кого приоритет выше, становится активным, остальные — стендбай и получают репликацию в реальном времени. Подробнее о принципе работы см. Принцип работы и Протокол — сервер ↔ сервер.

Для развёртывания кластера в Kubernetes используется StatefulSet + headless-сервис. Каждый под получает стабильное DNS-имя (ticketing-0.ticketing…, ticketing-1.ticketing…); эти имена в порядке приоритета указываются в CLUSTER_PEERS, а CLUSTER_SELF каждого пода автоматически подставляется через downward API (metadata.name).

Бесперебойный (поочерёдный) перезапуск ​

  1. Сначала перезапустите стендбай-узлы, по одному (активный узел продолжает обслуживание).
  2. Наконец, остановите активный узел (Ctrl+C) — через хэндовер стендбай повышается, и клиенты переключаются на него.
  3. Поднимите бывший активный узел заново — он присоединяется как стендбай к текущему активному узлу (автоматического фейлбэка нет).

См. также ​

  • Образ: sarolab/ticketing · Github: saro-lab/ticketing
  • В клиенте (брокере) регистрируйте адреса всех узлов, чтобы при сбое происходило автоматическое переключение. Особенности использования для каждого языка см. в разделе Библиотеки.
arrow_back
Назад
C/C++ (vcpkg)