1.1 列表的侷限

　　前面我們說通過佇列的 rpush 和 lpop 可以實現訊息佇列（隊尾進隊頭出），但是消費者需要不停地呼叫 lpop 檢視 List 中是否有等待處理的訊息（比如寫一個 while 迴圈）。 為了減少通訊的消耗，可以 sleep()一段時間再消費，但是會有兩個問題： 1、如果生產者生產訊息的速度遠大於消費者消費訊息的速度，List 會佔用大量的記憶體。 2、訊息的實時性降低。 list 還提供了一個阻塞的命令：blpop，沒有任何元素可以彈出的時候，連線會被阻塞。

blpop queue 5

　　基於 list 實現的訊息佇列，不支援一對多的訊息分發。

1.2 釋出訂閱模式

　　除了通過 list 實現訊息佇列之外，Redis 還提供了一組命令實現釋出/訂閱模式。這種方式，傳送者和接收者沒有直接關聯（實現瞭解耦），接收者也不需要持續嘗

試獲取訊息。 　　首先，我們有很多的頻道（channel），我們也可以把這個頻道理解成 queue。訂閱者可以訂閱一個或者多個頻道。訊息的釋出者（生產者）可以給指定的頻道釋出訊息。 只要有訊息到達了頻道，所有訂閱了這個頻道的訂閱者都會收到這條訊息。 　　需要注意的注意是，發出去的訊息不會被持久化，因為它已經從佇列裡面移除了，所以消費者只能收到它開始訂閱這個頻道之後釋出的訊息。下面我們來看一下發布訂閱 命令的使用方法。 　　訂閱者訂閱頻道：可以一次訂閱多個，比如這個客戶端訂閱了 3 個頻道。

subscribe channel-1 channel-2 channel-3

　　釋出者可以向指定頻道釋出訊息（並不支援一次向多個頻道傳送訊息）：

publish channel-1 2673

　　取消訂閱（不能在訂閱狀態下使用）：

unsubscribe channel-1

1.2.2 按規則（Pattern）訂閱頻道

　　支援?和*佔位符。?代表一個字元，*代表 0 個或者多個字元。 　　消費端 1，關注運動資訊:

psubscribe *sport

　　消費端 2，關注所有新聞：

psubscribe news*

　　消費端 3，關注天氣新聞：

psubscribe news-weather

　　生產者，釋出 3 條資訊：

publish news-sport yaoming 
publish news-music jaychou 
publish news-weather rain