Redis高可用—資料持久化

Redis的高可用從以下幾個方面來保證：

• 資料持久化
• 主從復制
• 自動故障恢復
• 集群

筆者將對以上幾個方面進行逐一介紹，今天這篇文章先來介紹Redis的資料持久化，

一、為什么需要持久化？

Redis是記憶體資料庫，資料全部保存在記憶體中，如果實體宕機，資料將會全部丟失，Redis提供了完善的資料持久化機制，可以把資料持久化到磁盤上，方便我們進行備份和快速恢復資料，

二、Redis資料持久化方式

Redis提供了2種資料持久化方式：

1. RDB：將記憶體中的資料以快照的形式保存到硬碟里，生成dump.rdb檔案，該檔案是一個二進制檔案，因為RDB檔案保存在磁盤里，即使Redis服務器行程退出，RDB檔案還在，Redis服務器在啟動時檢測到RDB檔案存在，會自動載入RDB檔案，用它來還原資料庫狀態，
2. AOF：AOF持久化通過保存Redis服務器執行的寫命令記錄資料庫狀態，AOF檔案保存了Redis寫命令請求協議，是純文本格式，可以直接打開AOF檔案查看檔案內容，

注意：
1. Redis默認開啟RDB持久化功能；
2. AOF默認關閉，如果手動開啟了AOF持久化功能，會優先使用AOF檔案來還原資料庫狀態，因為AOF檔案的更新頻率通常比RDB檔案的更新頻率高，

1. RDB持久化

1.1 什么時候觸發RDB持久化？

觸發RDB持久化的情況分為：手動觸發和自動觸發，

1.1.1 手動觸發

手動觸發命令：

1. save：阻塞式，記憶體較大的實體在執行程序中會造成長時間的阻塞，期間主行程不能處理任何命令請求，
2. bgsave：fork子行程，由子行程負責RDB檔案的創建，父行程可以繼續處理命令的請求，阻塞發生在fork階段，時間較短，

1.1.2 自動觸發

自動觸發RDB的條件有：

1. 使用save配置；
   配置格式：save 【seconds】 【changes】
   表示【seconds】秒內資料集存在【changes】次修改時，自動觸發bgsave，
   默認配置為：

#只要以下3個條件中的任意一個滿足，bgsave就會執行，
#服務器在900秒內，對資料庫進行了至少1次修改
save 900 1
#服務器在300秒內，對資料庫進行了至少10次修改
save 300 10
#服務器在60秒內，對資料庫進行了至少10000次修改
save 60 10000

實作原理：

#serverCron服務定時器每100ms執行一次檢查
if(now()-rdb_last_save_time < m(指定秒數) and rdb_changes_since_last_save>n(修改次數)){
   bgsave();
}

2. 從節點執行全量復制操作；
3. 執行shutdown命令時，如果沒有開啟AOF自動執行bgsave；
4. debug reload命令；

注意：如果開啟了自動RDB，flushall因涉及的操作較多，可能會觸發自動RDB，新產生的RDB檔案將為空，

1.2 redis.conf 中RDB相關配置

#RDB自動觸發條件(滿足任意一個就可以觸發RDB)
save 900 1
save 300 10
save 60 10000
#bgsave創建快照的時候出錯了（比如，fork子行程記憶體不足或rdb檔案所在的檔案夾沒有寫入權限），redis主行程將不再接受新的寫入命令
stop-writes-on-bgsave-error yes
#對RDB檔案進行壓縮
rdbcompression yes 
#RDB檔案名稱
dbfilename dump.rdb
#對RDB進行校驗
rdbchecksum yes
 #（保存目錄，這里是相對目錄，和redis.conf是同一個目錄）
dir ./ 

1.3 RDB持久化步驟

1. 執行bgsave命令，Redis父行程判斷當前是否存在正在執行的子行程，如RDB/AOF子行程，如果存在bgsave命令直接回傳；
2. 父行程執行fork操作創建子行程，fork操作程序中父行程會阻塞，通過info stats命令查看latest_fork_usec選項，可以獲取最近一個fork操作的耗時，單位為微秒；
3. 父行程fork完成后，bgsave命令回傳“Background saving started”資訊并不再阻塞父行程，可以繼續回應其他命令；
4. 子行程創建RDB檔案，根據父行程記憶體生成臨時快照檔案，完成后對原有檔案進行原子替換，執行lastsave命令可以獲取最后一次生成RDB的時間，對應info統計的rdb_last_save_time選項，
5. 行程發送信號給父行程表示完成，父行程更新統計資訊，具體見info Persistence下的rdb_*相關選項，

注意：fork子行程時，需要生成另外一份記憶體，如果原來記憶體占用比較大，會存在記憶體膨脹的問題，
對于錯誤格式的RDB檔案，可以使用redis-check-rdb 工具進行修復，

2. AOF持久化

2.1 redis.conf 中AOF相關配置

#開啟AOF，默認關閉
appendonly yes
#AOF檔案名稱
appendfilename appendonly.aof
 #（保存目錄，這里是相對目錄，和redis.conf是同一個目錄）
dir ./ 

