Настройка NATS с JetStream и кластеризацией для продакшена

Почему NATS теряет сообщения под нагрузкой

На стенде NATS держит поток ровно, поэтому первый пик в продакшене выглядит как загадка: часть сообщений просто не доезжает. В логах отправителя — тишина, в метриках — всплеск отказов, а в очереди остаются дыры, которые потом восстанавливают сверкой с внешним источником. Потеря сообщений складывается из трёх причин: разрыв соединения в момент переключения узла, переполнение очереди у медленного потребителя и отсутствие подтверждений на стороне отправителя.

Переключение узла — самый частый сценарий разрыва. Лидер уходит, кластер обмена сообщениями выбирает нового, а клиент в эти доли секунды пишет в мёртвый сокет и считает данные доставленными. Если повторная отправка и подтверждения не настроены, эти сообщения теряются молча, без ошибки на клиенте. Тот же механизм даёт дубли, когда повтор включён, но обработчик не идемпотентен: одно событие проходит дважды и ломает состояние.

Второй источник — задержки доставки и переполнение очереди. Когда потребитель не успевает, поток растёт до лимита хранения, и дальше либо срабатывает политика вытеснения старых записей, либо отправитель получает отказ на запись. На пиках это выглядит как рваный поток: часть событий приходит с опозданием, часть исчезает, а очередь восстанавливается рывком и добивает обработчик отложенной пачкой.

Разбираем, как это закрывается: подтверждения и повторная доставка в потоках JetStream, идемпотентные обработчики, размеры потоков и политики хранения под реальный профиль нагрузки, переподключение клиентов с сохранением буфера и проверки состояния узлов.

Что даёт отказоустойчивый кластер обмена сообщениями

Отказоустойчивый кластер NATS — это не «поставили три копии и забыли». Его эффекты проверяются до боевого запуска: гасим узел под нагрузкой, смотрим метрики и решаем, готовы ли к реальному сбою.

• Отказ узла не останавливает поток. Кворум из трёх узлов сохраняет запись, когда одна машина выпадает: публикация и подписка идут через живые узлы, клиенты переподключаются сами. Время восстановления потока — секунды вместо простоя сервиса.

• Гарантия доставки задаётся явно. Сообщения лежат на диске до подтверждения обработки, поэтому перезапуск сервиса-получателя не приводит к потере. Повторные обработки ограничены дедупликацией и видны в метриках, а не при разборе инцидента.

• Пиковая нагрузка не превращается в отказы. Если публикация идёт быстрее обработки, разница оседает в буфере хранения, а не в ошибках на входе — сервис остаётся доступным на всплеске.

• Обновления идут без ручных перезапусков. Узлы перезапускаются по одному, кворум сохраняется, дежурный не поднимает упавший процесс руками.

• Границы нагрузки заданы заранее. Лимиты на получателя и разделение потоков по назначению не дают одному сервису забрать ресурсы у остальных — деградация остаётся локальной.

Каждый пункт подтверждаем на учениях: гасим узел под нагрузкой, поднимаем трафик выше расчётного, обновляем кластер на живом потоке. Результат — сервис переживает отказ машины и пик без ручного вмешательства.

Режимы NATS: поток, очередь и постоянное хранилище

Режимы NATS решают разные задачи, и выбор между ними определяется одним вопросом: что должно произойти с сообщением, если получатель в момент отправки недоступен. Базовый режим отдаёт событие всем подписчикам темы сразу и нигде его не сохраняет. Очередь работ распределяет поток между экземплярами сервиса — сообщение уходит ровно одному исполнителю. Постоянное хранилище JetStream записывает поток на диск и позволяет перечитать его после перезапуска.

Выбор подсказывает сам характер данных: то, потерю чего можно пережить, идёт по теме без лишних накладных расходов; то, что требует повторной обработки, — через JetStream с подтверждением доставки. Комбинировать режимы в одной инсталляции нормально: подписка на тему и очередь используют один транспорт, поэтому переход между ними — это правка настроек подписчика, а не переписывание сервиса.

