Реплицированная очередь сообщений

Question

Я ищу очередь сообщений, которая будет реплицировать сообщения на кластере серверов.Я знаю, что это приведет к снижению производительности, но это то, к чему предъявляются требования - постоянство сообщений очень важно.

Репликация может быть асинхронной, но она должна быть, если существует большое количество ожидающих сообщений.для обработки они не должны быть потеряны.

Пока мне не удалось найти что-либо из известных MQ.Например, HornetQ поддерживал репликацию сообщений в 2.0, но в 2.2 он, похоже, удален.RabbitMQ вообще не копирует сообщения и т. Д.

Есть ли что-нибудь, что могло бы удовлетворить мои требования?

Answer 1

Есть как минимум три способа решения этой проблемы, которые приходят на ум, в зависимости от того, насколько надежным вам должно быть решение.

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

Два: продолжай смотреть. Существуют различные коммерческие системы, которые определенно делают это, две такие (без финансовой выгоды с моей стороны): Informatica Ultra Messaging (ранее 29West) и Solace . Они обычно используются в финансовом сообществе.

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

В целом: протестируйте свои предположения о производительности, поскольку все они будут иметь различные последствия для производительности в различных сценариях.

Answer 2

новый Kafka 0.8.1 предлагает репликацию!

Answer 3

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