《Spark 快速大數據分析》是一本為 Spark 初學者準備的書，它沒有過多深入實現細節，而是更多關註上層用戶的具體用法。不過，本書絕不僅僅限於 Spark 的用法，它對 Spark 的核心概念和基本原理也有較為全面的介紹，讓讀者能夠知其然且知其所以然。 Spark快速大數據分析PDF下載 本書作 ...
一. 發佈/訂閱命令
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
