Брокер событий — это место, где сохраняются данные (события), поступающие от продюсеров. Во многих системах брокер может быть разбит на партиции и масштабирован по разным машинам для повышения отказоустойчивости.
Один из способов классификации брокеров — разделение на потоки событий (event streams) и очереди событий (event queues).
| Тип | Как работает | Особенности |
|---|---|---|
| Потоки (Streams) | Брокер — это неизменяемый журнал (log). События хранятся заданное время (TTL). | Много консьюмеров могут читать одно событие. Можно «перемотать» время назад. |
| Очереди (Queues) | Сообщение удаляется из брокера сразу после подтверждения обработки (ACK). | Одно сообщение — один консьюмер. Идеально для распределения конкретных задач. |
1. Поток событий (Event Stream)
В потоковой модели консьюмеры могут повторно читать события, которые уже обработали, «возвращаясь во времени» (это полезно, если сервис упал и ему нужно восстановить состояние). Пример потоковой реализации — Apache Kafka.
2. Очередь событий (Event Queue)
Здесь подразумевается, что каждое сообщение обрабатывается ровно одним консьюмером. Можно подключить несколько консьюмеров (воркеров), но они будут читать разные сообщения — одно и то же сообщение не достанется двоим. Пример подобного решения — RabbitMQ.
RabbitMQ — это «умный» брокер, который сам следит за тем, кто что прочитал и куда направить сообщение (через Exchanges). Kafka — это «глупая труба», она просто надежно хранит данные на диске, а за позицию чтения (offset) отвечает сам консьюмер.
Именно это позволяет Kafka масштабироваться до триллионов сообщений в день.