Redis 釋出訂閱與事物
一、Redis的釋出和訂閱
- Redis 釋出訂閱(pub/sub)是一種訊息通訊模式：傳送者(pub)傳送訊息，訂閱者(sub)接收訊息
- Redis 客戶端可以訂閱任意數量的頻道
- Redis的釋出訂閱機制包括三個部分，釋出者，訂閱者和Channel
釋出者和訂閱者都是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
重新開啟個 redis 客戶端，然後在同一個頻道 redisChat 釋出兩次訊息
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"
命令
下面列出了Redis 釋出訂閱的常用命令：
| 序號 | 命令 | 描述 |
|---|---|---|
| 1 | PSUBSCRIBE pattern [pattern …] | 訂閱一個或多個符合給定模式的頻道 |
| 2 | PUBSUB subcommand [argument [argument …]] | 檢視訂閱與釋出系統狀態 |
| 3 | PUBLISH channel message | 將資訊傳送到指定的頻道 |
| 4 | PUNSUBSCRIBE [pattern [pattern …]] | 退訂所有給定模式的頻道 |
| 5 | SUBSCRIBE channel [channel …] | 訂閱給定的一個或多個頻道的資訊 |
| 6 | UNSUBSCRIBE [channel [channel …]] | 指退訂給定的頻道 |
Redis釋出訂閱與ActiveMQ的比較
- ActiveMQ支援多種訊息協議，包括AMQP，MQTT，Stomp等，並且支援JMS規範，但Redis沒有提供對這些協議的支援；
- ActiveMQ提供持久化功能，但Redis無法對訊息持久化儲存，一旦訊息被髮送，如果沒有訂閱者接收，那麼訊息就會丟失；
- ActiveMQ提供了訊息傳輸保障，當客戶端連線超時或事務回滾等情況發生時，訊息會被重新發送給客戶端，Redis沒有提供訊息傳輸保障。
總之，ActiveMQ所提供的功能遠比Redis釋出訂閱要複雜，畢竟Redis不是專門做釋出訂閱的，但是如果系統中已經有了Redis，並且需要基本的釋出訂閱功能，就沒有必要再安裝ActiveMQ了，因為可能ActiveMQ提供的功能大部分都用不到，而Redis的釋出訂閱機制就能滿足需求。
二、Redis 事務
Redis 通過 MULTI 、 DISCARD 、 EXEC 和 WATCH 四個命令來實現事務功能。事務提供了一種 將多個命令打包， 然後一次性、按順序地執行 的機制， 並且事務在執行的期間不會主動中斷 —— 伺服器在執行完事務中的所有命令之後， 才會繼續處理其他客戶端的其他命令。
一個事務從開始到執行會經歷以下三個階段：
- 開始事務。
- 命令入隊。
- 執行事務。
示例
以下是一個事務的例子， 它先以 MULTI 開始一個事務， 然後將多個命令入隊到事務中， 最後由 EXEC 命令觸發事務， 一併執行事務中的所有命令：
127.0.0.1:6379> multi
OK
127.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++"
注意
- 單個 Redis 命令的執行是原子性的，但 Redis 沒有在事務上增加任何維持原子性的機制，所以 Redis 事務的執行並不是原子性的
- 事務可以理解為一個打包的批量執行指令碼，但批量指令並非原子化的操作，中間某條指令的失敗不會導致前面已做指令的回滾，也不會造成後續的指令不做
命令
下表列出了 redis 事務的相關命令：
| 序號 | 命令 | 描述 |
|---|---|---|
| 1 | DISCARD | 取消事務，放棄執行事務塊內的所有命令 |
| 2 | EXEC | 執行所有事務塊內的命令 |
| 3 | MULTI | 標記一個事務塊的開始 |
| 4 | UNWATCH | 取消 WATCH 命令對所有 key 的監視 |
| 5 | WATCH key [key …] | 監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那麼事務將被打斷 |
為什麼redis事務不支援回滾
以下是這種做法的優點：
- Redis 命令只會因為錯誤的語法而失敗（並且這些問題不能在入隊時發現），或是命令用在了錯誤型別的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由程式設計錯誤造成的，而這些錯誤應該在開發的過程中被發現，而不應該出現在生產環境中
- 因為不需要對回滾進行支援，所以 Redis 的內部可以保持簡單且快速
有種觀點認為 Redis 處理事務的做法會產生 bug ， 然而需要注意的是， 在通常情況下， 回滾並不能解決程式設計錯誤帶來的問題。 舉個例子， 如果你本來想通過 INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤型別的鍵執行了 INCR ， 回滾是沒有辦法處理這些情況的。
鑑於沒有任何機制能避免程式設計師自己造成的錯誤， 並且這類錯誤通常不會在生產環境中出現， 所以 Redis 選擇了更簡單、更快速的無回滾方式來處理事務。