Брокеры сообщений
Брокер сообщений — это посредник, который развязывает отправителя данных от их обработчика. Продюсер публикует сообщение и идёт дальше, брокер надёжно его хранит, а консюмер забирает его позже — двум сторонам не нужно быть онлайн одновременно и знать друг о друге. Именно эта развязка во времени и пространстве делает систему устойчивой к пикам нагрузки и падениям отдельных сервисов.
Тема собирает три ловушки, на которых стабильно спотыкаются. Первая — считать брокер балансировщиком или обычной базой: он именно хранит и маршрутизирует сообщения между развязанными сервисами. Вторая — думать, что несколько консюмеров в одной группе делят одну партицию: параллелизм в Kafka ограничен числом партиций, а не консюмеров. Третья — не знать про очередь недоставленных сообщений и срок жизни: без них сбойное сообщение либо теряется молча, либо блокирует всю очередь. Разбор — в слоях ниже.
Карта темы
- Основы брокера сообщений — развязка продюсера и консюмера и базовые компоненты очереди в Kafka и RabbitMQ.
- Партиции Kafka и группы консюмеров — партиция как единица параллелизма, правило «партиция ↔ один консюмер в группе» и роль ZooKeeper/KRaft.
- DLQ и TTL сообщений — куда уходит сбойное сообщение и как срок жизни защищает очередь от «отравленных» сообщений.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Считать, что продюсер и консюмер обязаны быть онлайн вместе | Теряется весь смысл асинхронной развязки; система хрупка к падениям |
| Путать брокер с балансировщиком или базой данных | Неверная модель — брокер именно хранит и маршрутизирует сообщения |
| Думать, что несколько консюмеров в группе читают одну партицию | Лишние консюмеры простаивают; параллелизм не растёт |
| Масштабировать добавлением консюмеров сверх числа партиций | Ёмкость упирается в число партиций, а не консюмеров |
| Считать, что ZooKeeper хранит данные сообщений | ZooKeeper координирует кластер (в новом Kafka — KRaft), данные лежат в логах партиций |
| Не знать про DLQ | «Отравленное» сообщение блокирует очередь или молча теряется |
| Путать TTL с минимальной задержкой | TTL — это срок истечения, а не задержка перед доставкой |
Значение для собеседований
Брокеры спрашивают, чтобы проверить, отличаете ли вы асинхронную развязку от синхронного вызова и понимаете ли, где именно находится параллелизм. Кандидат, который говорит «партиция — единица параллелизма, поэтому масштабируют партициями, а группа консюмеров читает каждую партицию максимум одним консюмером», сразу опережает того, кто «добавит консюмеров, и станет быстрее».
Что обычно проверяют:
- Зачем нужен брокер и какие у него компоненты — продюсер, консюмер, сам брокер, очередь/топик.
- Разбор задачи «3 партиции, 4 консюмера» — один простаивает, это потеря ёмкости, а не ошибка.
- Чем занят ZooKeeper и что его заменяет в новом Kafka.
- Что такое DLQ и TTL и как они держат очередь здоровой при сбоях.
Типичный неверный ответ: «чтобы ускорить обработку, добавлю консюмеров в группу». Сверх числа партиций лишние консюмеры простаивают: масштаб задаёт число партиций. И «сбойное сообщение просто удаляется» — без DLQ оно либо теряется, либо застревает и блокирует очередь.