15 вопросов
Асинхронная обработка: отправитель не ждет выполнения. Сглаживание пиков нагрузки, развязка сервисов, надежная доставка (сообщение сохраняется). Обработка в фоне: письма, нотификации, тяжелые задачи.
Брокер сообщений: producers публикуют в exchange, exchange маршрутизирует в очереди, consumers получают из очередей. Exchange types: direct, fanout, topic, headers. Очереди именованные, сообщения персистентные. Поддержка ack, nack, dead letter.
Direct - по routing key (точное совпадение). Fanout - во все привязанные очереди. Topic - по шаблону ключа (wildcards). Headers - по заголовкам. Выбор зависит от маршрутизации.
ack (acknowledge) - подтверждение успешной обработки; сообщение удаляется из очереди. nack - отказ; сообщение можно вернуть в очередь или в DLQ. Без ack при падении consumer сообщение не теряется (requeue). Предотвращает потерю при сбоях.
Persistent сообщения и durable очереди; ack после обработки; idempotent consumer; при необходимости - подтверждение от подписчика (at-least-once). Retry с backoff и DLQ при повторных сбоях.
Распределенный лог: сообщения хранятся в партициях топиков, с retention. Высокая пропускная способность, масштабирование потребителей через consumer groups. RabbitMQ - классическая очередь (очередь очереди); Kafka - лог, перечитание с offset. Kafka для событий и стриминга; RabbitMQ для задач и очередей.
Topic - категория сообщений. Partition - упорядоченный лог внутри топика. Сообщения с одним ключом в одну партицию (порядок). Партиций несколько - параллелизм записи и чтения. Масштабирование топика - добавление партиций.
Группа потребителей: каждая партиция топика обрабатывается одним consumer из группы. При добавлении/удалении consumer происходит rebalance. Параллелизм = число партиций. Offset хранится в Kafka (commit).
Репликация партиций (replication factor); лидер и replica; при падении лидера replica становится лидером. Consumer commit offset после обработки; при перезапуске чтение с последнего offset. Producer ack=all для гарантии записи в реплики.
At-most-once - не более одного раза (возможна потеря). At-least-once - минимум один раз (возможны дубликаты при ретраях). Exactly-once - ровно один раз (транзакции, идемпотентность). В практике часто at-least-once + идемпотентный consumer.
Retry с ограничением попыток и backoff; при исчерпании - Dead Letter Queue (DLQ). Логирование и алерты. Идемпотентная обработка при дубликатах. Не блокировать очередь на "мертвых" сообщениях.
Очередь для сообщений, которые не удалось обработать после N попыток. Анализ и ручная обработка или повторная публикация после исправления. Не терять сообщения и не блокировать основную очередь.
Повторная обработка того же сообщения не должна менять результат. Реализация: дедупликация по message id в БД; проверка "уже обработано" перед действием; идемпотентные операции на стороне внешних систем.
Pull (Kafka): consumer запрашивает батч сообщений. Контроль скорости у consumer, проще backpressure. Push (RabbitMQ): брокер шлет consumer. Меньше задержка, но нужен flow control. Выбор по сценарию.
Разница между последним сообщением в партиции и текущим offset consumer. Рост lag - consumer не успевает. Мониторинг lag важен; при высоком lag - масштабировать consumers или оптимизировать обработку.