Messaging-статей на сайте набралось достаточно, чтобы в них запутаться: NATS, RabbitMQ, Kafka, отдельная статья о выборе брокера, гарантии доставки, транзакции в очереди и в логе, стриминг и CDC, Flink. Каждая статья хороша сама по себе, но вопрос читателя обычно не «расскажите про Kafka», а «мне нужно доставить событие между сервисами (или обработать поток) — какой инструмент брать и чего от него ожидать». Эта карта — не новая статья про messaging, а слой навигации над уже написанным: она раскладывает материал по осям и достраивает то, что ещё не написано, в те же оси, чтобы было видно, куда двигаться дальше.
Раскладка задаёт не хронологию публикаций, а логику выбора: сначала модель данных (что вообще за инструмент — очередь, лог или шина субъектов), затем гарантии, которые он даёт, затем то, что стоит за словом «эксплуатация» в проде, и отдельно — обработка потоков, где брокер уже не конечная точка, а часть пайплайна. Карта живая: часть статей выходит позже основного материала (Kafka — с 27 июля, Flink — с середины августа, стриминг и CDC — с конца августа), и ссылки на них до выхода показаны плашкой «готовится» вместо рабочей ссылки — так карта остаётся честной картой, а не списком заглушек.
В статье
- Что связывает этот хаб
- Модель: очередь, лог, шина
- Гарантии доставки
- Эксплуатация
- Обработка потоков
- С чего начать
- Соседние карты
Что связывает этот хаб
Четыре оси, по которым разложены статьи:
- Модель — очередь (RabbitMQ), лог (Kafka, Pulsar), шина субъектов (NATS): как устроено хранение и адресация сообщений и что из этого следует для читателя и писателя.
- Гарантии доставки — at-most-once/at-least-once/exactly-once, идемпотентность, порядок сообщений: что конкретный брокер и конкретный паттерн реально гарантируют, а что нужно достраивать на стороне приложения.
- Эксплуатация — HA и failover, мониторинг, безопасность, обновление кластера без простоя: то, что отличает «поднял на ноутбуке» от «работает в проде третий год».
- Обработка потоков — CDC, stream processing, событийные пайплайны, вплоть до аналитики: брокер как часть конвейера, а не как конечная точка.
Две из этих осей — модель и гарантии — задают квадрант, на котором видно, где по смыслу стоит каждая система:
Одна и та же статья может быть релевантна нескольким осям — например, статья про exactly-once в Kafka в первую очередь про гарантии, но неотделима от модели лога с партициями. Группировка ниже — по основному вопросу, который статья закрывает.
Модель: очередь, лог, шина
Отправная точка — статья, которая явно ставит вопрос выбора: Как выбрать брокер: RabbitMQ, Kafka, NATS. Она задаёт словарь: очередь удаляет сообщение после обработки, лог хранит его и позволяет перечитывать, шина субъектов маршрутизирует по паттерну подписки почти без хранения. Дальше — как этот словарь реализован в конкретных системах.
NATS начинается с модели субъектов и request/reply, ортогональной и очереди, и логу: NATS: subjects, Core, request/reply. Kafka — с модели лога: партиции как единица параллелизма и порядка, топик как именованный поток, Kafka: лог, топики, партицииготовится, с 29 июля; над этой моделью — механика чтения, Kafka: consumer groups и ребалансировкаготовится, с 31 июля; и механика хранения, определяющая, как долго лог живёт и что происходит со старыми записями, Kafka: retention и log compactionготовится, с 6 августа. Отдельный вопрос — существует ли альтернатива логу Kafka с другой архитектурой хранения (разделение брокеров и слоя хранения через Apache BookKeeper — сегменты как ledger’ы на bookies, — с опциональным offload старых сегментов в объектный сторадж и встроенным multi-tenancy): Pulsar против KafkaСкоро.
Гарантии доставки
Гарантии доставки — это не свойство брокера вообще, а свойство конкретной конфигурации и конкретного паттерна её использования. В RabbitMQ это durability очереди, publisher confirms, ручной ack и dead letter exchange как страховка от сообщений, которые не удаётся обработать: RabbitMQ: durability, confirms, ack, DLQ. В NATS постоянство и at-least-once (а при аккуратном использовании — exactly-once на уровне consumer) появляются только с JetStream — сам Core NATS из раздела «Модель» durable-гарантий и persistence не даёт, это at-most-once доставка без хранения: NATS JetStream: persistence и гарантии доставки. В Kafka надёжность — это в первую очередь репликация партиций и настройка acks/ISR: Kafka: репликация и надёжность (ISR, acks)готовится, с 4 августа, а строгое exactly-once поверх этого — отдельный механизм транзакций продюсера: Kafka: exactly-once и транзакцииготовится, с 7 августа.
Отдельная от брокера, но неотделимая от темы гарантий проблема — как сохранить консистентность между записью в БД и отправкой события, не полагаясь на распределённую транзакцию: Transactional Outbox/Inbox. А связь темы гарантий с транзакциями БД в целом, включая то, чем «транзакция» в очереди отличается от транзакции в СУБД, разобрана в Транзакции: брокеры (RabbitMQ/Kafka).
Эксплуатация
Эксплуатационный слой у всех трёх систем закрывает одни и те же вопросы — отказоустойчивость кластера, мониторинг, безопасность, обновление без простоя — но решает их по-разному. У NATS это классический кластер на routes и RAFT для JetStream: NATS: кластер, RAFT, failover, multi-tenancy и авторизация через accounts и JWT: NATS: accounts, JWT, безопасность, и повседневная эксплуатация через CLI и мониторинг: NATS: эксплуатация и мониторинг.
У RabbitMQ — отказоустойчивость через quorum-очереди: RabbitMQ: quorum-очереди и failover, связывание нескольких кластеров через Federation и Shovel, когда один кластер недостаточен: RabbitMQ: Federation и Shovel, продакшн-чеклист и мониторинг: RabbitMQ: мониторинг и продакшн-чеклист, и Streams — режим, в котором RabbitMQ начинает вести себя как лог, а не как очередь, вплотную приближаясь по use case к Kafka: RabbitMQ Streams: Kafka-подобный лог.
У Kafka эксплуатация сосредоточена в одной статье про KRaft, тюнинг и обновление кластера без внешней зависимости от ZooKeeper: Kafka: эксплуатация (KRaft, тюнинг)готовится, с 11 августа.
Обработка потоков
Здесь брокер перестаёт быть конечной точкой и становится частью конвейера. Экосистема Kafka вокруг самого брокера — Connect для интеграции с внешними системами и Schema Registry для контракта данных в потоке — мост между «просто брокером» и полноценным стримингом: Kafka: экосистема (Connect, Schema Registry)готовится, с 12 августа.
Дальше — серия про стриминг и обработку данных целиком: захват изменений из БД в лог, CDC через Debezium: PostgreSQL → Kafkaготовится, с 6 сентября; сравнение двух моделей обработки потока, встроенной в брокер и внешнего движка, Stream processing: Kafka Streams vs Flinkготовится, с 7 сентября; и проектирование самого пайплайна — сквозные гарантии, дедупликация, порядок, Пайплайны событий: доставка и порядокготовится, с 8 сентября. Куда поток приходит дальше, когда стоком служит не Kafka и не ClickHouse, а объектное хранилище, — это уже вопрос слоя хранения, а не messaging: открытые табличные форматы поверх озера разбирает Iceberg/Delta: открытые табличные форматыСкоро. Рядом — практический вопрос, как вообще увидеть поток, прежде чем его отлаживать: Визуализаторы событийных потоковСкоро.
Отдельный блок — Flink вглубь, для тех, кому «Kafka Streams vs Flink» выше уже недостаточно: модель dataflow, event-time и watermarks, Flink: dataflow, event-time, watermarksготовится, с 25 августа; состояние и exactly-once через checkpoints/savepoints, Flink: состояние и exactly-onceготовится, с 27 августа; и Flink SQL с коннекторами в проде, Flink SQL, коннекторы, эксплуатацияготовится, с 28 августа.
С чего начать
Три маршрута — в зависимости от того, с каким вопросом пришли:
- Выбор. Как выбрать брокер: RabbitMQ, Kafka, NATS → затем модельная статья нужной системы: NATS: subjects, Core, request/reply или Kafka: лог, топики, партицииготовится, с 29 июля → и дальше в её серию по эксплуатации.
- Надёжность. RabbitMQ: durability, confirms, ack, DLQ или Kafka: репликация и надёжность (ISR, acks)готовится, с 4 августа → Transactional Outbox/Inbox → Транзакции: брокеры (RabbitMQ/Kafka).
- Данные в потоке. CDC через Debezium: PostgreSQL → Kafkaготовится, с 6 сентября → Stream processing: Kafka Streams vs Flinkготовится, с 7 сентября → Flink: dataflow, event-time, watermarksготовится, с 25 августа → Iceberg/Delta: открытые табличные форматыСкоро.
Соседние карты
Messaging — не единственный хаб. Рядом:
- Данные: карта хранилищ и подходовготовится, с 22 сентября — если вопрос не «как доставить событие», а «где и как хранить данные».
- Надёжность распределённых систем — карта — надёжность как сквозная тема поверх messaging, БД и сетевого слоя.
- Consensus Landscape — для тех, кто хочет понять, что стоит за Raft-группами JetStream в NATS или репликацией партиций в Kafka, на уровне алгоритмов консенсуса.
Комментарии