共計 2378 個字符，預計需要花費 6 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

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