Гарантии порядка сообщений

1) Что такое «порядок» и зачем он нужен

Порядок сообщений — это отношение «что должно быть обработано раньше» для событий одной сущности (заказ, пользователь, кошелек) или для всего потока. Он важен для инвариантов: «статус A перед B», «баланс до списания», «версия n перед n+1».
В распределенных системах глобальный тотальный порядок дорог и редко нужен; обычно достаточно локального порядка «на ключ».

2) Виды гарантий порядка

1. Per-partition (локальный порядок в разделе лога) — Kafka: порядок внутри партиции сохраняется, между партициями — нет.
2. Per-key (ordering key / message group) — все сообщения с одним ключом маршрутизируются в один «поток» обработки (Kafka key, SQS FIFO MessageGroupId, Pub/Sub ordering key).
3. Global total order — вся система видит единый порядок (распределенный журнал/секвенсер). Дорого, ухудшает доступность и throughput.
4. Causal order (причинно-следственный) — «событие B после A, если B наблюдает эффект A». Достижим через метаданные (версии, Lamport-времена/векторные часы) без глобального секвенсера.
5. Best-effort order — брокер старается сохранять порядок, но при сбоях возможны перестановки (часто в NATS Core, RabbitMQ при нескольких консюмерах).

3) Где порядок ломается

Параллельные консьюмеры одной очереди (RabbitMQ: несколько consumers на одну очередь → interleaving).
Ретраи/повторные доставки (at-least-once), таймауты `ack`, повторная постановка в очередь.
Ребаланс/фейловер (Kafka: переезд партиции/лидера).
DLQ/повторная обработка — «ядовитое» сообщение уходит в DLQ, следующие идут дальше → логический разрыв.
Мульти-регион и репликация — разные задержки → рассинхронизация.

4) Дизайн «порядка по ключу»

• Используйте естественные ключи: `order_id`, `wallet_id`, `aggregate_id`.
• Следите за «горячими ключами» — один ключ может «заблокировать» поток (head-of-line blocking). При необходимости расщепляйте ключ: `order_id#shard(0..k-1)` с детерминированной реконструкцией порядка на синке.
• В Kafka — один ключ → одна партиция, порядок сохранится в пределах ключа.

java producer.send(new ProducerRecord<>("orders", orderId, eventBytes));

(Ключ = `orderId` гарантирует локальный порядок.)

5) «Порядок против пропускной способности»

• Один консюмер на очередь сохраняет порядок, но снижает параллелизм.
• At-least-once + параллелизм повышают производительность, но требуют идемпотентности и/или восстановления порядка.
• Global order добавляет hop к секвенсеру → ↑латентность и риск отказа.

Компромисс: per-key порядок, параллелизм = число партиций/групп, + идемпотентные синки.

6) Контроль порядка в конкретных брокерах

Kafka

Порядок внутри партиции.
Соблюдайте `max.in.flight.requests.per.connection ≤ 5` с `enable.idempotence=true`, чтобы ретраи продюсера не меняли порядок.
Консюмер-группа: одна партиция → один воркер в момент времени. Повторные доставки возможны → держите sequence/version в бизнес-слое.
Транзакции (read-process-write) сохраняют согласованность «прочитал/записал/скоммитил офсеты», но не создают глобальный порядок.

properties enable.idempotence=true acks=all retries=2147483647 max.in.flight.requests.per.connection=5

RabbitMQ (AMQP)

Порядок гарантируется на одной очереди для одного консюмера. С несколькими консюмерами сообщений может прийти «вперемешку».
Для порядка: один консюмер или prefetch=1 + ack по завершении. Для параллелизма — разделяйте очереди по ключам (sharding exchanges / consistent-hash exchange).

NATS / JetStream

NATS Core — best-effort, низкая латентность, порядок может нарушаться.
JetStream: упорядочивание внутри стрима/последовательности; при редоставках возможны перестановки на консюмере → используйте sequence и буфер восстановления.

SQS FIFO

Exactly-once processing (эффективно, за счет дедупа) и порядок внутри MessageGroupId. Параллелизм — количеством групп, внутри группы head-of-line.

Google Pub/Sub

Ordering key дает порядок в пределах ключа; при ошибках публикация блокируется до восстановления — следите за backpressure.

7) Паттерны сохранения и восстановления порядка

7.1 Sequence/версионирование

• принимает событие только если `seq = last_seq + 1`;
• иначе — кладет в буфер ожидания до прихода недостающих (`last_seq+1`).

pseudo if seq == last+1: apply(); last++
else if seq > last+1: buffer[seq] = ev else: skip // дубль/повтор

7.2 Буферы и окна (stream processing)

Time-window + watermark: принимаем out-of-order в пределах окна, по watermark «закрываем» окно и упорядочиваем.
Allowed lateness: канал для опоздавших (recompute/ignore).

7.3 Sticky-routing по ключу

Хэш-маршрутизация `hash(key) % shards` отправляет все события ключа в один воркер.
В Kubernetes — поддерживайте сессию (sticky) на уровне очереди/шерды, не на L4-балансировщике HTTP.