Хранилище включают точечно, только для нужных тем, чтобы не платить диском за весь трафик. Лимит по возрасту или объёму задаётся политикой хранения — поток перестаёт расти, а повторная обработка после сбоя остаётся возможной.

Как мы разворачиваем кластер: этапы работ

Кластер NATS собирается не по типовой инструкции, а под конкретный профиль обмена: одному сервису важна каждая заявка, другой публикует телеметрию с допустимыми потерями. Порядок работ у нас фиксирован — он позволяет ловить ошибки топологии на стенде, а не тогда, когда очередь уже встала.

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

2. Проектирование схемы. Определяем состав кластера, число реплик для стримов, лимиты хранения и политики очистки. Схема сразу ложится в конфигурацию в репозитории, а не в документ «на память».

3. Настройка кластера. Разворачиваем узлы, объединяем в кластер, включаем JetStream, задаём кворум, права доступа и шифрование трафика между узлами. Подключаем метрики и оповещения по отставанию потребителей.

4. Проверка отказом. Гасим узлы по одному и парами: смотрим перевыборы лидера, время восстановления, доступность публикации и подписки, отсутствие дублей и потерь. На выходе — замеры, а не обещания.

5. Передача в эксплуатацию. Отдаём конфигурации, инструкции по развёртыванию и восстановлению, описание схемы и дежурные сценарии. Ваши инженеры повторяют развёртывание на чистом контуре без подсказки.

6. Сопровождение. Следим за здоровьем кластера, планово обновляем версии, расширяем при росте нагрузки, разбираем инциденты с вашей командой.

Конфигурации, схемы и регламенты на выходе

Артефакты передаём не «архивом на память», а рабочим комплектом: любую из перечисленных сущностей ваша команда сможет прочитать, изменить и развернуть без нас. Всё лежит в вашем репозитории, версионируется и проходит проверку на стенде — мы прогоняем конфигурации через тестовый кластер и убеждаемся, что они воспроизводятся с нуля.

• Конфигурации узлов — файлы настроек каждого узла с пояснениями по ключевым параметрам: лимиты хранилища, окна хранения сообщений, таймауты, поведение при потере кворума.
• Схема кластера — топология маршрутов, зоны отказа, точки балансировки, порядок добавления и вывода узла на обслуживание.
• Схема тем и подписок — карта потоков и очередей: кто публикует, кто читает, какие группы подписчиков делят нагрузку, где включено повторное воспроизведение.
• Политики прав доступа — по учётным записям и пространствам: кто вправе публиковать, кто только читать, кому закрыт административный контур, как выдаются и отзываются ключи.
• Регламент эксплуатации — плановые работы, контроль роста хранилища, ротация логов, порядок обновления узлов без остановки обмена.
• Инструкции по восстановлению — сценарии на случай потери узла или зоны: что снимается из резерва, в какой последовательности поднимается, как проверяется целостность.
• Мониторинг и оповещения — набор метрик и порогов, при которых дежурный получает сигнал раньше, чем проблема дойдёт до бизнес-логики.
• Передача знаний — разбор с вашими инженерами по каждому артефакту, чтобы команда вела систему самостоятельно.

Комплект закрывает полный цикл: развернуть с нуля, изменить конфигурацию без простоя, откатить неудачное обновление и передать систему другому подрядчику без археологии. Опишите задачу — вернёмся с оценкой и планом.

Кейс: кластер NATS вместо самописной очереди

Компания с биллингом и массовыми рассылками держала очередь задач на самописном решении: воркеры выбирали строки из реляционной таблицы по флагу статуса, а согласованность держалась на блокировках. На пиках таблица упиралась в конкуренцию за строки, задания дублировались, часть событий пропадала без следа — разбор такого инцидента занимал вечер и требовал ручной сверки с логами сервисов.

Что было до

Доля потерянных сообщений в часы пик достигала 0,3–0,5% от потока, и в этих процентах оказывались подтверждения оплаты. Восстановление узла после падения занимало около 40 минут: воркеры не перераспределяли задания сами, дежурный поднимал их руками. Ручных вмешательств набиралось 8–12 в месяц — каждое отрывало инженера от плановых задач и сдвигало сроки.