#AOF檔案寫入磁盤頻率
appendfsync always  #每次收到寫命令就立即強制寫入磁盤，是最安全的，但該模式下速度也是最慢的，一般不推薦使用，
appendfsync everysec #默認方式，每秒鐘強制寫入磁盤一次，在性能和持久化方面做平衡，推薦該方式，
appendfsync no  #完全依賴作業系統的寫入，一般為30秒左右一次，性能最好但是持久化最沒有保證，不推薦，

/*AOF重寫相關命令*/
#在日志重寫時，不進行命令追加操作，而只是將其放在緩沖區里，避免與命令的追加造成DISK IO上的沖突，設定為yes表示rewrite期間對新寫操作不fsync,暫時存在記憶體中,等rewrite完成后再寫入，默認為no，建議yes
no-appendfsync-on-rewrite yes
#AOF重寫觸發條件
auto-aof-rewrite-percentage 100 #當前AOF檔案大小是上次日志重寫得到AOF檔案大小的二倍時，自動啟動新的日志重寫程序，
auto-aof-rewrite-min-size 64mb #當前AOF檔案啟動新的日志重寫程序的最小值，避免剛剛啟動Reids時由于檔案尺寸較小導致頻繁的重寫，

2.2 AOF持久化步驟

AOF持久化的實作可以分為：命令追加、檔案寫入、檔案同步3個步驟，

1. 命名追加：服務器在執行完一個寫命令后，會以協議格式將被執行的寫命令追加到服務器狀態的aof_buf緩沖區的末尾；
2. 檔案寫入和同步：服務器定時會檢查是否需要將aof_buf快取區中的內容寫入和保存到AOF檔案中，是否需要檔案寫入是根據appendfsync 選項設定的，可以從AOF持久化的效率和安全性出發，設定appendfsync 選項的值，

注意：對于錯誤格式的AOF檔案，先進行備份，然后采用redis-check-aof --fix命令進行修復，修復后使用diff-u對比資料的差異，找出丟失的資料，有些可以人工修改補全，

2.3 AOF重寫

2.3.1 為什么AOF重寫？

寫命令追加到AOF檔案，AOF會越來越大，占用過多的硬碟空間，并且重啟之后的資料加載也會很慢，因此需要AOF重寫，

2.3.2 AOF重寫觸發機制

觸發AOF重寫的方式分為：手動觸發、自動觸發，

1. 手動觸發：手動執行命令BGREWRITEAOF；

2. 自動觸發：通過配置redis.conf中auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size來實作，這兩個條件同時滿足時觸發AOF，

2.3.3 AOF重寫規則

AOF重寫并不會對現有AOF檔案進行讀取和分析操作，它是通過讀取服務器當前資料庫狀態來實作的，
因此過期的資料不會寫入新AOF檔案，之前針對同一個key的多個命令也會因為直接讀取資料庫狀態由一個命令代替，并且，為避免一個key包含的資料過多導致客戶端輸入緩沖區溢位，重寫程式在處理串列、集合、有序集合、哈希等可能包含多個元素的鍵時，會先判斷鍵所包含的元素數量，如果超過配置的常量值（默認是64）了，會拆分為多個命令，

2.3.4 AOF重寫步驟

1. 執行AOF重寫請求，如果當前行程正在執行AOF重寫則不執行重寫操作，如果行程在執行bgsave則等待執行完畢后再執行，
2. 父行程執行fork創建子行程，開銷等同于bgsave程序，
3. （1）主行程fork操作完成后，繼續回應其他命令，所有修改命令依然寫入AOF緩沖區并根據appendfsync策略同步到硬碟，保證原有AOF機制正確性，
   （2）由于fork操作運用寫時復制技術，子行程只能共享fork操作時的記憶體資料，由于父行程依然回應命令，Redis使用“AOF重寫緩沖區”保存這部分新資料，防止新AOF檔案生成期間丟失這部分資料，
4. 子行程根據記憶體快照，按照命令合并規則寫入到新的AOF檔案，每次批量寫入硬碟資料量由配置aof-rewrite-incremental-fsync控制，默認為32MB，防止單次刷盤資料過多造成硬碟阻塞，
5. （1）新AOF檔案寫入完成后，子行程發送信號給父行程，父行程更新統計資訊，具體見info persistence下的aof_*相關統計，
   （2）父行程把AOF重寫緩沖區的資料寫入到新的AOF檔案，
   （3）使用新AOF檔案替換老檔案，完成AOF重寫，

3. RDB和AOF對比

1. RDB性能高于AOF：
   ● 采用二進制方式存盤資料，資料檔案比較小，加載快速；
   ● 存盤的時候是按照配置中的save策略來存盤，每次都是聚合很多資料批量存盤，寫入的效率很好，而AOF則一般都是作業在實時存盤或者準實時模式下，相對來說存盤的頻率高，效率卻偏低，
2. AOF資料安全性高于RDB：
   ● 存盤是基于累計批量的思想，也就是說在允許的情況下，累計的資料越多那么寫入效率也就越高，但資料的累計是靠時間的積累完成的，那么如果在長時間資料不寫入RDB，但Redis又遇到了崩潰，那么沒有寫入的資料就無法恢復了，但是AOF方式偏偏相反，根據AOF配置的存盤頻率的策略可以做到最少的資料丟失和較高的資料恢復能力，
   二者選擇的標準，就是性能和資料安全性之間的一個權衡，

三、參考文獻

1. https://zhuanlan.zhihu.com/p/111306444
2. 《Redis設計與實作》