Redis隊列vs MSMQ

Question

很長一段時間，我們使用msmq和redis隊列（IRedisList）。 幾個月前我們開始嘗試redis pub-sub。

我們的應用程序有超過20個服務，可以讀取隊列中的消息或使用redis預訂頻道。 我們也有十多個隊列，我們​​發送消息給他們。 該應用程序是多線程的。

那麼我想從你那裏得到什麼？

現在我們有一些時間來決定使用什麼類型的隊列以及我們想用不同種類的隊列替換什麼樣的隊列。

我試圖尋找關於MSMQ VS Redis的帖子，但沒有找到足夠的信息。

有人能告訴我這個問題嗎？

Answer 1

國際海事組織，你試圖比較蘋果和橘子在這裏。

MSMQ是一種企業級MOM（面向消息的中間件，即排隊系統），提供持久性，事務支持和豐富的功能集。

Redis是一款快速的內存數據結構服務器，您可以在其上構建排隊系統。使用Redis正確實施MSMQ的基本功能已經是一項艱鉅的任務。它可能根本無法實現高級功能（如分發事務支持）。

我會建議嘗試列出您在排隊系統所期望的性能：

• 你需要持久化？
• 你需要交易支持嗎？
• 你需要分佈式事務支持嗎？
• 你需要「一次又一次」交付語義嗎？至多一次？至少一次？
• 您是否需要多重重試策略（線性延遲，指數退避等）？
• 你需要異常/死亡隊列嗎？
• 您是否需要物品保留？
• 你需要隊列瀏覽支持嗎？隊列管理功能？
• 您是否需要物品優先管理？
• 你是否需要自動物品到期？
• 您需要延遲物品嗎？
• 您是否需要項目排序？上一個值隊列？
• 你需要發佈和訂閱嗎？隨着多重鑄造？
• 您是否需要在單個線程中同時從幾個隊列中取出隊列？
• 您是否需要高可用性和/或羣集支持？
• 您是否擁有高吞吐量？你需要最好的表現嗎？

根據您的要求，Redis可能會或可能不會很適合。但不要指望用Redis得到真正的MOM的花裏胡哨。

最後一點：您提到了Redis pub/sub功能。請注意，這種機制根本不是基於排隊系統。使用Redis pub/sub不能保證消息的傳遞。如果用戶沒有收聽，該用戶的物品將會丟失。