事實上，redis生來就不是幹訊息釋出與訂閱這件事的，一開始只是用做記憶體快取，後來才被開發出全域性唯一ID，分散式鎖，訊息佇列這些功能！

在我們一開始沒用成熟的訊息中介軟體(mq，ons，kafka)的時候，就用了redis作為訊息的釋出訂閱機制！

redis作為一個記憶體資料庫，所有的資料都在記憶體中進行操作，只提供透過非同步的方式(AOF或者RDB)進行資料的持久化，在重啟的時候，從檔案中把資料載入到記憶體，所以redis速度非常快！

redis釋出訂閱的原理又是啥？

redis通常分為client端(一般為多個)和server端，一個客戶端(釋出者)透過傳送訊息到channel中，redis server中會維護一份pubsub_channels字典，以channel為key，所有的channel訂閱者組成的連結串列為value，在訊息釋出的時候，server會使用channel取出所有的訂閱者進行遍歷，然後把訊息釋出給所有訂閱者！(為什麼使用連結串列結構？在訂閱者頻繁變動的時候，連結串列的修改時間複雜度為O(1))！

redis作為訊息釋出訂閱具體有什麼操作呢？

1，釋出者:訊息的釋出者透過redis的指令publish生產訊息，這個指令會返回相應的值，表明訊息訂閱者數量！

2，訂閱:訊息的消費者透過subscribe指令訂閱頻道(可多個)，這個指令會返回訂閱的頻道，數量，和消費的訊息！

3，模糊匹配:類似於sql中的*，redis使用psubscribe指令訂閱模糊的符合某個條件的所有頻道！

4，取消訂閱:訂閱者透過unsubscribe命令取消某個頻道的訂閱，也會有相應的返回值！

不過！！！

redis畢竟不是專門幹這個的，不提供訊息持久化，不提供訊息事務機制，如果訊息丟了，就等著乾瞪眼了，所以成熟的訊息中介軟體是一個很好的選擇！

上面這些指令很簡單，只要下載個redis映象，玩一玩就會了，更多的技術分享，敬請關注。。。

它是通長連線收訊息的，在極端的情況下會丟失訊息，如在伺服器寫訊息的時候，訂閱方突然斷開，那麼這條訊息就會永久丟失。如果僅是滿足一般的訊息驅動，是一個比較輕量的選擇，並且也可以做到廣播和單播兩種形式。如果肯下點功夫，基於訊息驅動的分散式事務也不是沒有可能。