發布者和訂閱者都是redis客戶端，channel則為redis伺服器端，發布者將訊息傳送到某個的頻道，訂閱了這個頻道的訂閱者就能接收到這條訊息。redis的這種發布訂閱機制與基於主題的發布訂閱類似，channel相當於主題。
示例
以下例項演示了發布訂閱是如何工作的。在我們例項中我們建立了訂閱頻道名為 redischat:
127.0.0.1:6379> subscribe redischat
reading messages... (press ctrl-c to quit)
1) "subscribe"
2) "redischat"
3) (integer) 1
127.0.0.1:6379> publish redischat "redis is a caching teching"
(integer) 1
127.0.0.1:6379> publish redischat "hello"
(integer) 1
127.0.0.1:6379> subscribe redischat
reading messages... (press ctrl-c to quit)
1) "subscribe"
2) "redischat"
3) (integer) 1
1) "message"
2) "redischat"
3) "redis is a caching teching"
1) "message"
2) "redischat"
3) "hello"
序號命令描述1
psubscribe pattern [pattern …]
訂閱乙個或多個符合給定模式的頻道
2pubsub subcommand [argument [argument …]]
檢視訂閱與發布系統狀態
3publish channel message
將資訊傳送到指定的頻道
4punsubscribe [pattern [pattern …]]
退訂所有給定模式的頻道
5subscribe channel [channel …]
訂閱給定的乙個或多個頻道的資訊
6unsubscribe [channel [channel …]]
指退訂給定的頻道
redis發布訂閱與activemq的比較
activemq支援多種訊息協議，包括amqp，mqtt，stomp等，並且支援jms規範，但redis沒有提供對這些協議的支援；
activemq提供持久化功能，但redis無法對訊息持久化儲存，一旦訊息被傳送，如果沒有訂閱者接收，那麼訊息就會丟失；
activemq提供了訊息傳輸保障，當客戶端連線超時或事務回滾等情況發生時，訊息會被重新傳送給客戶端，redis沒有提供訊息傳輸保障。
總之，activemq所提供的功能遠比redis發布訂閱要複雜，畢竟redis不是專門做發布訂閱的，但是如果系統中已經有了redis，並且需要基本的發布訂閱功能，就沒有必要再安裝activemq了，因為可能activemq提供的功能大部分都用不到，而redis的發布訂閱機制就能滿足需求。
redis 通過 multi 、 discard 、 exec 和 watch 四個命令來實現事務功能。事務提供了一種將多個命令打包， 然後一次性、按順序地執行的機制， 並且事務在執行的期間不會主動中斷 —— 伺服器在執行完事務中的所有命令之後， 才會繼續處理其他客戶端的其他命令。
乙個事務從開始到執行會經歷以下三個階段：
示例
以下是乙個事務的例子， 它先以 multi 開始乙個事務， 然後將多個命令入隊到事務中， 最後由 exec 命令觸發事務， 一併執行事務中的所有命令：
127.0.0.1:6379> multi
ok127.0.0.1:6379> set book "c++"
queued
127.0.0.1:6379> get book
queued
127.0.0.1:6379> exec
1) ok
2) "c++"
命令描述
1discard
取消事務，放棄執行事務塊內的所有命令
2exec
執行所有事務塊內的命令
3multi
標記乙個事務塊的開始
4unwatch
取消 watch 命令對所有 key 的監視
5watch key [key …]
監視乙個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那麼事務將被打斷
為什麼redis事務不支援回滾
以下是這種做法的優點：
有種觀點認為 redis 處理事務的做法會產生 bug ， 然而需要注意的是， 在通常情況下， 回滾並不能解決程式設計錯誤帶來的問題。 舉個例子， 如果你本來想通過 incr 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤型別的鍵執行了 incr ， 回滾是沒有辦法處理這些情況的。
鑑於沒有任何機制能避免程式設計師自己造成的錯誤， 並且這類錯誤通常不會在生產環境中出現， 所以 redis 選擇了更簡單、更快速的無回滾方式來處理事務。
Redis 發布與訂閱
redis 自從2.0版本後，增加發布與訂閱等新特性，該功能有點類似設計模式中的觀察者模式，對訊息的生產者與接收者進行松耦合。也可以用該特性實現系統與系統之間的訊息傳遞，該功能的 的實現非常實用和高效。下面我們介紹一下，如何使用發布與訂閱 redis提供發布與訂閱幾個命令 subscribe cha...
redis發布與訂閱
redis在2.8.0版本之後出了乙個新功能，叫pub sub，也叫 發布與訂閱 在這篇文章中不僅要介紹它是如何用的，更重要的是要介紹它的應用場景。在之前介紹websocket之用tubesock在rails實現聊天室 五 的時候，就用redis的pub sub實現過聊天室。相關的 是這樣的 red...
Redis發布與訂閱
訂閱 發布訊息圖 第乙個 訊息傳送者，第二個 頻道 第三個 訊息訂閱者！下圖展示了頻道 channel1 以及訂閱這個頻道的三個客戶端 client2 client5 和 client1 之間的關係 當有新訊息通過 publish 命令傳送給頻道 channel1 時，這個訊息就會被傳送給訂閱它的三...