В RabbitMQ, Как сделать очереди в разных кластерах доступными без кластеризации?

Question

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

Смотрите, я не могу потерять ни одно сообщение на обоих сайтах.О публикации сообщений на нужном сайте можно позаботиться, но если сообщения находятся в очереди (рабочая очередь) или сообщения обрабатываются потребителем, и внезапно, если сайт выходит из строя, включая брокера и потребителя, как эти сообщения могут быть обработанына другом сайте.Как и в кластере, если один узел умирает, другой имеет все зеркалированные сообщения и знает, какие из них были подтверждены, но как этого добиться в WAN, так как кластеризация между WAN нецелесообразна.

Answer 1

Я думаю, что вопрос иллюстрирует концептуальную проблему с дизайном. Подводя итог,

1. Есть два сайта, подключенных через WAN
2. Один сайт является основным, а другой - активным резервом
3. Существует желание полной репликации состояния системы (полная согласованность) между узлами A и B, чтобы включить состояние сообщений в очереди и обрабатываемых сообщений.

По сути, вам нужна 100% согласованность, доступность и допуск раздела. Такая конструкция невозможна в соответствии с CAP Теорема . RabbitMQ обеспечивает либо согласованность и доступность с низким допуском разделов через кластеризацию , либо доступность и допуск разделов через federation или shovel . RabbitMQ не очень хорошо справляется со случаем необходимости согласованности и допуска разделов, поскольку брокеры сообщений действительно обрабатывают высокопереходный трафик.

Вместо этого необходимо полностью охватить проблему тем, что может быть решено с использованием доступных технологий. Мне кажется, что правильный подход (так как это через WAN) состоит в том, чтобы пожертвовать доступностью для согласованности и терпимости к разделам, и чтобы ваше приложение обрабатывало случай отработки отказа. Вы можете достаточно настроить RabbitMQ в этом отношении - см. https://www.rabbitmq.com/partitions.html.