Нужно ли подтверждать сообщения в Kafka?
В классической consumer group Kafka обычно фиксируют offsets, а не подтверждают удаление каждого сообщения из очереди. Offset показывает, с какой позиции группа продолжит после восстановления.
Читать ответПодготовка к интервью
Разбирайте реальные вопросы, сверяйтесь с подробными ответами и готовьтесь по технологиям и компаниям.
Проверьте, насколько резюме подходит выбранной позиции, и получите рекомендации по улучшению.
Каталог
В классической consumer group Kafka обычно фиксируют offsets, а не подтверждают удаление каждого сообщения из очереди. Offset показывает, с какой позиции группа продолжит после восстановления.
Читать ответREST подходит для обращения с немедленным ответом, Kafka — для распространения событий и асинхронной обработки с повторным чтением. В ответе приведите реальные случаи и объясните требования к каждому.
Читать ответПри увеличении числа партиций формула hash(key) % N может направить новые сообщения того же ключа в другую партицию. Старые записи остаются на прежнем месте, поэтому сквозной порядок по ключу нарушается.
Читать ответKafka удобна как сохраняемый журнал событий с повторным чтением и независимыми потребителями. RabbitMQ часто выбирают для очередей задач и гибкой маршрутизации сообщений.
Читать ответИдемпотентный producer Kafka защищает от дублей его внутренних повторов, но не от любой повторной бизнес-отправки после перезапуска. Для неё нужен стабильный event_id и дедупликация.
Читать ответRabbitMQ обычно используют как брокер маршрутизируемых сообщений и очередей задач, Kafka — как распределённый журнал событий с partitions, offsets и независимым повторным чтением.
Читать ответPartition — упорядоченный журнал части topic; consumer group распределяет его partitions между своими consumers. Порядок гарантируется внутри partition, а не всего topic.
Читать ответПостройте потоковый конвейер с адаптером источника, ограниченной очередью, пулом загрузчиков, парсерами и пакетной записью. Лимит 1000 должен действовать на все активные запросы вместе.
Читать ответRabbitMQ обычно доставляет сообщения активным consumers с учётом prefetch; Kafka consumer сам запрашивает порции данных. Нагрузка определяется также батчами, подтверждениями и скоростью клиентов.
Читать ответKafka ориентирован на партиционированный журнал с offsets и повторным чтением, RabbitMQ — на брокерную маршрутизацию и очереди с подтверждениями. Это разные исходные модели, а не абсолютное разделение задач.
Читать ответНазовите брокеры, которые действительно использовали, и задачи: доставка фоновых заданий, интеграционные события, потоковая обработка или повторное чтение истории. Kafka и RabbitMQ выбирают по требованиям.
Читать ответПосле обнаружения отказа партиции назначат живому consumer, который продолжит с последнего зафиксированного offset. Сообщение может обработаться повторно, поэтому побочные эффекты должны быть идемпотентными.
Читать ответ