Очереди, потоки, события
RabbitMQ exchanges: построй маршрутизирующую ткань событий заказов
Читать про типы exchange — не то же самое, что развести топологию, которая переживёт нового подписчика, poison message и опечатанный binding. Построй небольшую маршрутизирующую ткань событий заказов, прогони через неё реальные сообщения и докажи каждое решение маршрутизации доказательством — а не успехом продюсера.
Преврати модель юнита в работающую топологию RabbitMQ: выбери верный тип exchange для выборочной подписки, добавь карантин dead-letter и защиту от немаршрутизируемых сообщений, затем подтверди через management UI и счётчики сообщений, что каждое событие попадает ровно туда, куда должно.
Спроектируй и запусти топологию RabbitMQ для событий заказов с тремя consumer'ами (audit, только-EU, fulfilment), докажи, что выборочная маршрутизация работает, затем сделай её устойчивой к poison message и отсутствующему binding'у — демонстрируя каждое поведение наблюдаемыми счётчиками сообщений, а не предположениями.
- Таблица маршрутизации (queue, binding-паттерн) плюс счётчик полученного по queue для известного набора опубликованных ключей, совпадающий с тем, что должен ловить каждый паттерн — измерено в management UI, а не предсказано.
- Некорректное сообщение показано прибывающим в карантинную queue, пока work-queue не застряла в цикле переотправки.
- Сообщение с несовпадающим routing key показано перехваченным mandatory-возвратом (или catch-all binding'ом), доказывая отсутствие тихого отбрасывания.
- Абзац-разбор: обоснование выбранного типа exchange и почему direct/fanout/headers подошли бы хуже для выборочной подписки.
- Добавь fanout exchange для broadcast-задачи (например, инвалидации кэша) рядом с topic-тканью и объясни, почему рассылке место на своём exchange, а не на topic # binding.
- Переключи work-queue на quorum queue и понаблюдай компромисс throughput под устойчивой нагрузкой публикации против classic queue.
- Добавь алерт: заинструментируй счётчик немаршрутизируемых сообщений и глубину dead-letter queue и триггери предупреждение при росте любого — on-call сигналы сломанного binding'а или шторма poison-сообщений.
- Добавь тестовую обвязку маршрутизации topic, которая утверждает для фиксированного набора routing key, какие именно queue должны получить каждое — чтобы будущее изменение binding'а, ломающее маршрутизацию, валило тест, а не production.
Это цикл, который ты будешь запускать, проектируя любую топологию RabbitMQ: выбери тип exchange по форме подписки (topic для выборочных паттернов, fanout для настоящей рассылки, direct для фиксированного point-to-point), привяжи queue по паттерну и подтверди копии реальными счётчиками сообщений, карантинь poison-сообщения через dead-letter exchange и защити от тихих отбрасываний флагом mandatory или catch-all. Сделав это раз на игрушечной ткани событий заказов, ты доводишь production-версию — где отсутствующий binding невидим, пока fraud-queue не пустует три дня — до уровня мышечной памяти.