Очередь FIFO, чтобы гарантировать упорядоченную "обработку" сообщений (несколько потребителей)?

Question

Мне задали этот вопрос сегодня, и ответ, кажется, разделяет мнение среди моей команды.

Сценарий У вас есть несколько издателей, отправляющих события (сообщения) в RabbitMQ (через EasyNetQ) по определенным темам. Они сказали, что они гарантируют FIFO. Они хотят создать систему, которая гарантирует "обработку" сообщений по "теме" по порядку.

Мое решение У меня есть кеш, в котором содержится "номер версии" для каждой темы, а также обработка сообщения, если последовательность не совпадает. Вы можете повторить обработку сообщения (повтор с задержкой по времени) после завершения обработки первого события и обновления кеша до новой целевой версии. Это означает, что потребитель в основном ждет, пока другой потребитель завершит обработку. Это работает для вещей, которые занимают величины миллисекунд, а не секунд, так как это своего рода блокировка.

В качестве альтернативы я сказал, что мы могли бы реализовать таблицу хранения для событий не по порядку, как это http://blog.jonathanoliver.com/cqrs-out-of-sequence-messages-and-read-models/

Человек, который поднял вопрос, сказал, что оба эти ответа были неправильными.

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

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

РЕДАКТИРОВАТЬ: уточнить. Я ожидаю найти плюсы и минусы каждого подхода, чтобы определить, какое решение лучше подходит для моего контекста. Есть ли подводные камни и т.д.?

Answer 1

Есть ли правильное и неправильное решение здесь

нет

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

да

это вопрос, который задают довольно часто в stackru и часто отвечают в сообщениях в блогах по всему Интернету.

на каждый раз, когда кто-то спрашивает, есть как минимум 2 разных ответа. ни один из них не является "правильным" или "неправильным", но все они лучше подходят для определенных ситуаций, основанных на контексте.