Что сделали

Развернули кластер NATS с JetStream: потоки с дисковой персистентностью и репликацией на несколько узлов, потребители с явным подтверждением доставки и повторной выдачей при ошибке обработчика. Обработчики сделали идемпотентными по ключу события, чтобы повтор был безопасен, а разбор «зависших» заданий заменили на автоматическую повторную выдачу по таймауту.

Что стало

На критичном потоке подтверждений оплаты потери сообщений — ноль, включая пиковые окна. Узел возвращается в строй меньше чем за минуту: потребители переподключаются к живым репликам сами, ручной подъём больше не нужен. Вмешательства дежурного сократились до плановых обновлений, а зависшие задания видны в метриках потока, а не выясняются по жалобам.

Отдельный эффект — предсказуемость отката: состояние очереди хранится на диске, поэтому перезапуск сервиса не означает потерю накопленного потока.

Чем кластер NATS отличается от одиночного брокера

Одиночный узел NATS — один процесс и одно хранилище: пока он жив, публикация и подписка идут с минимальной задержкой, конфигурация читается из одного файла, а эксплуатация сводится к перезапуску службы. Точка отказа ровно одна, и она совпадает с точкой остановки всего обмена между сервисами.

Кластер — три и более узла, связанных маршрутами: они образуют кворум, переизбирают лидера и держат копии потоков JetStream на разных узлах. Отказ одного узла публикацию не прерывает: клиенты переподключаются к выжившим, а поток восстанавливается из копии. Но если выпадут два узла из трёх, запись встанет до возвращения третьего — осознанная плата за согласованность данных.

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

Частые технические сомнения перед стартом

Перед стартом инженеры заказчика проверяют не нас, а совместимость с уже работающим контуром. Ниже — пять вопросов, которые звучат чаще всего, с короткими ответами по существу.

Как понять, что кластер выдержит нашу нагрузку?

Снимаем профиль реального потока — темы, размер сообщений, долю подтверждений, пики — и прогоняем на тестовом контуре. Смотрим, где растут задержки и как ведёт себя хранилище при отказе одного узла.

У нас уже развёрнут обмен — переезд без простоя возможен?

Переводим по темам, а не целиком: часть времени сообщения идут в оба контура, потребители переключаются по готовности. Старый маршрут отключаем после сверки, поэтому простоя у потребителей нет.

Настройки разъехались между средами — как это лечится?

Конфигурацию переносим в репозиторий и описываем декларативно: один источник правды для всех сред, различия только в параметрах окружения. Расхождения проверяются автоматически перед выкаткой.

Что будет, если новая конфигурация окажется неудачной?

Возврат занимает минуты: конфигурация версионируется, а накопленные сообщения остаются в хранилище и не теряются при перезапуске. Схему отката фиксируем и проверяем на тестовом контуре заранее.

Обсудим вашу задачу обмена сообщениями

Чтобы оценка и план опирались на факты, а не на предположения, нам нужны исходные данные по вашему контуру обмена сообщениями. Чем точнее вы опишете схему и профиль нагрузки, тем меньше допущений заложим в кластер и политику хранения — и тем предсказуемее будут сроки.

• Схема обмена: кто публикует, кто и в каких группах читает, сколько потоков и подписок, что происходит при всплеске.
• Профиль нагрузки: сообщений в секунду в пике и в среднем, типичный и максимальный размер сообщения.
• Требования к сохранности: допустимая потеря при сбое узла, глубина хранения, нужен ли повтор доставки при отказе потребителя.
• Контур развёртывания: свой сервер или облако, сколько зон, какие каналы связи между узлами и как устроен доступ.
• Текущее состояние: что уже поднято, где наблюдаете узкие места, есть ли журналы, метрики и описания прошлых отказов.
• Организационные рамки: желаемые сроки запуска, окна для работ, кто с вашей стороны принимает результат.

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