Насколько отказоустойчив RabbitMQ и какими средствами это достигается?

А, слушай, про RabbitMQ и его "надёжность" из коробки — это вообще отдельная песня, блядь. Ну то есть, он вроде как крутой, но если его не настроить, то при первой же серьёзной проблеме он тебе такую пиздюлину подложит, что мало не покажется. Сейчас разжую, как оно работает, чтобы не было мучительно больно потом.

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

1. Кластеризация (Clustering) Это когда ты берёшь несколько серваков и делаешь из них одну банду. Они между собой общаются, метаданные (очереди, обменники, пользователи) у них общие. Но вот тут, сука, подвох: содержимое очередей по умолчанию живёт только на одном узле! То есть если этот узел накроется медным тазом — всё, пиши пропало, данные в ус не дуют, пока этот сервак не воскреснет. Получается, кластер есть, а отказоустойчивости нихуя.

2. Зеркалирование очередей (Queue Mirroring / High Availability) Вот это уже наше всё, блядь! Это когда ты говоришь: "Так, пацаны, чтобы каждая очередь была не на одном, а на нескольких узлах". Сообщение прилетело — и размножилось на N серверов. Если главный узел (мастер) откинулся — один из его зеркал тут же встаёт на его место, и работа идёт. Без этого — просто класть хуй на всю эту кластеризацию, честно. Настраивается через политики, ищи x-ha-policy.

3. Сохраняемость (Durability) Тут два слоя, оба важные, как яйца у мужика.

   • Durable Queues: Это чтобы сама очередь (её описание) пережила перезагрузку брокера. Без этого — перезапустил RabbitMQ, а очереди твоей уже нет. Пиздец.
   • Persistent Messages: А это чтобы сами сообщения не испарились. Помечаешь сообщение как persistent, и брокер скидывает его на диск. Но! Если очередь не durable, то persistent сообщение всё равно сдохнет. Надо использовать оба механизма, иначе — волнение ебать, а доверия ноль.

4. Подтверждение доставки (Confirmations and Acknowledgements) А это чтобы не терять сообщения по дороге, понимаешь? Тут тоже два фронта:

   • Publisher Confirms: Ты, как отправитель, пишешь сообщение и ждёшь от брокера кивка: "Чувак, я его принял, записал на диск (если persistent), положил в очередь (если она есть), всё чики-пуки". Без этого — отправил и молишься, долетело или нет.
   • Consumer Acknowledgements: Ты, как потребитель, взял сообщение из очереди, обработал его и должен сказать брокеру: "Всё, братан, я с этим закончил, можно удалять". Если не подтвердил (или сказал "накосячил, nack"), брокер вернёт сообщение обратно в очередь, чтобы его кто-то другой обработал. Без этого — потребитель взял сообщение, умер, и сообщение потеряно нахуй.

5. Обработка сетевых разделений (Split-Brain) А это, блядь, самая хитрая жопа. Представь: сеть легла, и твой кластер развалился на две изолированные банды. Каждая думает, что она главная, и начинает жить своей жизнью. Пиздец полный, данные могут разъехаться. RabbitMQ даёт на выбор несколько режимов (типа pause_minority, autoheal), чтобы автоматом эту пиздобратию как-то разрулить. Но тут надо головой думать, а не тыкать наугад.

Итог, ёпта: Чтобы RabbitMQ стал реально отказоустойчивым зверем, тебе надо:

1. Сделать кластер из трёх или больше узлов (один — это не кластер, это просто сервер, блядь).
2. Обязательно включить зеркалирование очередей.
3. Использовать durable очереди и persistent сообщения.
4. Включить подтверждения и от издателей, и от потребителей.

Только тогда можно будет спать более-менее спокойно. А иначе — это просто игрушка, которая в продакшене тебя жестоко и беспощадно наебёт при первой же возможности. Не делай так.