Черги повідомлень: RabbitMQ, Kafka
Черги повідомлень: RabbitMQ, Kafka
1) Коли що вибирати
RabbitMQ (AMQP 0-9-1 / 1. 0, класичні черги, Quorum Queues, Streams)
Підходить для: RPC/команд, workflow, коротких завдань, fanout/topic маршрутизації, гнучких підтверджень, управління пріоритетами.
Плюси: багата семантика маршрутизації (exchanges),'basic. qos'( prefetch), per-message TTL/delay, зручні патерни RPC (reply-to), легкий старт.
Мінуси: історія зберігається в черзі, горизонтальне масштабування по чергах/шардах; висока Throughput-вартість при дуже великих потоках.
Apache Kafka (лог подій, партії, consumer groups)
Підходить для: потоків подій, аудиту, event sourcing, ETL/інтеграцій (Connect), високих RPS/MBps, реплей/ре-процесинг, стрім-процесингу (Streams/ksqlDB).
Плюси: довготривалий журнал, масштабування по партіях, стійкий реплей, компактування ключів.
Мінуси: модель «pull + партії» - не для дрібного RPC; порядок тільки в межах партії; управління схемами/сумісністю - обов'язок команди.
2) Семантики доставки та інваріанти
At-most-once: без ретраїв; швидко, ризик втрати.
At-least-once: з ретраями; потребує ідемпотентності споживача.
Exactly-once: досяжно в обмежених умовах (Kafka TX + ідемпотентний продьюсер + узгоджений sink; RabbitMQ - через таблицю дедупа/ідемпотентні ключі).
Порядок: RabbitMQ - порядок у черзі (може порушуватися при ретраях/мульти-консьюмерів); Kafka - порядок в партії, ключ задає партіонування.
Інваріанти домену: гроші/баланси - через журнали/саги та ідемпотентні команди; не покладайтеся на LWW.
3) Патерни інтеграції
Outbox/InBox: атомарний запис події в БД → публікація в чергу (outbox) та ідемпотентне споживання з логом обробок (inbox).
DLQ (мертві листи): після N спроб/помилок - в DLQ + алерт.
Retry/Delay: RabbitMQ — TTL + dead-letter exchange; Kafka - retry-топіки з backoff.
Request/Reply: RabbitMQ — `reply_to` + `correlation_id`; Kafka - рідко, тільки спец-патернами.
Компенсації: саги над подіями; кожна операція має зворотну.
4) Проектування ключів і топологій
RabbitMQ
Exchanges: `direct`, `topic`, `fanout`, `headers`.
Routing key: визначає попадання в чергу (і). Для пріоритизації - окремі черги.
QoS: 'prefetch'( наприклад, 50-300) балансує швидкість/латентність.
Quorum Queues: репліковані черги на Raft; заміна mirrored classic.
Streams: потік з офсетами (Kafka-подібно) для high-throughput/реплея.
Kafka
Topic → partitions: плануйте'#partitions'по цільовому throughput і паралелізму (назад сумісно збільшити простіше, ніж зменшити).
Key: всі записи одного ключа - в одній партії (гарантія порядку за ключем).
Replication factor: 3 для продуктивних тем,'min. insync. replicas = 2'+'acks = all'для надійності.
Retention: за часом/розміром; compaction - зберігає останні значення за ключем + tombstones для видалення.
5) Ретраї, DLQ, ідемпотентність
RabbitMQ
Повтори: per-message TTL + DLX (dead-letter exchange) з backoff (наприклад, 1м → 5м → 15м).
Ідемпотентність: 'correlation _ id '/' message-id'+ таблиця оброблених повідомлень (TTL) або детерміновані команди.
Підтвердження: manual `basic. ack'після успішної транзакції;'basic. nack(requeue=false)` в DLQ.
Kafka
Повтори: окремі retry-топіки; consumer комітить офсет після успішного side-effect.
Exactly-once processing (EOS): Producer `enable. idempotence = true', транзакційні producer/consumer,'read _ committed'на споживачі; sink (наприклад, Kafka→Kafka або Kafka→DB через транзакцію) - акуратно синхронізувати.
Дедуп: за ключем/ідемпотентним ключем на стороні бази, або через compacted topic.
6) Продуктивність і розміри
Закон Літтла: `L = λ × W`
Для воркерів: необхідний паралелізм'N запас (1. 2–1. 5)`.
RabbitMQ prefetch: почніть з'prefetch = 100'і виміряйте р99/час «ін-флайт».
Kafka partitions: розрахунок з бажаного consumer-паралелізму і цілі по throughput (наприклад, 1 партія стабільно 5-20 MB/s на SSD/10GbE).
7) Спостережуваність і алерти
Загальне:- Lag/Backlog (повідомлень/байт), age повідомлень (p95/p99), error-rate обробок, DLQ-rate.
- Час «publikatsiya→obrabotka» (end-to-end).
- Карта залежностей: продьюсер → брокер → консюмер.
- З'єднання, канали, не-acked повідомлення,'memory _ alarm','disk _ free _ limit','queue length'p95.
- Звіти по Quorum (leader, Raft log, промахи'quorum not enough').
- Under-replicated partitions, ISR shrink/expand, controller changes.
- Producer errors (timeouts, `request latency`), consumer lag per group/partition.
- Broker I/O, page cache hit, GC, ZooKeeper/KRaft health.
8) Безпека і мульти-тенантність
Шифрування TLS in-transit, автентифікація (SASL/PLAIN/SCRAM/OAuth, mTLS).
Авторизація: vhost/permissions (RabbitMQ), ACL на топіки/групи (Kafka).
Квоти: на з'єднання, канали, розмір черги/топіка, швидкість публікації/читання.
Ізоляція по середах (dev/stage/prod) і по namespace/vhost.
9) Експлуатація і тюнінг
RabbitMQ
Розносьте exchanges/queues по вузлах (капацитет CPU/IO).
Lazy queues (повідомлення на диск) для великих буферів; уникайте «гарячих» черг без шардингу.
Quorum Queues для HA; плануйте розмір Raft-журналу і диск.
Політики TTL/length-limit, priority черги тільки при реальній потребі (дорого).
bash rabbitmqctl set_policy DLX "^task\." \
'{"dead-letter-exchange":"dlx","message-ttl":60000,"max-length":100000}' --apply-to queuesKafka
SSD/NVMe, швидкі мережі; OS-тюнінг (swappiness низький, файлові ліміти).
`acks=all`, `linger. ms'( батчування),'compression. type = zstd '/lz4 для пропускної.
Параметри споживача: `max. poll. interval. ms`, `max. poll. records`, `fetch. min. bytes`.
Retention і compaction - баланс сховища/реплея.
java props. put("acks","all");
props. put("enable. idempotence", "true");
props. put("max. in. flight. requests. per. connection","1");
props. put("retries","10");10) Інтеграції та екосистема
Kafka Connect (Sinks/Sources), Schema Registry (Avro/JSON/Protobuf) і сумісність ('BACKWARD/FORWARD/FULL').
Kafka Streams/ksqlDB: stateful-операції, вікна, агрегати.
RabbitMQ Shovel/Federation: перенесення між кластерами/центрами.
Оператори K8s: Strimzi (Kafka), RabbitMQ Cluster Operator; GitOps-маніфести.
11) Чек-лист впровадження (0-45 днів)
0-10 днів
Визначити use-case'и: команди/таски (RabbitMQ), події/аудит (Kafka).
Вибрати ключі ('routing key '/' partition key'), задати SLO «publikatsiya→obrabotka».
Базові політики безпеки (TLS, ACL), квоти, DLQ/TTL.
11-25 днів
Впровадити outbox/inbox, ідемпотентність і дедуп.
Налаштувати ретраї з backoff (Rabbit: TTL+DLX; Kafka: retry topics).
Дашборди: lag, age, DLQ-rate, end-to-end latency; алерти.
26-45 днів
Тюнінг пропускний: prefetch/acks (Rabbit); partitions/acks/batch (Kafka).
DR-процедури (дзеркалювання/реплікація), тести відмови вузлів.
Документувати контракти подій (схеми) і політику сумісності.
12) Анти-патерни
Один «універсальний» інструмент на всі завдання.
Відсутність DLQ/TTL: вічні отруйники (poison messages).
Необмежений'prefetch'→ голодування споживачів, зростання p99.
Kafka без ключів → втрата порядку/гарячі партії за замовчуванням.
«Exactly-once» без реальної потреби/дисципліни - помилкове почуття безпеки.
Секрети/логіни в коді, без TLS/ACL.
Хардкод схем/версій повідомлень без Registry і міграцій.
13) Метрики зрілості
Lag/age SLO виконується ≥ 99% часу; DLQ-rate під контролем.
Ідемпотентність покриває 100% критичних шляхів; outbox/inbox впроваджено.
Retention/compaction задокументовані, реплей не ламає споживачів.
Алерти на ISR/URP (Kafka) і Raft/дискові ліміти (Rabbit) налаштовані.
Контракти подій версіонуються (Schema Registry), сумісність тестується в CI.
Регулярні game-days: відмова вузла/брокера/АЗ, перевірка відновлення.
14) Приклади конфігів (зведення)
RabbitMQ: префетч і підтвердження (pseudocode):python channel. basic_qos(prefetch_count=200)
for msg in consume("tasks"):
try:
handle(msg)
channel. basic_ack(msg. delivery_tag)
except Transient:
channel. basic_nack(msg. delivery_tag, request = False) # will go to DLQjava props. put("enable. auto. commit","false");
props. put("isolation. level","read_committed"); // при EOS
//...
poll -> process(idempotent) -> commitSync()15) Висновок
RabbitMQ і Kafka вирішують різні класи завдань: команди/таски і багата маршрутизація проти довготривалого журналу подій і масштабованого стрімінгу. Успіх - в правильних семантиках доставки, дисципліні ідемпотентності, продуманому ключуванні, ретраях/DLQ, спостережуваності і суворої безпеки. Побудуйте навколо черг інженерну практику - outbox/inbox, схеми і GitOps-політики - і ваша інтеграція стане передбачуваною, масштабованою і стійкою.