Что происходит, когда очередь сообщений выглядит пустой, а нода RabbitMQ уже задыхается от гигабайт данных? В этом выпуске разбираем реальную аварию: как массовые рассылки персонализированных писем превратили RabbitMQ в тяжелое хранилище объектов, для которого он архитектурно не предназначен.
Telegram-канал сообщества: https://t.me/getanalysts
VK сообщество: https://vk.com/getanalyst
Статья к эпизоду с доп. материалами: https://getanalyst.ru/podcast/rabbitmq-dmx
Выпуск актуален для системных аналитиков и архитекторов, которые проектируют интеграции через брокеры и готовятся к собеседованиям.
Тайм-коды к эпизоду:
| Заставка
| Введение и знакомство со спикером
| Для каких задач выбрали RabbitMQ
| Как работают интеграции с внешними системами через брокер
| DMX (Delayed Message Exchange) — задача, которая положила RabbitMQ
| Где в логах и мониторинге видны признаки падения RabbitMQ
| Последствия аварии и объём потерянных сообщений
| Что входит в payload сообщения RabbitMQ
| Порядок действий после падения RabbitMQ и почему не стоит проталкивать сообщения руками
| Инструменты аналитиков для работы с RabbitMQ
| Инфраструктура RabbitMQ: ноды
| Рекомендации по проектированию взаимодействия с RabbitMQ
Ведущая:
Екатерина Ананьева
Основатель сообщества Системных Аналитиков GetAnalyst
Гости:
Софья Калинина,
Старший cистемный аналитик, РТК ИТ.