Очередь Redis против MSMQ - программирование

Долгое время мы использовали msmq и redis queue (IRedisList). Пару месяца назад мы начали пробовать redis pub-sub.

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

Итак, что я хочу от вас?

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

Я попытался найти сообщение о MSMQ VS Redis и не нашел достаточно информации.

Может кто-нибудь посоветует мне эту проблему?

Ответ 1

ИМО, вы пытаетесь сравнить яблоки и апельсины здесь.

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

Redis - это быстрый сервер структуры данных в памяти, на котором вы можете создать систему очередей. Правильная реализация основных функций MSMQ с Redis - уже сложная задача. Вероятно, было бы невозможно реализовать расширенные функции (например, поддержку транзакций распространения).

Я бы предложил попробовать перечислить свойства, которые вы ожидаете от системы очередей:

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

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

Последняя точка: вы упомянули функцию Redis pub/sub. Обратите внимание, что этот механизм совсем не основан на системе очередей. Существует никаких гарантий относительно доставки сообщений с Redis pub/sub. Если абонент не прослушивает, этот элемент будет потерян для этого абонента.