Вопрос проверяет понимание механизмов отказоустойчивости и сохранения данных в RabbitMQ.
Если RabbitMQ падает, все сообщения, которые не были сохранены на диск, теряются. Для сохранности критичных сообщений их нужно публиковать как persistent, а очереди объявлять как durable. После перезапуска брокер восстановит durable-очереди и persistent-сообщения с диска. Кластер RabbitMQ (с зеркалированием очередей) позволяет пережить падение одного узла без потери данных и простоя.
Обеспечение сохранности сообщений при сбоях — ключевая задача брокера сообщений.
Механизмы обеспечения сохранности и восстановления:
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-сообщений и, для высокой доступности, кластеризацию с зеркалированием очередей.
