redis 的訂閱發布機制允許客戶端通過 publish、subscribe 等命令實現實時消息傳遞，適用于解耦組件和事件驅動架構。1. 發布消息使用 publish 命令向指定頻道發送消息；2. 訂閱頻道使用 subscribe 命令監聽一個或多個頻道；3. 取消訂閱使用 unsubscribe 命令停止接收特定頻道消息；4. 模式匹配訂閱使用 psubscribe 命令按模式訂閱多個頻道。構建簡單聊天室可讓用戶連接 redis 后訂閱頻道并發布消息，但存在消息丟失、無持久化等局限。相比 redis streams，pub/sub 更適合實時性高但可靠性要求低的場景，而 streams 支持持久化和消費者組，適用于需可靠傳遞的場景。
redis 的訂閱發布（Pub/Sub）機制允許你構建消息隊列和事件驅動的應用程序。它提供了一種發布者（publisher）向多個訂閱者（subscriber）發送消息的方式，而無需知道具體的訂閱者是誰。這對于解耦應用程序組件非常有用。
Redis 訂閱發布模式的完整實現教程
實現 Redis 的訂閱發布，大致可以分為以下幾個步驟：發布消息、訂閱頻道、取消訂閱、模式匹配訂閱。
發布消息
發布消息很簡單，使用 PUBLISH 命令即可。
PUBLISH channel "Hello, Redis Pub/Sub!"
這會將消息 “Hello, Redis Pub/Sub!” 發布到名為 “channel” 的頻道。任何訂閱了該頻道的客戶端都會收到這條消息。要注意的是，Redis 不會存儲發布的消息，如果客戶端在消息發布時沒有訂閱，那么消息就會丟失。
訂閱頻道
客戶端使用 SUBSCRIBE 命令訂閱一個或多個頻道。
SUBSCRIBE channel1 channel2
訂閱之后，客戶端會進入訂閱狀態，只能接收訂閱相關的命令（如 SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE）和接收發布到已訂閱頻道的消息。 如果嘗試執行其他命令，Redis 會返回錯誤。
收到消息后，客戶端會收到一個包含三個元素的數組：消息類型（”message”），頻道名稱，以及消息內容。
取消訂閱
使用 UNSUBSCRIBE 命令可以取消訂閱。
UNSUBSCRIBE channel1
如果不指定頻道，則取消訂閱所有已訂閱的頻道。
模式匹配訂閱
除了訂閱特定頻道，還可以使用模式匹配訂閱，使用 PSUBSCRIBE 命令。
PSUBSCRIBE news.*
這會訂閱所有以 “news.” 開頭的頻道，例如 “news.sports”、”news.politics” 等。 取消模式匹配訂閱使用 PUNSUBSCRIBE 命令。
PUNSUBSCRIBE news.*
與 UNSUBSCRIBE 類似，如果不指定模式，則取消訂閱所有已訂閱的模式。
如何使用 Redis Pub/Sub 構建一個簡單的聊天室？
構建一個簡單的聊天室，可以分為以下幾個步驟：
- 客戶端連接 Redis： 每個用戶連接到 Redis 服務器。
- 用戶訂閱聊天頻道： 用戶使用 SUBSCRIBE 命令訂閱一個特定的聊天頻道（例如 “chat:room1″）。
- 用戶發送消息： 用戶輸入消息后，客戶端使用 PUBLISH 命令將消息發布到聊天頻道。
- 所有訂閱者接收消息： 所有訂閱了該聊天頻道的用戶都會收到消息，并在客戶端顯示。
這個方案很簡單，但存在一些問題，例如沒有消息持久化，如果用戶離線，則無法收到消息。 此外，也沒有用戶身份驗證和權限管理。 可以考慮使用 Redis Streams 來解決消息持久化問題，并使用其他機制來實現用戶身份驗證和權限管理。
Redis Pub/Sub 的局限性是什么？
Redis Pub/Sub 雖然簡單易用，但也存在一些局限性：
- 消息丟失： 如前所述，Redis 不會存儲發布的消息，如果客戶端離線或未訂閱，消息就會丟失。
- 不可靠性： Redis Pub/Sub 是一種“fire and forget”的機制，不保證消息傳遞的可靠性。如果 Redis 服務器崩潰，消息可能會丟失。
- 缺乏消息確認： 發布者無法知道消息是否成功發送給所有訂閱者。
- 不支持消息持久化： 消息不會被持久化到磁盤，因此無法在服務器重啟后恢復。
對于需要可靠消息傳遞的場景，建議使用 Redis Streams 或其他消息隊列系統，例如 rabbitmq 或 kafka。 Redis Streams 提供了消息持久化、消費者組和消息確認等功能，可以更好地滿足可靠消息傳遞的需求。
Redis Pub/Sub 與 Redis Streams 有什么區別？
Redis Pub/Sub 和 Redis Streams 都是 Redis 提供的消息傳遞機制，但它們的設計目標和適用場景有所不同。
- Redis Pub/Sub： 是一種簡單的發布訂閱模式，適用于實時性要求高，但可靠性要求不高的場景，例如實時聊天、實時通知等。
- Redis Streams： 是一種更復雜的消息隊列，提供了消息持久化、消費者組和消息確認等功能，適用于需要可靠消息傳遞的場景，例如訂單處理、日志收集等。
可以簡單地理解為，Pub/Sub 更像是一個廣播系統，而 Streams 更像是一個消息隊列。 選擇哪種機制取決于具體的應用場景和需求。 如果只需要簡單的實時消息傳遞，Pub/Sub 可能更合適。 如果需要可靠的消息傳遞和消息持久化，Streams 則是更好的選擇。 也可以將兩者結合使用，例如使用 Pub/Sub 進行實時通知，使用 Streams 進行消息持久化和處理。
實際上，在某些場景下，選擇消息隊列（如 Kafka、RabbitMQ）可能比 Redis Streams 更合適，因為它們在消息可靠性、吞吐量和可擴展性方面通常更具優勢。 選擇哪種技術取決于具體的業務需求和技術棧。
