Подготовка к интервью
Разбирайте реальные вопросы, сверяйтесь с подробными ответами и готовьтесь по технологиям и компаниям.
Проверьте, насколько резюме подходит выбранной позиции, и получите рекомендации по улучшению.
Каталог
Kafka прежде всего хранит распределённый журнал с offsets и повторным чтением, а RabbitMQ предоставляет маршрутизацию и очереди сообщений. Выбор зависит от модели потребления и требований, не только от скорости.
Читать ответQuorum Queues используют Raft: лидер согласует реплицируемые изменения с большинством. Старые Mirrored Queues имели другой механизм репликации; классическое зеркалирование удалено в RabbitMQ 4.0.
Читать ответRabbitMQ часто удобен для очередей рабочих задач и гибкой маршрутизации, Kafka — для сохраняемого потока событий с независимыми потребителями и replay. Выбор зависит от требований, а не только объёма.
Читать ответSplit-brain возникает, когда разделённые части кластера продолжают действовать независимо и расходятся по состоянию. Исторический pause_minority приостанавливал меньшинство ради согласованности.
Читать ответPush отправляет данные потребителю по инициативе брокера, pull позволяет потребителю запрашивать порции. Управление потоком нужно в обоих случаях; сама модель не определяет весь расход памяти брокера.
Читать ответKafka удобна как сохраняемый журнал событий с повторным чтением и независимыми потребителями. RabbitMQ часто выбирают для очередей задач и гибкой маршрутизации сообщений.
Читать ответRabbitMQ обычно используют как брокер маршрутизируемых сообщений и очередей задач, Kafka — как распределённый журнал событий с partitions, offsets и независимым повторным чтением.
Читать ответПри аварии риск зависит от persistence и подтверждений, а не только от названия брокера. Redis без подходящей долговечности может потерять недавно принятые задачи; RabbitMQ тоже требует правильной настройки.
Читать ответRabbitMQ обычно доставляет сообщения активным consumers с учётом prefetch; Kafka consumer сам запрашивает порции данных. Нагрузка определяется также батчами, подтверждениями и скоростью клиентов.
Читать ответНадёжная схема: сохранить чек и outbox-событие в одной транзакции, доставить его через RabbitMQ, а REST-проверку выполнять с ограниченными повторами и идемпотентностью.
Читать ответВеб-приложение кладёт задачу в брокер, отдельный Celery worker её исполняет. Падение веб-процесса не равно падению worker; повторную доставку нужно считать нормальным событием.
Читать ответPrefetch Count ограничивает число сообщений, доставленных потребителю, но ещё не подтверждённых. Слишком малое значение оставляет простаивающие ресурсы, слишком большое ухудшает баланс и расход памяти.
Читать ответ