Очереди сообщений: зачем и как

Проблема прямого вызова

Сервис заказов после оформления должен отправить письмо, начислить бонусы и обновить аналитику. Если он вызывает эти три сервиса напрямую и ждёт ответа, он становится медленным и хрупким: упал почтовый сервис, и заказ не оформляется, хотя к почте он отношения не имеет. Очередь сообщений развязывает это.

Producer, очередь, consumer

Идея простая. Сервис не вызывает других напрямую, а кладёт сообщение в очередь и идёт дальше. Другие сервисы забирают сообщения из очереди и обрабатывают в своём темпе.

• Producer кладёт сообщения.
• Consumer забирает и обрабатывает.
• Очередь (брокер) хранит сообщения между ними.

Сервис заказов теперь не ждёт почту и не падает из-за неё: он положил сообщение и свободен.

Что это даёт

• Развязка. Producer и consumer не знают друг о друге и не падают вместе. Упал consumer, сообщения копятся в очереди и обработаются, когда он вернётся.
• Сглаживание пиков. Пришёл всплеск заказов, очередь приняла их, а consumer разгребает в своём темпе. База не захлёбывается.
• Масштабирование. Очередь медленно разгребается, добавляешь ещё consumer-ов на ту же очередь, и они разбирают сообщения параллельно.

At-least-once и идемпотентность

Брокеры обычно гарантируют доставку at-least-once: сообщение дойдёт хотя бы раз, но при сбоях может прийти повторно. Поэтому consumer должен быть идемпотентным из урока про идемпотентность: повторная обработка одного сообщения не должна начислять бонусы дважды. Это ключевое требование к обработчикам очередей.

RabbitMQ и Kafka

Два самых частых брокера решают слегка разные задачи:

• RabbitMQ это классическая очередь задач. Сообщение забрал один consumer, обработал, оно ушло. Хорошо для «сделать работу один раз» (отправить письмо, обработать платёж).
• Kafka это лог событий. Сообщения не удаляются после чтения, а лежат в логе, и разные потребители читают его независимо, каждый со своей позицией. Хорошо для потоков событий и аналитики, где одно событие нужно многим.

Грубо: нужна очередь задач берут RabbitMQ, нужен поток событий для многих потребителей берут Kafka.

Что важно запомнить

Очередь развязывает сервисы: producer кладёт сообщение и не ждёт, consumer обрабатывает в своём темпе. Это убирает каскадные падения, сглаживает пики и позволяет масштабировать обработку, добавляя consumer-ов.

Доставка at-least-once означает возможный повтор, поэтому consumer должен быть идемпотентным. RabbitMQ — очередь задач (сделать один раз), Kafka — лог событий (многие читатели независимо).

Этим закрывается трек про данные: база, миграции, пулы, кеш и очереди.