Publish/subscribe

От один-к-одному к один-ко-многим

Очередь точка-точка доставляет каждое сообщение одному consumer’у. Publish/subscribe доставляет каждое сообщение каждой заинтересованной стороне. Издатель публикует сообщение в именованный топик; брокер копирует его в каждую подписку; каждый подписчик потребляет свою копию независимо. Издатель называет топик, а не получателя — он понятия не имеет, кто слушает, и consumer’ы приходят и уходят, а издатель этого не знает и об этом не заботится. Эта косвенность и есть весь смысл: она добавляет уровень развязки сверх временной развязки обычной очереди.

Результат — инверсия из хука. Вместо producer’а, держащего список из N downstream’ов для вызова (и деплоя при каждом изменении списка), producer публикует один раз, а consumer’ы решают, что им интересно. Это разница между командами («отправь это письмо» — адресовано одному обработчику, задача → используй очередь) и событиями («заказ оформлен» — факт, разосланный всем, кому интересно → используй pub/sub). Правильно провести это различие — это бОльшая часть дизайна: у команды ровно один корректный обработчик; у события ноль или много, и нельзя зашивать consumer’ов в producer.

Две архитектуры под одним именем: брокер против лога

«Pub/sub» описывает поведение (fan-out), и его реализуют два очень разных механизма. Этот раскол — самое важное, что надо понять в этом уроке.

Брокерный стиль (RabbitMQ, ActiveMQ, AWS SNS→SQS). Брокер маршрутизирует копию каждого сообщения в пер-подписчиковую очередь, и как только подписчик подтвердил, эта копия удаляется. Хранение сообщений транзиентно — задача брокера в доставке, а не в удержании. Подписчик, что не был подключён в момент публикации, может попросту никогда не увидеть сообщение (если ты не настроил durable-подписки). Брокер отслеживает состояние доставки за consumer’ов.

Log-based (Apache Kafka, AWS Kinesis, Apache Pulsar). Топик — это append-only лог: сообщения пишутся по порядку и удерживаются на настроенное окно (часы, дни или навсегда), независимо от того, прочитал ли их кто-то. Сообщения не пушатся consumer’ам с удалением; они тянут (pull) и отслеживают собственную позицию — офсет (offset) — в логе. Несколько независимых consumer’ов читают один лог на своих офсетах, не мешая друг другу. Чтение не потребляет; лог просто помнит, где каждый consumer.

БРОКЕР (RabbitMQ/SNS)            ЛОГ (Kafka/Kinesis)
publish → веер копий → очереди   append → неизменяемый лог [m0 m1 m2 m3 m4 …]
consumer ack → копия УДАЛЕНА      consumer A читает, двигает свой ОФСЕТ → 3
состояние живёт в БРОКЕРЕ         consumer B читает независимо → офсет 1
«труба доставки»                 состояние (офсет) живёт в CONSUMER'е
                                  «долговечная, реплеябельная запись»

Этот один архитектурный выбор каскадом задаёт всё остальное: реплей, порядок, пропускную способность и операционную модель — всё следует из «удалить при потреблении» против «append-only лог с офсетами».

Consumer-группы и порядок по партициям

Лог-топик разбит на партиции для параллелизма — единицу и масштаба, и порядка. Consumer-группа — это набор кооперирующих consumer’ов, делящих работу по топику: каждая партиция назначена ровно одному consumer’у в этой группе, поэтому добавление consumer’ов вплоть до числа партиций масштабирует пропускную способность линейно. Важно: разные группы каждая получают полный поток — группа «аналитика» и группа «антифрод» обе читают каждое сообщение на своих офсетах. Так один топик кормит много независимых подписчиков (fan-out между группами), при этом каждый подписчик балансирует нагрузку внутри себя (деление внутри группы).

Порядок следует из партиций. Лог гарантирует порядок внутри партиции, а не по всему топику. Сообщения с одним ключом (например, user_id) хешируются в одну партицию, поэтому все события одного пользователя остаются упорядочены относительно друг друга; события разных пользователей могут чередоваться. Это тот же компромисс порядка по ключу из урока про очереди, теперь сделанный структурным: ты получаешь параллелизм между партициями и порядок внутри одной — и выбираешь ключ партиционирования, чтобы класть «то, что должно остаться упорядоченным» вместе. Выберешь ключ со слишком малым числом различных значений — создашь горячую партицию, которую нельзя распараллелить.

Так лог — это просто навороченная очередь? Нет.

Самый глубокий вывод: очередь и лог — не один инструмент с разным брендингом. Очередь — это труба доставки: сообщения протекают и исчезают после обработки; её состояние — «что осталось сделать». Лог — это долговечная запись фактов: сообщения остаются, а consumer’ы движутся по ним; его состояние — «где каждый читатель». Очередь отвечает на «какая работа осталась?»; лог отвечает на «что произошло и могу ли я прочитать это снова?». К брокеру/очереди тянешься, когда работу надо сделать раз и забыть, а к логу — когда события суть факты, которые ты можешь захотеть разослать веером, переставить consumer’ов над ними или переиграть. Путать их — трактовать Kafka как очередь задач, из которой удаляешь, или очередь как event store, который реплеишь, — частая и дорогая несостыковка.

Это высота композиции: выбор fan-out и выбор лог-против-брокера для дизайна. Отдельный трек queues прорабатывает внутренности — лидерство партиций Kafka и ISR, типы exchange и биндинги RabbitMQ, точные протоколы коммита офсета. Используй его, когда эксплуатируешь конкретный брокер; оставайся здесь, когда решаешь, хочет ли дизайн fan-out и хочет ли реплей.