為什么需要持久化？
Redis對資料的操作都是基于記憶體的，當遇到了行程退出、服務器宕機等意外情況，如果沒有持久化機制，那么Redis中的資料將會丟失無法恢復，有了持久化機制，Redis在下次重啟時可以利用之前持久化的檔案進行資料恢復，理解和掌握Redis的持久機制，對于Redis的日常開發和運維都有很大幫助，也是在大廠面試經常被問到的知識點，Redis支持的兩種持久化機制：
- RDB：把當前資料生成快照保存在硬碟上，
- AOF：記錄每次對資料的操作到硬碟上，
接下來，我們詳細了解一下這兩種持久化機制，
歡迎關注微信公眾號：萬貓學社，每周一分享Java技術干貨，
RDB持久化
RDB（Redis DataBase）持久化是把當前Redis中全部資料生成快照保存在硬碟上，RDB持久化可以手動觸發，也可以自動觸發，
手動觸發
save和bgsave命令都可以手動觸發RDB持久化，
save命令
執行save命令會手動觸發RDB持久化，但是save命令會阻塞Redis服務，直到RDB持久化完成，當Redis服務儲存大量資料時，會造成較長時間的阻塞，不建議使用，
> save
OK
執行后，Redis的日志中記錄：
* DB saved on disk
bgsave命令
執行bgsave命令也會手動觸發RDB持久化，和save命令不同是：Redis服務一般不會阻塞，Redis行程會執行fork操作創建子行程，RDB持久化由子行程負責，不會阻塞Redis服務行程，Redis服務的阻塞只發生在fork階段，一般情況時間很短，
> bgsave
Background saving started
執行后，Redis的日志中記錄：
* Background saving started by pid 2645
* DB saved on disk
* RDB: 0 MB of memory used by copy-on-write
* Background saving terminated with success
bgsave命令的具體流程如下圖：
- 執行
bgsave命令，Redis行程先判斷當前是否存在正在執行的RDB或AOF子執行緒，如果存在就是直接結束， - Redis行程執行fork操作創建子執行緒，在fork操作的程序中Redis行程會被阻塞，
- Redis行程fork完成后，
bgsave命令就結束了，自此Redis行程不會被阻塞，可以回應其他命令， - 子行程根據Redis行程的記憶體生成快照檔案，并替換原有的RDB檔案，
- 子行程通過信號量通知Redis行程已完成，
歡迎關注微信公眾號：萬貓學社，每周一分享Java技術干貨，
自動觸發
除了執行以上命令手動觸發以外，Redis內部可以自動觸發RDB持久化，自動觸發的RDB持久化都是采用bgsave的方式，減少Redis行程的阻塞，那么，在什么場景下會自動觸發呢？
- 在組態檔中設定了save的相關配置，如
sava m n，它表示在m秒內資料被修改過n次時，自動觸發bgsave操作， - 當從節點做全量復制時，主節點會自動執行
bgsave操作，并且把生成的RDB檔案發送給從節點， - 執行
debug reload命令時，也會自動觸發bgsave操作， - 執行
shutdown命令時，如果沒有開啟AOF持久化也會自動觸發bgsave操作，
RDB優點
RDB檔案是一個緊湊的二進制壓縮檔案，是Redis在某個時間點的全部資料快照，所以使用RDB恢復資料的速度遠遠比AOF的快，非常適合備份、全量復制、災難恢復等場景，
RDB缺點
每次進行bgsave操作都要執行fork操作創建子經常，屬于重量級操作，頻繁執行成本過高，所以無法做到實時持久化，或者秒級持久化，
另外，由于Redis版本的不斷迭代，存在不同格式的RDB版本，有可能出現低版本的RDB格式無法兼容高版本RDB檔案的問題，
歡迎關注微信公眾號：萬貓學社，每周一分享Java技術干貨，
AOF持久化
AOF（Append Only File）持久化是把每次寫命令追加寫入日志中，當需要恢復資料時重新執行AOF檔案中的命令就可以了，AOF解決了資料持久化的實時性，也是目前主流的Redis持久化方式，
AOF持久化流程
AOF流程如下圖：
- 命令追加（append）：所有寫命令都會被追加到AOF快取區（aof_buf）中，
- 檔案同步（sync）：根據不同策略將AOF快取區同步到AOF檔案中，
- 檔案重寫（rewrite）：定期對AOF檔案進行重寫，以達到壓縮的目的，
- 資料加載（load）：當需要恢復資料時，重新執行AOF檔案中的命令，
檔案同步策略
AOF持久化流程中的檔案同步有以下幾個策略：
- always：每次寫入快取區都要同步到AOF檔案中，硬碟的操作比較慢，限制了Redis高并發，不建議配置，
- no：每次寫入快取區后不進行同步，同步到AOF檔案的操作由作業系統負責，每次同步AOF檔案的周期不可控，而且增大了每次同步的硬碟的資料量，
- eversec：每次寫入快取區后，由專門的執行緒每秒鐘同步一次，做到了兼顧性能和資料安全，是建議的同步策略，也是默認的策略，
觸發檔案重寫
AOF持久化流程中的檔案重寫可以手動觸發，也可以自動觸發，
- 手動觸發：使用
bgrewriteaof命令， - 自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置確定自動觸發的時機，auto-aof-rewrite-min-size表示運行AOF重寫時檔案大小的最小值，默認為64MB；auto-aof-rewrite-percentage表示當前AOF檔案大小和上一次重寫后AOF檔案大小的比值的最小值，默認為100，只用前兩者同時超過時才會自動觸發檔案重寫，
歡迎關注微信公眾號：萬貓學社，每周一分享Java技術干貨，
AOF持久化配置
對AOF持久化的具體流程有了了解后，我們來看一下如何配置AOF，AOF持久化默認是不開啟的，需要修改組態檔，如：
# appendonly改為yes，開啟AOF
appendonly yes
# AOF檔案的名字
appendfilename "appendonly.aof"
# AOF檔案的寫入方式
# everysec 每個一秒將快取區內容寫入檔案 默認開啟的寫入方式
appendfsync everysec
# 運行AOF重寫時AOF檔案大小的增長率的最小值
auto-aof-rewrite-percentage 100
# 運行AOF重寫時檔案大小的最小值
auto-aof-rewrite-min-size 64mb
微信公眾號：萬貓學社
微信掃描二維碼
獲得更多Java技術干貨
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/4605.html
標籤：NoSQL
上一篇：現場填坑系列:mongodb 復制集跨機房同步網路問題探查
下一篇：Cassandra 簡介