一、RDB

1.1 觸發機制

save命令：阻塞當前redis服務器，直到RDB程序完成，服務器在阻塞期間不能處理如何客戶端請求，原則上save命令已經廢棄，

bgsave命令：會fork一個子行程，RDB的持久化由這個子行程來完成，阻塞只發生在fork階段，耗時較短，子行程執行rdb期間redis服務器不會阻塞，正常處理客戶端請求，

自動觸發機制：在redis.conf 配置：

save m n

代表如果在m秒記憶體在n次的修改時，則執行bgsave命令

優點

缺點

為了解決實時持久化問題，redis引入了AOF，

AOF默認是關閉的，通過如下命令開啟：

appendonly yes

AOF作業基本流程：

命令寫入

對于每一條redis寫入命令，在AOF中會追加一條文本，文本格式是redis文本協議格式（RESP），直接采用協議格式，以來兼容性和可讀性高，二來避免了二次處理的開銷，

如果直接把命令寫入硬碟會影響到redis的性能，先寫入aof_buf，然后后期通過同步策略寫入硬碟，避免直接的IO影響到redis的性能，

檔案同步

redis提供了多種AOF緩沖區檔案同步策略，同步策略分別使用了作業系統的wirte函式和fsync函式，說明如下：

write: 會觸發延遲寫（delayed write）操作，為了性能，linux在內核提供了頁緩沖區用來提高硬碟的IO性能，write操作在寫入系統緩沖區后直接回傳，后期同步硬碟操作依賴于作業系統調度（比如按時，或者緩沖區慢等），如果在同步前出現系統宕機故障，緩沖區的資料會丟失，

fsync: 強制作業系統將緩沖區的操作同步到硬碟，

由appendfsync引數控制：

可配置的值	說明
always	命令寫入buf后呼叫系統呼叫fsync同步AOF檔案，fsync完成后執行緒回傳
no	命令寫入buf后呼叫系統呼叫write操作，后續fsync同步操作由作業系統來完成，一般為30秒一次，
everysec	命令寫入buf后呼叫系統呼叫write操作，后續fsync同步操作專門執行緒每一秒呼叫一次，

everysec是always和no的折中，是性能和安全性的這種，是redis默認的配置，也是比較推薦的配置，

檔案重寫

檔案重寫就是把Redis行程里面的最新資料轉化為寫命令然后同步到aof檔案的程序，通過重寫不但可以減小aof檔案的體積，從而進一步提高aof檔案在恢復程序中的加載速度，

由以下原因可以通過aof重寫減少aof檔案的體積：

觸發機制：

手動觸發：執行bgrewriteaof命令
自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數確定自動觸發時機：
- auto-aof-rewrite-min-size：表示運行aof重寫時檔案的最小體積，默認為64MB
- auto-aof-rewrite-percentage：表示當前aof檔案的size（aof_current_size）和上一次重寫后aof檔案的size(aof_base_size)的比值，
  
  只有當以上兩個條件同時滿足時，才會觸發自動aof

aof重寫流程：

執行aof重寫請求
父行程fork一個子行程，開銷等同于bgsave時候fork的程序
aof緩沖區寫入
1. fork結束后，主行程繼續回應客戶端請求，所有修改命令都會寫入aof_buf，后續基于appendfsync策略寫入硬碟
2. 由于fork操作運用寫時復制技術，子行程只能共享fork操作時的的記憶體資料，在執行bgrewrite期間，主行程依然在回應命令，redis用aof_rewrite_buf來保存這部分資料，防止在新的aof檔案生成期間丟失這部分資料，
寫入新的AOF，子行程基于fork后的aof_buf（快照）生成新的aof檔案
后續操作
1. 子行程發送信號通知父行程aof生成完成，父行程更新相關統計資訊
2. 父行程把aof_rewrite_buf的資料寫入到新的aof檔案
3. 使用最新的aof檔案替換老檔案，完成最終的AOF重寫，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/235955.html

標籤：NoSQL