講解Redis發布訂閱演示、事務演示、持久化

推薦（免費）：redis教學

文章目錄

• 一、Redis發布訂閱介紹
• 二、Redis發布訂閱示範
• 三、Redis中的交易
• #四、轉帳功能-Redis事務示範
• 五、轉帳功能升級版-watch
• 六、交易的錯誤處理
• • 業務邏輯錯誤
  • 語法錯誤
• 七、Redis持久化
• • #RDB持久化
  • AOF持久化

RDB持久化

---

AOF持久化

一、Redis發布訂閱介紹

Redis 發布訂閱(pub/sub)是一種訊息通訊模式：發送者(pub)發送訊息，訂閱者(sub)接收訊息。 Redis 用戶端可以訂閱任意數量的頻道。

• 應用程式場景：
• #①
建立即時訊息系統
• ，例如普通的即時聊天，群聊等功能。 ②在一個部落格網站中，有n多個粉絲訂閱了你，當你發布新文章，就可以
推送訊息

給粉絲們。

③微信公眾號模式

。

二、Redis發布訂閱演示

• 發布訂閱語法# 訂閱頻道：

• #subscribe channel1 [channel2 ...] 　　　　訂閱給定的一個或多個頻道的資訊
  
  

psubscribe pattern1 [pattern2 .. .]
• 　　　　訂閱一個或多個符合給定模式的頻道。

  發佈頻道：
  
  
  publish channel message

  　　　　　　　　　　 將訊息傳送到指定的頻道。

• 取消訂閱頻道：

• #unsubscribe channel1 [ channel2 ...] 　　　指退訂給定的頻道。
  

punsubscribe pattern1 [pattern2 ...]

　　　退訂所有給定模式的頻道。

三、Redis中的交易

Redis 交易可以一次執行多個指令，（依序地串行化執行，執行中不會被其它指令插入，不許加塞）
• 事務應用程式場景：
• ##商品秒殺

轉帳

• 兩個特點：

Redis會將一個交易中的所有指令序列化，然後按順序執行(任意指令執行失敗，其餘的指令依然被執行)執行中不會被其它指令插入，不准出現加賽行為。

一個交易從開始到執行會經歷以下三個階段：開始事務、命令入隊、執行事務。

事務相關指令:
multi 　　　　　標記一個交易區塊的開始。
exec　　　　　　執行所有交易區塊內的指令。
discard 　　　　取消事務，放棄執行事務區塊內的所有指令。

watch key

　　　 監視一個(或多個)key，如果在事務執行之前這個(或這些)key被其他命令所改動，那麼事務將被打斷。 unwatch

　　　　取消watch指令對所有key的監視。

四、轉帳功能-Redis交易示範

• #需求：轉帳功能，A向B帳號轉帳50元。

轉帳前A有80元，B有10元。

轉帳後A有30元，B有60元。

本範例先以

multi
• 開始一個事務，然後將多個指令入隊到事務中，最後由
exec
• 指令觸發事務。
  
  輸入Multi指令開始，輸入的指令都會依序進入指令佇列中，但不會執行。 直到輸入Exec後，Redis會將先前的命令佇列中的命令依序執行。

執行exec前，如果發現新增的指令有問題，可以使用discard指令放棄佇列運行，類似MySQL中的回溯操作。

五、轉帳功能升級版-watch#############需求：某一帳戶在一事務內進行操作，在提交交易前，另一個進程對該帳戶進行操作。 ###

上文中的轉帳是不安全的，在執行中如果有其他命令對帳戶a或b的操作，可能會出現幻讀；解決辦法是添加watch命令，可以對帳戶進行watch監視，一旦在事務執行中，出現了其他指令對帳戶a或b操作，程式直接報錯回滾。

執行了watch指令後，如果exec或discard指令先被執行，就不需要再執行 unwatch來取消對key的監視了，因為exec或discard指令會自動取消監視。

六、交易的錯誤處理

業務邏輯錯誤

發生業務邏輯錯誤：只有報錯的指令不會被執行，而其它的指令都會執行，不會回滾。

語法錯誤

#發生語法錯誤：執行時整個的所有佇列都會被取消。

七、Redis持久化

資料存放在記憶體：高效率、但斷電記憶體資料會遺失。
資料存放在硬碟：讀寫速度慢於記憶體、但斷電資料不會遺失。

RDB持久化

RDB是redis的預設持久化機制。 RDB相當於照快照，保存的是資料的一種狀態。 (幾十G的資料可以儲存為幾KB的快照)

快照是預設的持久化方式。這種方式是就是將記憶體中資料以快照的方式寫入到二進位檔案中，預設的檔案名稱為dump.rdb(存在redis.conf檔案中)。

優點：

• 快照保存資料極快、還原資料極快
• #適用於災難備份

缺點：

• 小記憶體機器不適合使用，RDB機制符合要求就會照快照，佔記憶體。

AOF持久化

由於快照方式是在一定間隔時間做一次的，所以如果redis 意外宕機，就會失去最後一次快照後的所有修改。如果應用程式要求不能遺失任何修改的話，可以採用AOF(Append-Only File)持久化方式。

appendonly yes 指令可以啟用 AOF 持久化方式。

有三種方式如下（預設是：每秒fsync 一次）

• appendfsync always　　　　 收到寫入指令就立即寫入磁碟，最慢，但是保證完全的持久​​化
• appendfsync everysec 　　　每秒鐘寫入磁碟一次，在效能和持久化方面做了很好的折中
• appendfsync no 　　　　　　完全依賴OS，性能最好，但持久化沒保證

優點：
AOF比快照方式有更好的持久化性，是由於在使用AOF持久化方式時：redis 會將每一個收到的寫入命令都透過write 函數追加到檔案中(預設是appendonly.aof)。當redis 重新啟動時會透過重新執行檔案中儲存的寫入指令來在記憶體中重建整個資料庫的內容。

缺點：

AOF的方式也同時帶來了另一個問題。持久化檔案會變的越來越大，佔硬碟 。例如我們呼叫 incr test指令 100 次，檔案中必須保存全部的 100 個指令，其實有 99 個都是多餘的。

以上是講解Redis發布訂閱演示、事務演示、持久化的詳細內容。更多資訊請關注PHP中文網其他相關文章！