Очереди, потоки, события
RabbitMQ exchanges: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — маршрутизация direct/fanout/topic/headers, binding key, smart-broker push, prefetch и сбои dead-letter.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение по топологии, которое ты принимаешь на реальном ревью дизайна — не определение для заучивания, а компромисс маршрутизации, который надо взвесить под production-нагрузкой.
Цель
Убедись, что связываешь тип exchange, binding key, smart-broker push-модель и production-сбои — тот синтез, к которому вёл урок.
Викторина
Completed
Надо доставлять события заказов трём сервисам сегодня, ожидаешь новых позже, и один сервис интересуют только EU-заказы. Какой тип exchange подходит и почему?
Heads-up Fanout копирует каждое сообщение в каждую привязанную queue, поэтому EU-сервис получает все US-заказы лишь чтобы их отбросить — лишний трафик и риск тихой потери данных при баге фильтра. Используй fanout, только когда всем consumer'ам действительно нужно всё.
Heads-up Direct — точное совпадение, поэтому «все EU-события заказов» не выражаются одним binding; пришлось бы перечислять каждый конкретный ключ и пере-биндить при каждом новом типе события. Хорошо для фиксированной point-to-point маршрутизации, хрупко для развивающейся таксономии событий.
Heads-up Headers это выразит, но медленнее (матчит карту атрибутов вместо routing key) и редко того стоит, когда точечный topic-ключ вроде order.created.eu несёт тот же смысл дешевле.
Викторина
Completed
Queue нового consumer'а ничего не получает — ни ошибок, ни исключений, а вызовы publish продюсера возвращают успех. Самая вероятная причина?
Heads-up У RabbitMQ нет воспроизводимого лога — маршрутизация решается во время публикации через binding, а не окном retention. Поздний consumer не может «пропустить» удержанные сообщения, потому что их не существует.
Heads-up Низкий prefetch замедляет throughput, но всё равно доставляет; пустая queue без ошибок указывает на отсутствующий или несовпадающий binding, а не на QoS.
Heads-up Продюсеры RabbitMQ могут публиковать только в exchange — нельзя опубликовать в queue напрямую — поэтому это не выразимый режим сбоя.
Викторина
Completed
Topic-binding использует ключ order.*.eu. Какой routing key совпадёт?
Heads-up * матчит ровно одно слово и обязателен; в order.eu всего два слова, поэтому средняя позиция, которую требует *, отсутствует, и совпадения нет. Используй # для матча нуля-или-более слов.
Heads-up * матчит ровно одно слово, а не несколько; order.*.eu требует ровно трёх слов, поэтому четырёхсловный ключ не совпадает. Понадобился бы order.#.eu.
Heads-up Topic-binding должен совпасть в каждой позиции; финальное слово eu не равно us, поэтому весь ключ не совпадает независимо от совпадающего префикса.
Викторина
Completed
Коллега говорит, что RabbitMQ и Kafka — взаимозаменяемые очереди, поэтому поздно подключившийся consumer может воспроизвести события за неделю из любой. Где ошибка?
Heads-up Fanout копирует живые сообщения в текущие привязанные queue во время публикации; он ничего не удерживает. Consumer, добавленный позже, всё равно не увидит прошлые события, так как RabbitMQ удалил каждое по ack.
Heads-up Prefetch управляет in-flight неподтверждённой доставкой, а не retention или replay. Подтверждённые сообщения удаляются независимо от prefetch.
Heads-up Quorum queue добавляют Raft-репликацию для долговечности при отказах узлов, а не replay — подтверждённое сообщение всё равно удаляется и не может быть перечитано новым consumer'ом.
Викторина
Completed
Один consumer держит огромный бэклог неподтверждённых сообщений, пока быстрые consumer'ы простаивают, а память брокера ползёт к high-watermark. Что неверно настроено и какой фикс?
Heads-up Тип exchange управляет тем, какие queue получают копию, а не сколько in-flight сообщений держит один consumer. Голодание плюс рост неподтверждённой памяти — проблема QoS/prefetch, а не маршрутизации.
Heads-up Dead-letter exchange карантинит отклонённые или просроченные сообщения; он ничего не делает с медленным consumer'ом, захватившим большой prefetch-батч. Фикс — снизить prefetch, а не dead-letter.
Heads-up Publisher confirms сообщают продюсеру, что сообщение сохранено; они не управляют in-flight лимитами на стороне consumer'а. Бэклог и рост памяти идут от слишком высокого prefetch.
Викторина
Completed
Consumer делает nack-with-requeue на некорректном payload, который никогда не сможет обработать, и один worker теперь застрял, бесконечно переполучая то же сообщение. Какой устойчивый фикс?
Heads-up Fanout копирует то же poison message в больше queue — он множит проблему, а не убирает сообщение из цикла переотправки. Фикс — dead-letter наружу, а не рассылка.
Heads-up Больший prefetch позволяет worker'у держать больше сообщений, но poison message всё равно переочередняется и переотправляется; он не уходит. Только dead-letter убирает его из цикла.
Heads-up Флаг mandatory возвращает немаршрутизируемые сообщения продюсеру во время публикации; он ничего не делает с сообщением, которое смаршрутизировалось верно, но повторно падает в consumer'е. Этому случаю нужен dead-letter exchange.
Итог
Сквозная линия — одно дерево решений маршрутизации: тип exchange это алгоритм (direct — точное совпадение, fanout — рассылка, topic — точечный паттерн с * и #, headers — матч атрибутов), binding плюс routing key решают, какие queue получат независимую копию, а smart-broker push-модель означает, что подтверждённое сообщение удаляется — никакого replay, в отличие от Kafka. Production-сбои на слой ниже: непривязанный exchange тихо отбрасывает без флага mandatory, слишком высокий prefetch голодает быстрых consumer’ов и растит неподтверждённую память, а poison message без dead-letter exchange зацикливается навсегда. Сначала верно выбери тип exchange и binding; всё ниже зависит от корректной маршрутизации.