一、Redis的發(fā)布和訂閱
- Redis 發(fā)布訂閱(pub/sub)是一種消息通信模式：發(fā)送者(pub)發(fā)送消息，訂閱者(sub)接收消息
- Redis 客戶端可以訂閱任意數(shù)量的頻道
- Redis的發(fā)布訂閱機制包括三個部分，發(fā)布者，訂閱者和Channel
發(fā)布者和訂閱者都是Redis客戶端，Channel則為Redis服務(wù)器端，發(fā)布者將消息發(fā)送到某個的頻道，訂閱了這個頻道的訂閱者就能接收到這條消息。Redis的這種發(fā)布訂閱機制與基于主題的發(fā)布訂閱類似，Channel相當(dāng)于主題。
示例
以下實例演示了發(fā)布訂閱是如何工作的。在我們實例中我們創(chuàng)建了訂閱頻道名為 redisChat:
127.0.0.1:6379> subscribe redisChat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1
重新開啟個 redis 客戶端，然后在同一個頻道 redisChat 發(fā)布兩次消息
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 發(fā)布訂閱的常用命令：
| 序號 | 命令 | 描述 |
|---|---|---|
| 1 | PSUBSCRIBE pattern [pattern ...] | 訂閱一個或多個符合給定模式的頻道 |
| 2 | PUBSUB subcommand [argument [argument ...]] | 查看訂閱與發(fā)布系統(tǒng)狀態(tài) |
| 3 | PUBLISH channel message | 將信息發(fā)送到指定的頻道 |
| 4 | PUNSUBSCRIBE [pattern [pattern ...]] | 退訂所有給定模式的頻道 |
| 5 | SUBSCRIBE channel [channel ...] | 訂閱給定的一個或多個頻道的信息 |
| 6 | UNSUBSCRIBE [channel [channel ...]] | 指退訂給定的頻道 |
Redis發(fā)布訂閱與ActiveMQ的比較
- ActiveMQ支持多種消息協(xié)議，包括AMQP，MQTT，Stomp等，并且支持JMS規(guī)范，但Redis沒有提供對這些協(xié)議的支持；
- ActiveMQ提供持久化功能，但Redis無法對消息持久化存儲，一旦消息被發(fā)送，如果沒有訂閱者接收，那么消息就會丟失；
- ActiveMQ提供了消息傳輸保障，當(dāng)客戶端連接超時或事務(wù)回滾等情況發(fā)生時，消息會被重新發(fā)送給客戶端，Redis沒有提供消息傳輸保障。
總之，ActiveMQ所提供的功能遠(yuǎn)比Redis發(fā)布訂閱要復(fù)雜，畢竟Redis不是專門做發(fā)布訂閱的，但是如果系統(tǒng)中已經(jīng)有了Redis，并且需要基本的發(fā)布訂閱功能，就沒有必要再安裝ActiveMQ了，因為可能ActiveMQ提供的功能大部分都用不到，而Redis的發(fā)布訂閱機制就能滿足需求。
二、Redis 事務(wù)
Redis 通過 MULTI 、 DISCARD 、 EXEC 和 WATCH 四個命令來實現(xiàn)事務(wù)功能。事務(wù)提供了一種 將多個命令打包， 然后一次性、按順序地執(zhí)行 的機制， 并且事務(wù)在執(zhí)行的期間不會主動中斷 —— 服務(wù)器在執(zhí)行完事務(wù)中的所有命令之后， 才會繼續(xù)處理其他客戶端的其他命令。
一個事務(wù)從開始到執(zhí)行會經(jīng)歷以下三個階段：
- 開始事務(wù)。
- 命令入隊。
- 執(zhí)行事務(wù)。
示例
以下是一個事務(wù)的例子， 它先以 MULTI 開始一個事務(wù)， 然后將多個命令入隊到事務(wù)中， 最后由 EXEC 命令觸發(fā)事務(wù)， 一并執(zhí)行事務(wù)中的所有命令：
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 命令的執(zhí)行是原子性的，但 Redis 沒有在事務(wù)上增加任何維持原子性的機制，所以 Redis 事務(wù)的執(zhí)行并不是原子性的
- 事務(wù)可以理解為一個打包的批量執(zhí)行腳本，但批量指令并非原子化的操作，中間某條指令的失敗不會導(dǎo)致前面已做指令的回滾，也不會造成后續(xù)的指令不做
命令
下表列出了 redis 事務(wù)的相關(guān)命令：
| 序號 | 命令 | 描述 |
|---|---|---|
| 1 | DISCARD | 取消事務(wù)，放棄執(zhí)行事務(wù)塊內(nèi)的所有命令 |
| 2 | EXEC | 執(zhí)行所有事務(wù)塊內(nèi)的命令 |
| 3 | MULTI | 標(biāo)記一個事務(wù)塊的開始 |
| 4 | UNWATCH | 取消 WATCH 命令對所有 key 的監(jiān)視 |
| 5 | WATCH key [key ...] | 監(jiān)視一個(或多個) key ，如果在事務(wù)執(zhí)行之前這個(或這些) key 被其他命令所改動，那么事務(wù)將被打斷 |
為什么redis事務(wù)不支持回滾
以下是這種做法的優(yōu)點：
- Redis 命令只會因為錯誤的語法而失?。ú⑶疫@些問題不能在入隊時發(fā)現(xiàn)），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應(yīng)該在開發(fā)的過程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中
- 因為不需要對回滾進(jìn)行支持，所以 Redis 的內(nèi)部可以保持簡單且快速
有種觀點認(rèn)為 Redis 處理事務(wù)的做法會產(chǎn)生 bug ， 然而需要注意的是， 在通常情況下， 回滾并不能解決編程錯誤帶來的問題。 舉個例子， 如果你本來想通過 INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤類型的鍵執(zhí)行了 INCR ， 回滾是沒有辦法處理這些情況的。
鑒于沒有任何機制能避免程序員自己造成的錯誤， 并且這類錯誤通常不會在生產(chǎn)環(huán)境中出現(xiàn)， 所以 Redis 選擇了更簡單、更快速的無回滾方式來處理事務(wù)。
