</>
halfcoder

Гайды

Введение в NATS: легковесная шина сообщений

Core vs JetStream, subject и wildcards, queue groups, request-reply, Docker, безопасность и чек-лист.

~9 мин чтения

ОчередиNATSОбмен сообщениями

Введение в NATS: легковесная шина сообщений

NATS — лёгкий высокопроизводительный message broker с минимальной операционной нагрузкой. Ядро — pub/sub по subject (строковые имена с иерархией orders.us.created), request-reply, очереди queue group на subscribers. Сравнение с тяжёлыми брокерами — RabbitMQ vs Kafka; у Kafka — Apache Kafka: основы.

1. Режимы использования

РежимОписание
Core NATSIn-memory fire-and-forget pub/sub; очень быстро; без персистентности по умолчанию
JetStreamПерсистентные streams, consumer с ack, replay, retention
Leaf nodesРасширение edge → hub топологии

Без JetStream поведение ближе к Redis Pub/Sub по гарантиям; с JetStream — к «лёгкой» очереди с журналом. См. Redis Pub/Sub и очереди.

2. Subject и wildcards

  • orders.* — один токен на месте *.
  • orders.> — хвост из нуля или более токенов.

Соглашения по именам — часть контракта между командами.

3. Queue groups

Несколько subscriber'ов с одинаковым queue name образуют queue group: каждое сообщение доставляется одному члену (балансировка нагрузки), в отличие от чистого pub/sub, где все получают копию.

4. Request-reply

Publisher шлёт запрос с reply subject; subscriber отвечает в этот inbox. Удобно для синхронных RPC поверх NATS с низкой задержкой.

5. JetStream (концепты)

  • Stream — именованный журнал с политикой retention (limits, interest, workqueue).
  • Consumer — push/pull, durable имя, ack (Ack, Nak, Term).
  • Exactly-once в полном смысле всё равно упирается в идемпотентность обработчика.

6. Установка

bash
docker run -d --name nats -p 4222:4222 -p 8222:8222 nats:2 -js -m 8222

-js включает JetStream; 8222 — HTTP мониторинг.

CLI (nats из пакета nats-io/natscli) ускоряет отладку без кода:

bash
nats pub demo.hello "ping"
nats sub "demo.>"

Для JetStream: nats stream ls, nats consumer add. В проде задавайте имя соединения и ping interval в клиенте — проще коррелировать разрывы в логах.

Переподключение: в Go-клиенте типичны опции вроде MaxReconnect, ReconnectWait, ReconnectJitter; включайте обработчик отключения (DisconnectedErrHandler), логируйте причину и backoff, чтобы не устроить шторм к брокеру при массовом рестарте приложений.

7. Когда NATS уместен

  • Control plane, live updates, микросервисная шина с низкой задержкой.
  • Edge / IoT с leaf nodes.
  • Когда Kafka избыточен по эксплуатации, а Rabbit — по протоколу/стеку.

Менее уместен как единственный долгоживущий analytics log на петабайты — туда чаще Kafka/облачные логи.

8. Безопасность

Nkeys, JWT, TLS, accounts (multi-tenant изоляция в 2.x). Не оставляйте открытый 4222 в интернете.

9. Лимиты и slow consumers

Max pending / slow consumer policy — без лимитов быстрый продьюсер может исчерпать память брокера, если клиент не читает. Настройте max_payload, max_connections под ваш SLO.

10. Supercluster и маршрутизация

Несколько региональных кластеров gateway-ами связывают supercluster; задержка и политика маршрутизации subject'ов должны быть явно описаны в runbook.

11. Чек-лист

  • Решено: Core vs JetStream под требования retention/ack.
  • Дисциплина subject'ов и документация контрактов.
  • Мониторинг /varz, /connz, JetStream RAFT при кластере.
  • TLS между клиентами и сервером в проде.
  • Резервное копирование JetStream store при персистентных стримах.

Дальше: RabbitMQ vs Kafka · Тег NATS