Какие последствия и стратегии обработки сбоя (падения) брокера сообщений RabbitMQ?

Ну вот смотри, классическая история: стоит себе RabbitMQ, все его ласкают, называют брокером, а он взял и накрылся медным тазом. И что получается? Вся эта красивая асинхронная хуйня моментально встаёт колом.

Производители, которые только что важные сообщения в очередь пихали, теперь тычутся в закрытую дверь, как дураки. Потребители, которые эти сообщения жрали, повисают в разрыве соединения и сидят с пустой миской. А самое весёлое — те сообщения, которые потребитель уже взял, но не успел сказать «ок, обработано», так и болтаются в подвешенном состоянии, как недоделанные души. Красота, да?

Так и что делать-то, если этот самый «надежный» брокер решил откинуться? Сидеть и плакать? Не, есть проверенные способы не обосраться полностью.

Первое и самое очевидное — научи клиента переподключаться. Это же не ручное дело каждый раз коннекты тыкать. В нормальных библиотеках, типа того же RabbitMQ.Client для дотнетчиков, есть встроенная фича — автоматическое восстановление. Включил её, выставил интервалы с экспоненциальной задержкой (чтобы не дудосить брокер, пока он грузится), и пусть сам бьётся головой об стенку, пока не пролезет обратно.

var factory = new ConnectionFactory
{
    HostName = "localhost",
    AutomaticRecoveryEnabled = true, // Вот эта волшебная галочка
    NetworkRecoveryInterval = TimeSpan.FromSeconds(10) // Не лезь каждую секунду, дай отдышаться
};

Второй момент — а куда девать сообщения, пока брокер в отключке? Вот твой сервис пытается отправить событие «пользователь заплатил миллион», а RabbitMQ — упс, не доступен. Просто выкинуть событие? Да ты псих! Тут нужен паттерн «Outbox» или «Store and Forward». Короче, пиши всё в свою локальную базу или файлик, как в буфер обмена. А потом уже фоновая работяга будет тихонечко выгребать это добро и пытаться протолкнуть в RabbitMQ, когда он очухается. И да, обязательно используй Publisher Confirms, чтобы точно знать, что брокер не просто принял сообщение, а реально записал его на диск, а не держал в памяти, пока его не вырубили.

Третье — сделай так, чтобы сообщения вообще пережили перезагрузку. А то часто бывает: очередь объявил, отправил кучу данных, брокер перезапустился — а очереди-то и нету, испарилась, как сон. Поэтому объявляй очереди как durable, а сообщения помечай как persistent. Это гарантирует, что они запишутся на диск и не потеряются, даже если кролика вырубят.

var properties = channel.CreateBasicProperties();
properties.Persistent = true; // Теперь это не просто в памяти, а на диске
channel.QueueDeclare(queue: "task_queue", durable: true, exclusive: false, autoDelete: false, arguments: null);

Ну и четвёртый, жирный пункт — не класть все яйца в одну корзину. Запускай RabbitMQ кластером, с зеркалированием очередей. Упала одна нода — остальные подхватят. Это, конечно, сложнее и требует ресурсов, но зато ты спишь спокойно, а не бегаешь ночью перезапускать единственный инстанс.

Если резюмировать всю эту простыню: чтобы не охуеть от падения RabbitMQ, нужно комбинировать три вещи. Во-первых, умного клиента, который сам переподключается. Во-вторых, буфер на своей стороне, чтобы не терять данные, пока брокер в отключке. И в-третьих, правильно настроенного самого брокера — с надёжным хранением и кластеризацией. Тогда и падения будут не страшнее легкой икоты.