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 只監控一次事務並且是當前連線的事務