7.4 Actor-модель / «один поток на ключ»

Для критичных агрегатов (кошелек): актор обрабатывает последовательно, остальной параллелизм — количеством акторов.

7.5 Идемпотентность + reordering

Даже с восстановлением порядка возможны повторы. Сочетайте UPSERT по ключу+версии и Inbox (см. «Exactly-once vs At-least-once»).

8) Работа с «ядовитыми» сообщениями (poison pills)

Сохранение порядка сталкивается с задачей: «как жить, если одно сообщение не обработать?»

Строгий порядок: блокировка потока ключа (SQS FIFO: вся группа). Решение — by-key DLQ: переводим только проблемный ключ/группу в отдельную очередь/ручной разбор.
Гибкий порядок: допускаем пропуск/компенсацию; логируем и продолжаем (не для финансов/критичных агрегатов).
Политика ретраев: ограниченный `max-deliver` + backoff + авидемпотентные эффекты.

9) Мульти-регион и глобальные системы

Cluster-linking/репликация (Kafka) не гарантирует межрегиональный глобальный порядок. Дайте приоритет локальному per-key порядку и идемпотентным синкам.
Для truly-global order используйте секвенсер (центральный лог), но это влияет на доступность (CAP: минус A при сетевых разрывах).
Альтернатива: causal order + CRDT для некоторых доменов (счетчики, множества) — не нужен строгий порядок.

10) Наблюдаемость порядка

Метрики: `out_of_order_total`, `reordered_in_window_total`, `late_events_total`, `buffer_size_current`, `blocked_keys_total`, `fifo_group_backlog`.

11) Анти-паттерны

Одна очередь + много консюмеров без шардирования по ключу — порядок ломается сразу.
Ретраи через пере-паблиш в ту же очередь без idempotency — дубли + out-of-order.
Глобальный порядок «на всякий случай» — взрыв латентности и стоимости без реальной пользы.
SQS FIFO одна группа на все — полный head-of-line. Используйте MessageGroupId per ключ.
Игнорирование «горячих ключей» — один «кошелек» тормозит все; делите ключ на под-ключи там, где возможно.
Смешивание критичных и bulk-потоков в одной очереди/группе — взаимное влияние и потери порядка.

12) Чек-лист внедрения

• Определен уровень гарантии: per-key/per-partition/causal/global?
• Спроектирован ключ упорядочивания и стратегия против «горячих ключей».
• Настроен маршрутизатор: партиционирование/MessageGroupId/ordering key.
• Консюмеры изолированы по ключам (sticky-routing, shard-workers).
• Включены идемпотентность и/или Inbox/UPSERT на синках.
• Реализован sequence/version и буфер reordering (если нужно).
• Политика DLQ by key и ретраи с backoff.
• Метрики порядка и алерты: out-of-order, blocked_keys, late_events.
• Game day: ребаланс, потеря узла, «ядовитое» сообщение, сетевые задержки.
• Документация: инварианты порядка, границы окон, влияние на SLA.

13) Примеры конфигураций

13.1 Kafka Consumer (минимизация нарушения порядка)

properties max.poll.records=500 enable.auto.commit=false  # коммит после успешной обработки батча isolation.level=read_committed

13.2 RabbitMQ (порядок ценой параллелизма)

Один консюмер на очередь + `basic.qos(prefetch=1)`

bash rabbitmq-plugins enable rabbitmq_consistent_hash_exchange публикуем с хедером/ключом для консистентного хеша

13.3 SQS FIFO

Задавайте MessageGroupId = key. Параллелизм = количество групп.
MessageDeduplicationId для защиты от дублей (в окне провайдера).

13.4 NATS JetStream (ordered consumer, эскиз)

bash nats consumer add ORDERS ORD-KEY-42 --filter "orders.42.>" --deliver pull \
--ack explicit --max-deliver 6

14) FAQ

Q: Мне нужен глобальный порядок?
A: Почти никогда. Почти всегда достаточно per-key. Глобальный порядок — дорого и бьет по доступности.

Q: Как быть с «ядовитым» сообщением при строгом порядке?
A: Переводить только его ключ/группу в DLQ, остальное — продолжать.

Q: Можно ли получить порядок и масштаб одновременно?
A: Да, порядок по ключу + много ключей/партиций + идемпотентные операции и буферы reordering там, где нужно.

Q: Что важнее: порядок или exactly-once?
A: Для большинства доменов — порядок по ключу + эффективно exactly-once эффекты (идемпотентность/UPSERT). Транспорт может быть at-least-once.

15) Итоги

Порядок — это локальная гарантия вокруг бизнес-ключа, а не дорогая глобальная дисциплина. Проектируйте ключи и партиции, ограничивайте «горячие» ключи, используйте идемпотентность и, где нужно, sequence + буфер reordering. Следите за метриками «out-of-order» и «blocked keys», тестируйте сбои — и вы получите предсказуемую обработку без жертв в производительности и доступности.