Redis發布訂閱演示、事務演示、持久化的方法

小編給大家分享一下Redis發布訂閱演示、事務演示、持久化的方法，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

文章目錄

• 一、Redis發布訂閱介紹

• 二、Redis發布訂閱演示

• 三、Redis中的事務

• 四、轉賬功能-Redis事務演示

• 五、轉賬功能升級版-watch

• 六、事務的錯誤處理

• 
  

• 業務邏輯錯誤

• 語法錯誤

• 七、Redis持久化

• 
  

• 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發布訂閱演示、事務演示、持久化的方法”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！