1、簡介
李子捌把話說在前頭，如果你是面試或者為了了解知識來學習這一知識點，我覺得是有必要的；但是如果你是作為公司的技術負責人或者項目技術選型來使用Redis的Pub/Sub做消息的發布訂閱，如果你不是走投無路了，那么你可能值得斟酌一下。Redis的Pub/Sub發布訂閱，是Redis一步步完善消息隊列功能的一個進步點，雖然現在沒人用Pub/Sub做消息隊列，但是它的思想和功能也是值得玩一下的，這個就是我寫這篇文章的主要原因。
Redis 發布訂閱 (pub/sub) 是一種消息通信模式：發送者 (pub) 發送消息，訂閱者 (sub) 接收消息。
- pub -> publisher
- sub -> subscriber
Redis客戶端訂閱一個頻道非常簡單，它可以訂閱任意數量的頻道。
如下圖，Redis客戶端訂閱（subscriber）頻道（channel）
如下圖，當消息發送到客戶端訂閱的頻道（channel）時，這個消息就會被訂閱的所有未故障的客戶端接接收到
2、實例演示
演示Redis的發布訂閱，我們需要開啟多個客戶端，訂閱頻道（channel）。
2.1 普通訂閱
如下我會啟動4個客戶端，第一個客戶端用來發布消息，其他的用來訂閱頻道，接收消息。
客戶端2、客戶端3、客戶端4同時訂閱news和weather頻道（channel）
客戶端1向頻道news/weather發布消息
此時可以看到三個客戶端均接收客戶端1向頻道news/weather發布的消息
2.2 模式訂閱
Redis為了方便同時訂閱多個模式的頻道，也有類似市面上常見的MQ中模式訂閱功能（如Rabbit MQ中的topic），這個功能可以匹配符的方式進行訂閱。
比如我需要訂閱以fund.開頭，任意字符結尾的頻道，就可以使用如下的訂閱方式
嘗試向fund.nuoan發布消息
訂閱了fund.*的客戶端，成功接收到消息
3、Pub/Sub為什么被拋棄
關于Redis的Pub/Sub為什么被拋棄，最主要的原因是它無法持久化，沒有實現持久化機制的Pub/Sub，無法做到消息的不丟失，在客戶端宕機或者Redis服務宕機的情況下，都會導致消息丟失。
- 客戶端宕機，客戶端無法接收消息
- Redis服務宕機，沒有客戶端能連接上，肯定也無法接收到消息
大部分情況下，我們都不會用到Redis去做消息中間件，市面上成熟且好用的消息中間件非常多，如果真的需要使用Redis來做消息中間件，可以考慮Redis 5.0的新數據結構Stream，這個功能在Pub/Sub的基礎上，實現了持久化機制，并且大力借鑒了kafka的設計原理，完善了Redis用于實現消息隊列的不足之處。
關于stream的知識點，請查看我的Redis專欄！
