Redis 的pub/sub機制與23種設計模式中的觀察者設計模式極為類似。但Redis對于這個機制的實現更為輕便和簡結，沒有觀察者模式的那么復雜的邏輯考慮而僅僅需要通過兩個Redis客戶端配置channel即可實現，因此它也僅僅做了消息的"發布"和"訂閱"的實現，而在實際處理這類場景時遇到的情況根本沒有考慮到。

數據可靠性無法保證
一個redis-cli發布消息n個redis-cli接受消息。消息的發布是無狀態的，即發布完消息后該redis-cli便在理會該消息是否被接受到，是否在傳輸過程中丟失，即對于發布者來說，消息是"即發即失"的.

擴展性太差

不能通過增加消費者來加快消耗發布者的寫入的數據，如果發布者發布的消息很多，則數據阻塞在通道中已等待被消費著來消耗。阻塞時間越久，數據丟失的風險越大(網絡或者服務器的一個不穩定就會導致數據的丟失)

資源消耗較高

在pub/sub中消息發布者不需要獨占一個Redis的鏈接，而消費者則需要單獨占用一個Redis的鏈接，在java中便不得獨立出分出一個線程來處理消費者。這種場景一般對應這多個消費者，此時則有著過高的資源消耗。

對于如上的幾種不足，如果在項目中需要考慮的話可以使用JMS來實現該功能。JMS提供了消息的持久化/耐久性等各種企業級的特性。如果依然想使用Redis來實現并做一些數據的持久化操作，則可以根據JMS的特性來通過Redis模擬出來.

subscribe端首先向一個Set集合中增加“訂閱者ID”，此Set集合保存了“活躍訂閱”者，訂閱者ID標記每個唯一的訂閱者，例如：sub:email,sub:web。此SET稱為“活躍訂閱者集合”
subcribe端開啟訂閱操作，并基于Redis創建一個以“訂閱者ID”為KEY的LIST數據結構，此LIST中存儲了所有的尚未消費的消息。此LIST稱為“訂閱者消息隊列”
publish端：每發布一條消息之后，publish端都需要遍歷“活躍訂閱者集合”，并依次向每個“訂閱者消息隊列”尾部追加此次發布的消息。
到此為止，我們可以基本保證，發布的每一條消息，都會持久保存在每個“訂閱者消息隊列”中。
subscribe端，每收到一個訂閱消息，在消費之后，必須刪除自己的“訂閱者消息隊列”頭部的一條記錄。
subscribe端啟動時，如果發現自己的自己的“訂閱者消息隊列”有殘存記錄，那么將會首先消費這些記錄，然后再去訂閱。

總結

以上是生活随笔為你收集整理的Redis pub/sub机制在实际运用场景的理解(转载)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。