一. 釋出/訂閱命令
1.1 訊息系統
釋出/訂閱，即pub/sub，是一種訊息通訊模式：釋出者也稱訊息生產者，生產和傳送訊息到儲存系統；訂閱者也稱為訊息消費者，從儲存系統接受和消費訊息。這個儲存系統可以是檔案系統FS、訊息中介軟體MQ、資料管理系統DBMS，也可以是Redis。整個訊息釋出者、訂閱者與儲存系統統稱為訊息系統。
訊息系統中的訂閱者訂閱了某類訊息後，只要儲存系統中存在該類訊息，其就可不斷的接受並消費這些訊息。當儲存系統中沒有該訊息後，訂閱者的接受、消費阻塞。而當釋出者將訊息寫入到儲存系統後，會立即喚醒訂閱者。當儲存系統放滿時，不同的釋出者具有不同的處理方式：有的會阻塞釋出者的釋出，等待可用的儲存空間；有的則會將多餘的訊息丟失。
當然，不同的訊息系統訊息的釋出/訂閱方式也是不同的。例如RocketMQ、Kafka等訊息中介軟體構成的訊息系統中，釋出/訂閱的訊息都是以Topic分類的。而Reids構成的訊息系統中，釋出/訂閱的訊息都是以頻道Channel分類的。
1.2 subscibe
SUBSCRIBE channel [channel ...]
redis客戶端透過一個subscibe命令可以同時訂閱任意數量的頻道。在輸出了訂閱了主題後，命令處於阻塞狀態，等待相關頻道的訊息。
1.3 pubsubscibe
PSUBSCRIBE pattern [pattern ...]
訂閱一個或多個符合給定模式的頻道。
說明：這裡的模式只能使用萬用字元*。例如，it*可以匹配所有以it開頭的頻道，像it.news、it.blog、it.tweets等；news.*可以匹配所有以news.開頭的頻道，像news.global.today、news.it等。
1.4 publish
PUBLISH channel message
reids 客戶端將資訊 message 傳送到指定的頻道 channel 。返回值：接收到資訊 message 的訂閱者數量。
1.5 unsubscibe
UNSUBSCRIBE [channel [channel ...]]
redis客戶端退訂給定的頻道。
說明：如果沒有頻道被指定，也即是，一個無引數的 UNSUBSCRIBE 呼叫被執行，那麼客戶端使用 SUBSCRIBE 命令訂閱的所有頻道都會被退訂。在這種情況下，命令會返回一個資訊，告知客戶端所有被退訂的頻道。
1.6 punsubscibe
PUNSUBSCRIBE [pattern [pattern ...]]
退訂一個或多個符合給定模式的頻道。
說明：這裡的模式只能使用萬用字元*。如果沒有模式被指定，也即是，一個無引數的 PUNSUBSCRIBE 呼叫被執行，那麼客戶端使用 PSUBSCRIBE 命令訂閱的所有模式都會被退訂。在這種情況下，命令會返回一個資訊，告知客戶端所有被退訂的模式。
1.7 pubsub
PUBSUB <subcommand> [argument [argument ...]]
PUBSUB 是一個檢視訂閱與釋出系統狀態的內省命令， 它由數個不同格式的子命令組成， 以下將分別對這些子命令進行介紹。
（1）PUBSUB CHANNELS
PUBSUB CHANNELS [pattern]
列出當前的活躍頻道（活躍的意思是有訂閱者的意思）。活躍頻道指的是那些至少有一個訂閱者的頻道， 訂閱模式的客戶端不計算在內。
說明：pattern 引數是可選的。如果不給出 pattern 引數，那麼列出訂閱/釋出系統中的所有活躍頻道。如果給出 pattern 引數，那麼只列出和給定模式 pattern 相匹配的那些活躍頻道。pattern中只能使用萬用字元*。
（2）PUBSUB NUMSUB
PUBSUB NUMSUB [channel-1 ... channel-N]
返回給定頻道的訂閱者數量， 訂閱模式的客戶端不計算在內。不給定任何頻道，命令只返回一個空列表。
（3）PUBSUB NUMPAT
PUBSUB NUMPAT
返回訂閱模式的數量，所有客戶端訂閱的所有頻道模式的數量總和。 注意， 這個命令返回的不是訂閱模式的客戶端的數量， 而是客戶端訂閱的所有模式的數量總和。返回值為 一個整數回覆（Integer reply）。
二. Redis 事務
Redis的事務的本質是一組命令的批處理。這組命令在執行過程中會被順序地、一次性全部執行完畢，只要沒有出現語法錯誤，這組命令在執行期間是不會被中斷的。
2.1 Redis事務特性
Redis的事務僅保證了資料的一致性，不具有像DBMS一樣的ACID特性。
*** 這組命令中的某些命令的執行失敗不會影響其它命令的執行，不會引發回滾。即不具備原子性。
*** 這組命令透過樂觀鎖機制實現了簡單的隔離性。沒有複雜的隔離級別。
*** 這組命令的執行結果是被寫入到記憶體的，是否持久取決於Redis的持久化策略，與事務無關。
2.2 Redis事務實現
（1）三個命令
Redis事務透過三個命令進行控制。
*** muti：開啟事務。
*** exec：執行事務。
*** discard：取消事務。
（2）基本使用
下面是定義並執行事務的用法
MULTI
MULTI
標記一個事務塊的開始。事務塊內的多條命令會按照先後順序被放進一個佇列當中，最後由 EXEC 命令原子性(atomic)地執行。返回值，總是返回 OK 。
EXEC
EXEC
執行所有事務塊內的命令。假如某個(或某些) key 正處於 WATCH 命令的監視之下，且事務塊中有和這個(或這些) key 相關的命令，那麼 EXEC 命令只在這個(或這些) key 沒有被其他命令所改動的情況下執行並生效，否則該事務被打斷(abort)。返回值：事務塊內所有命令的返回值，按命令執行的先後順序排列；當操作被打斷時，返回空值 nil 。
DISCARD
DISCARD
取消事務，放棄執行事務塊內的所有命令。如果正在使用 WATCH 命令監視某個(或某些) key，那麼取消所有監視，等同於執行命令 UNWATCH 。返回值總是返回 OK 。
WATCH
WATCH key [key ...]
監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那麼事務將被打斷。返回值：總是返回 OK 。
這種又稱為 Reids的樂觀鎖，其實現原理依賴是資料記錄的版本號。
UNWATCH
UNWATCH
取消 WATCH 命令對所有 key 的監視。如果在執行 WATCH 命令之後， EXEC 命令或 DISCARD 命令先被執行了的話，那麼就不需要再執行 UNWATCH 了。因為 EXEC 命令會執行事務，因此 WATCH 命令的效果已經產生了；而 DISCARD 命令在取消事務的同時也會取消所有對 key 的監視，因此這兩個命令執行之後，就沒有必要執行 UNWATCH 了。
（3）案例
# 事務被成功執行 redis> MULTI OK redis> INCR user_id QUEUED redis> INCR user_id QUEUED redis> INCR user_id QUEUED redis> PING QUEUED redis> EXEC 1) (integer) 1 2) (integer) 2 3) (integer) 3 4) PONG # 監視 key ，且事務成功執行 redis> WATCH lock lock_times OK redis> MULTI OK redis> SET lock "huangz" QUEUED redis> INCR lock_times QUEUED redis> EXEC 1) OK 2) (integer) 1 # 監視 key ，且事務被打斷 redis> WATCH lock lock_times OK redis> MULTI OK redis> SET lock "joe" # 就在這時，另一個客戶端修改了 lock_times 的值 QUEUED redis> INCR lock_times QUEUED redis> EXEC # 因為 lock_times 被修改， joe 的事務執行失敗 (nil)
學習參閱宣告
1.【Redis影片從入門到高階】
https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】
2. 【Redis 命令參考】
https://haiyong.site/doc/redis/redis-gh-pages/hash/hscan.html