摘要：上一篇文章實戰第三章命令第五節有序集合下一篇文章實戰第三章命令第七節其他命令一般來說，發布與訂閱又稱的特點是訂閱者負責訂閱頻道，發送者負責向頻道發送二進制字符串消息。到目前為止，本書介紹的大多數命令都是與特定數據類型相關的。

上一篇文章：Python--Redis實戰：第三章：Redis命令：第五節：有序集合
下一篇文章：Python--Redis實戰：第三章：Redis命令：第七節：其他命令

一般來說，發布與訂閱（又稱pub/sub）的特點是訂閱者（listener）負責訂閱頻道（channel），發送者（publisher）負責向頻道發送二進制字符串消息（binary string message）。每當有消息被發送至給定頻道時，頻道的所有訂閱者都會收到消息。我們也可以把頻道看作是電臺，其中訂閱者可以同時收聽多個電臺，而發送者則可以在任何電臺發送信息。

本節將對發布與訂閱的相關操作進行介紹，閱讀這一節可以讓讀者學會怎樣使用發布與訂閱的相關命令，并了解到為什么本書在之后的章節里面會使用其他相似的解決方案來代替Redis提供的發布與訂閱。

下表展示了Redis提供的5個發布與訂閱命令：

考慮到publish命令和subscribe命令在Python客戶端的實現方式，一個比較簡單的演示發布與訂閱的方法，就像下面代碼清單那樣使用輔助線程（helper thread）來執行publish命令：

import redis  # 導入redis包包
import time,threading


# 與本地redis進行鏈接，地址為：localhost，端口號為6379

r = redis.StrictRedis(host="localhost", port=6379)

def publisher(n):
    #函數在開始執行時會先休眠，讓訂閱者有足夠的時間來連接服務器并監聽消息
    time.sleep(1)
    for i in range(n):
        r.publish("channel",i)
        #在發送消息之后進行短暫的休眠，讓消息可以一條接一條地出現
        time.sleep(1)

def run_pubsub():
    #啟動發送者線程，并讓它發送三條消息
    threading.Thread(target=publisher,args=(3,)).start()
    #創建訂閱對象，并對它訂閱給定的頻道
    pubsub=r.pubsub()
    pubsub.subscribe(["channel"])
    count=0
    #通過遍歷函數pubsub.listen()的執行結果來監聽訂閱消息
    for item in pubsub.listen():
        #打印接收到的每條消息
        print(item)
        count+=1
        if count==4:
            pubsub.unsubscribe()
        if count==5:
            break

if __name__ == "__main__":
    run_pubsub()

運行結果：

{"type": "subscribe", "pattern": None, "channel": b"channel", "data": 1}
{"type": "message", "pattern": None, "channel": b"channel", "data": b"0"}
{"type": "message", "pattern": None, "channel": b"channel", "data": b"1"}
{"type": "message", "pattern": None, "channel": b"channel", "data": b"2"}
{"type": "unsubscribe", "pattern": None, "channel": b"channel", "data": 0}

在剛開始訂閱一個頻道的時候，客戶端會接收到一條關于被訂閱頻道的反饋。
在退訂頻道時，客戶端會接受到一條反饋信息，告知被退訂的是哪個頻道，以及客戶端目前仍在訂閱的頻道數量。

雖然Redis的發布與訂閱非常有用，但本書只在這一節和8.5節使用了這個模式，這樣做的原因主要有以下兩個：

第一個原因和Redis系統的穩定性有關。對于舊版Redis來說，如果一個客戶端訂閱了某個或某些頻道，但它讀取消息的速度卻不夠快的話，那么不斷積壓的消息會使得Redis輸出緩沖區的體積變得越來越大，這可能會導致Redis的速度變慢，甚至直接崩潰。也可能會導致Redis被操作系統強制殺死，甚至導致操作系統本身不可用。新版的Redis不會出現這種問題，因為它會自動斷開不符合client-output-buffer-limit pubsub配置選項要求的訂閱客戶端。

第二個原因和數據傳輸的可靠性有關。任何網絡系統在執行操作時都可能會遇到斷線情況，而斷線產生的連接錯誤通常會使得網絡連接兩端的其中一端進行重新連接。本書使用的Python語言的Redis客戶端會在連接失效時自動進程重新連接，也會自動處理連接池（connection pool），諸如此類。但是，如果客戶端在執行訂閱操作的過程中斷線，那么客戶端將丟失在斷線期間發送的所有消息，因此依靠頻道來接受消息的用戶可能會對Redis提供的publish命令和subscribe命令的語義感到失望。

基于以上兩個原因，本書在第六章編寫了兩個不同的方法來實現可靠的消息傳遞操作，這兩個方法除了可以處理網絡斷線之外，還可以防止Redis因為消息擠壓而耗費過多內存（這個方法即使對于舊版的Redis也是有效的）。

如果你喜歡簡單易用的publish命令和subscribe命令，并且能夠承擔可能會丟失一小部分數據的風險，那么你也可以繼續使用Redis提供的發布與訂閱特性，而不是8.5節中提供的實現，只要記得先把client-output-buffer-limit pubsub選項設置好就行了。

到目前為止，本書介紹的大多數命令都是與特定數據類型相關的。接下來的一節要介紹的命令你可能也會用到，但它們既不屬于Redis提供的5中數據結構，也不屬于發布與訂閱特性。

上一篇文章：Python--Redis實戰：第三章：Redis命令：第五節：有序集合
下一篇文章：Python--Redis實戰：第三章：Redis命令：第七節：其他命令