Redis 事務 & 訊息佇列
Redis 訊息佇列介紹
什麼是訊息佇列
訊息佇列(Message Queue)是一種應用間的通訊方式,訊息傳送後可以立即返回,有訊息系統來確保資訊的可靠傳遞,訊息生產者只管把訊息釋出到訊息佇列中而不管誰來取,訊息消費者只管從訊息佇列中取訊息而不管誰釋出的,這樣釋出者和使用者都不用知道對方的存在。
為什麼使用訊息佇列
首先,我們可以知道,訊息佇列是一種非同步的工作機制,比如說日誌收集系統,為了避免資料在傳輸過程中丟失,還有訂單系統,下單後,會生成對應的單據,庫存的扣減,消費資訊的傳送,一個下單,產生這麼多的訊息,都是通過一個操作的觸發,然後將其他的訊息放入訊息佇列中,依次產生。再就是很多網站的,秒殺活動之類的,前多少名使用者會便宜,都是通過訊息佇列來實現的。
這些例子,都是通過訊息佇列,來實現,業務的解耦,最終資料的一致性,廣播,錯峰流控等等,從而完成業務的邏輯。
其他訊息佇列軟體產品
1)Rabbit-MQ(最初起源於金融系統,用於分散式系統中儲存轉發訊息,OpenStack)
2)Zero-MQ(SaltStack)
3)Kafka(Java)
4)Redis(Key:value 資料庫,快取,訊息佇列)
Redis 訊息佇列模式
訊息佇列主要分為兩種,這兩種模式 Redis 都支援
- 生產者/消費者模式:生產者生產訊息放到佇列裡,多個消費者同時監聽佇列,誰先搶到訊息誰就會從佇列中取走訊息;即對於每個訊息只能被最多一個消費者擁有;
- 釋出者/訂閱者模式:釋出者生產訊息放到佇列裡,多個監聽佇列的消費者都會收到同一份訊息;即正常情況下每個消費者收到的訊息應該都是一樣的 。
生產者 / 消費者模式
使用 LPUSH , RPOP 可以模擬生產者消費者佇列,一個訊息只能讀取一次 。
釋出者 / 訂閱者模式
Runoob 釋出 / 訂閱模式,一個訊息可以被多個訂閱者接收 。
Redis 事務
MySQL 事務處理
# 成功的事務
begin;
sql1;
sql2;
...
commit;
# 失敗的事務
begin;
sql1;
sql2;
...
rollback;
Redis 事務處理
# 開啟事務 MULTI # 結束事務(執行所有事務塊內的命令) EXEC # 取消事務(放棄執行事務塊內的所有命令) DISCARD # 監視一個(或多個) key,如果在事務執行之前這個(或這些) key 被其他命令所改動,那麼事務將被打斷 WATCH # 取消監控 UNWATCH
Redis 事務的示例
# 使用事務執行
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k100 v100
QUEUED
127.0.0.1:6379> set k200 v200
QUEUED
127.0.0.1:6379> get k200
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "v200"
# 事務取消
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> keys *
(empty list or set)
# 監控一個key
127.0.0.1:6379> WATCH k1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v1000000
QUEUED
# 另一個視窗修改k1
127.0.0.1:6379> set k1 00000
OK
# 回到第一個視窗提交事務
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> get k1
"00000"
Redis 事務的特性
原子性:不支援,不會回滾且(中間出錯也會)繼續執行
隔離性:支援,事務中的命令順序,不會被打斷,先 EXEC 先執行,單機 Redis 讀寫操作使用單程序單執行緒
永續性:不支援,Redis 資料容易丟失
一致性:不支援,要求通過樂觀鎖 Watch 來實現
Redis 事務一致性(樂觀鎖)
Redis 只支援樂觀鎖(依靠 Watch 實現)
事務(一個鍵或多個鍵)在不使用 Watch 監控時,誰後提交誰為準
事務(一個鍵或多個鍵)在使用 Watch 監控時,誰先提交誰為準
Watch 只監控一次事務並且是當前連線的事務