共計 3443 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章主要講解了“Redis 中發布訂閱及事務的知識點整理”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“Redis 中發布訂閱及事務的知識點整理”吧！
一、Redis 發布訂閱
Redis 發布訂閱 (pub/sub) 是一種消息通信模式：發送者 (pub) 發送消息，訂閱者 (sub) 接收消息。
打開兩個窗口：session1 和 session2
在 session1 中訂閱消息：
subscribe xbqChannel 客戶端訂閱消息，xbqChannel 為相應的頻道
在 session2 中發布消息：
publish xbqChannel testMessge 發布消息，同時訂閱該頻道的客戶端能收到該消息
二、Redis 事務
和眾多其它數據庫一樣，Redis 作為 NoSQL 數據庫也同樣提供了事務機制。在 Redis 中，MULTI/EXEC/DISCARD/WATCH 這四個命令是我們實現事務的基石。
Redis 事務帶有以下重要的特征：
在事務中的所有命令都將會被串行化的順序執行，事務執行期間，Redis 不會再為其它客戶端的請求提供任何服務，從而保證了事物中的所有命令被原子的執行。
和關系型數據庫中的事務相比，在 Redis 事務中如果有某一條命令執行失敗，其后的命令仍然會被繼續執行。
我們可以通過 MULTI 命令開啟一個事務，有關系型數據庫開發經驗的人可以將其理解為 BEGIN TRANSACTION 語句。在該語句之后執行的命令都將被視為事務之內的操作，最后我們可以通過執行 EXEC/DISCARD 命令來提交 / 回滾該事務內的所有操作。這兩個 Redis 命令可被視為等同于關系型數據庫中的 COMMIT/ROLLBACK 語句。
在事務開啟之前，如果客戶端與服務器之間出現通訊故障并導致網絡斷開，其后所有待執行的語句都將不會被服務器執行。然而如果網絡中斷事件是發生在客戶端執行 EXEC 命令之后，那么該事務中的所有命令都會被服務器執行。
當使用 Append-Only 模式時，Redis 會通過調用系統函數 write 將該事務內的所有寫操作在本次調用中全部寫入磁盤。然而如果在寫入的過程中出現系統崩潰，如電源故障導致的宕機，那么此時也許只有部分數據被寫入到磁盤，而另外一部分數據卻已經丟失。Redis 服務器會在重新啟動時執行一系列必要的一致性檢測，一旦發現類似問題，就會立即退出并給出相應的錯誤提示。此時，我們就要充分利用 Redis 工具包中提供的 redis-check-aof 工具，該工具可以幫助我們定位到數據不一致的錯誤，并將已經寫入的部分數據進行回滾。修復之后我們就可以再次重新啟動 Redis 服務器了。
一個事務從開始到執行會經歷以下三個階段：開始事務、命令入隊、執行事務。
三、安全
1. 查看 redis 的密碼：config get requirepass
2. 為 redis 設置密碼的方法：
在 redis.conf 中進行配置：requirepass xbqpass
通過命令行進行設置：redis config set requirepass xbqpass
3. 當對 redis 進行操作時，需要授權：redis auth xbqpass
四、持久化 1、RDB（Snapshotting 快照持久化）
快照是默認的持久化方式。這種方式是就是將內存中數據以快照的方式寫入到二進制文件中, 默認的文件名為 dump.rdb。可以通過配置設置自動做快照持久化的方式。我們可以配置 redis 在 n 秒內如果超過 m 個 key 被修改就自動做快照，下面是默認的快照保存配置：
鴻蒙官方戰略合作共建——HarmonyOS 技術社區
save 900 1 #900 秒內如果超過 1 個 key 被修改，則發起快照保存
save 300 10 #300 秒內容如超過 10 個 key 被修改，則發起快照保存
save 60 10000 #在 60 秒 (1 分鐘) 之后，如果至少有 10000 個 key 發生變化，則 dump 內存快照
client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化，每次快照持久化都是將內存數據完整寫入到磁盤一次，并不是增量的只同步臟數據。如果數據量大的話，而且寫操作比較多，必然會引起大量的磁盤 io 操作，可能會嚴重影響性能。另外由于快照方式是在一定間隔時間做一次的，所以如果 redis 意外 down 掉的話，就會丟失最后一次快照后的所有修改。
2、AOF（Append-only）
redis 會將每一個收到的寫命令都通過 write 函數追加到文件中(默認是 appendonly.aof)。當 redis 重啟時會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。
鴻蒙官方戰略合作共建——HarmonyOS 技術社區
appendonly yes #啟用 aof 持久化方式
# appendfsync always #每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用
appendfsync everysec #每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦
# appendfsync no #完全依賴 os，性能最好, 持久化沒保證
3、RDB 機制的優勢和劣勢：
1.RDB 優勢:
一旦采用該方式，那么整個 Redis 數據庫將只包含一個文件，這對于文件備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近 24 小時的數據，同時還要每天歸檔一次最近 30 天的數據。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
對于災難恢復而言，RDB 是非常不錯的選擇。因為我們可以非常輕松的將一個單獨的文件壓縮后再轉移到其它存儲介質上。
性能最大化。對于 Redis 的服務進程而言，在開始持久化時，它唯一需要做的只是 fork 出子進程，之后再由子進程完成這些持久化的工作，這樣就可以極大的避免服務進程執行 IO 操作了。
相比于 AOF 機制，如果數據集很大，RDB 的啟動效率會更高。
2.RDB 劣勢：
如果你想保證數據的高可用性，即最大限度的避免數據丟失，那么 RDB 將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。
由于 RDB 是通過 fork 子進程來協助完成數據持久化工作的，因此，如果當數據集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是 1 秒鐘。
4、AOF 機制的優勢和劣勢：
1.AOF 優勢：
1). 該機制可以帶來更高的數據安全性，即數據持久性。Redis 中提供了 3 中同步策略，即每秒同步、每修改同步和不同步。事實上，每秒同步也是異步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那么這一秒鐘之內修改的數據將會丟失。而每修改同步，我們可以將其視為同步持久化，即每次發生的數據變化都會被立即記錄到磁盤中。可以預見，這種方式在效率上是最低的。
2). 由于該機制對日志文件的寫入操作采用的是 append 模式，因此在寫入過程中即使出現宕機現象，也不會破壞日志文件中已經存在的內容。然而如果我們本次操作只是寫入了一半數據就出現了系統崩潰問題，不用擔心，在 Redis 下一次啟動之前，我們可以通過 redis-check-aof 工具來幫助我們解決數據一致性的問題。
3). 如果日志過大，Redis 可以自動啟用 rewrite 機制。即 Redis 以 append 模式不斷的將修改數據寫入到老的磁盤文件中，同時 Redis 還會創建一個新的文件用于記錄此期間有哪些修改命令被執行。因此在進行 rewrite 切換時可以更好的保證數據安全性。
4). AOF 包含一個格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實上，我們也可以通過該文件完成數據的重建。
2.AOF 劣勢：
對于相同數量的數據集而言，AOF 文件通常要大于 RDB 文件。根據同步策略的不同，AOF 在運行效率上往往會慢于 RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和 RDB 一樣高效。
3. 如何修復壞損的 AOF 文件：
1). 將現有已經壞損的 AOF 文件額外拷貝出來一份。
2). 執行 redis-check-aof –fix 命令來修復壞損的 AOF 文件。
3). 用修復后的 AOF 文件重新啟動 Redis 服務器。
感謝各位的閱讀，以上就是“Redis 中發布訂閱及事務的知識點整理”的內容了，經過本文的學習后，相信大家對 Redis 中發布訂閱及事務的知識點整理這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
