Что происходит, если брокер сообщений (RabbitMQ) падает? Как обеспечивается сохранность сообщений и восстановление?

Question

Если RabbitMQ падает, все сообщения, которые не были сохранены на диск, теряются. Для сохранности критичных сообщений их нужно публиковать как persistent, а очереди объявлять как durable. После перезапуска брокер восстановит durable-очереди и persistent-сообщения с диска. Кластер RabbitMQ (с зеркалированием очередей) позволяет пережить падение одного узла без потери данных и простоя.

YeaHub · Accepted Answer

Обеспечение сохранности сообщений при сбоях — ключевая задача брокера сообщений.Механизмы обеспечения сохранности и восстановления:Durable Queues и Persistent Messages:Durable Queue: Очередь объявляется как долговременная. Её метаданные сохраняются на диск, и она будет автоматически восстановлена после перезапуска брокера.Persistent Message: Сообщение помечается как постоянное. RabbitMQ сохранит его на диск, как только оно будет доставлено в durable-очередь.Важно: Сообщение будет сохранено на диск, только если оно находится в durable-очереди. Сохранение на диск замедляет работу брокера.Кластеризация и зеркалирование (Mirroring):RabbitMQ позволяет объединять несколько узлов в кластер.Зеркалирование очередей: Очередь может быть зеркалирована на несколько узлов кластера. Все операции (публикация, потребление) реплицируются на все зеркала.Преимущество: Если основной улад (master) падает, одно из зеркал автоматически становится новым мастером, и работа продолжается без потери данных и с минимальным простоем. Это обеспечивает высокую доступность (High Availability).Подтверждения от издателя (Publisher Confirms):Этот механизм позволяет издателю убедиться, что брокер принял сообщение.Издатель может ожидать подтверждения от брокера, что сообщение было не только получено, но и записано на диск на всех зеркалах очереди. Только после этого издатель может считать операцию успешной.Сценарий восстановления после падения одиночного сервера:Если используется одиночный экземпляр RabbitMQ с durable-очередью и persistent-сообщениями, после перезапуска брокер:Восстановит все durable-очереди.Восстановит все persistent-сообщения, которые были в этих очередях.Сообщения, которые находились в оперативной памяти (не persistent), будут потеряны.Потребители должны быть спроектированы так, чтобы переподключаться к брокеру при его восстановлении.Вывод:Для обеспечения сохранности сообщений при сбоях необходимо использовать комбинацию durable-очередей, persistent-сообщений и, для высокой доступности, кластеризацию с зеркалированием очередей.