Redis持久化總結

Redis之因此能被稱之爲內存數據庫而不僅僅是內存緩存是由於其有本身的持久化機制,能夠持久化數據庫到硬盤當中，在宕機以後能及時的恢復，其持久化方式主要有兩種，AOF和RDB,下面的內容是對這兩種方式的總結。

AOF

基本概念

AOF方式也就是Append Only File，其是在執行命令以後，將對應的日誌寫到日誌文件中的，由於是先執行操做，再寫日誌，所以不會阻塞當前的寫操做。

什麼時候將日誌刷盤，決定了Redis宕機恢復時丟失數據的多少，Redis提供了三種策略

• Always: 同步寫回，命令執行完成，立馬寫回到磁盤
• Everysec: 每秒寫回，隔一秒就將緩存頁數據寫回磁盤
• No: 依賴操做系統控制的寫回，操做系統本身決定刷盤時機。

以上三種策略，對數據的可靠性要求越高的對性能的影響也就越大，所以如何配置是一個取捨問題。

AOF日誌寫的格式是執行命令的Redis協議內容，Redis協議是文本協議，天然佔據空間比較大，而因爲其記錄的是操做流，對同一個Key的不斷修改使得AOF日誌中記錄了不少歷史的Value,爲了解決這個問題，Redis引入了AOF重寫機制,如何重寫，是否影響Redis對外提供的服務是咱們關心的內容，下面是關於AOF重寫過程的總結,以問題的形式呈現。

AOF重寫

1. 什麼時候開啓重寫

這是由redis中的配置決定的，能夠根據百分比和文件大小設置，相關的配置是auto-aof-rewrite-*

2. 重寫過程當中會不會影響Redis對外提供服務？

不會,重寫過程是後臺子進程bgrewriteaof來完成的，因爲在fork過程當中操做系統會拷貝頁表等相關信息,這個過程會阻塞，可是拷貝完成以後,子進程會同父進程共享內存空間，而父進程也因爲Copy On Write機制對內存的修改不會影響到子進程。子進程重寫AOF，父進程對外提供服務，同時工做，總體上來看仍是不會影響的。

3. 重寫過程會直接刪除原來的AOF日誌麼?

不會，原來的日誌依然會使用，直到AOF重寫完成。

4. 重寫AOF的日誌的進程內存空間是快照,那重寫過程當中的數據怎麼辦?

在重寫過程當中，數據會寫到兩個緩存中，一個是原來的AOF緩存，一個是AOF重寫緩存區，當重寫完成以後，重寫緩衝區記錄的最新操做也會寫入新的AOF文件中，以保證數據庫最新的記錄，完成以後進行替換

RDB

上面講到了AOF來記錄Redis操做,當進行數據恢復的時候，AOF須要從頭至尾執行命令才能恢復到最新的狀態，而若是可以直接將內存快照下來，就會快不少，這就是RDB也就是Redis Data Base 執行RDB操做有兩個命令能夠直接執行

• save
• bgsave

其中save是在主進程中執行save操做,會阻塞主進程，而bgsave會建立一個子進程，來負責生成快照，子進程如何作到不阻塞在上面AOF中有解釋。

對於RDB,還有一個問題是快照頻率的問題，從可靠性的角度出發，巴不得每時每刻均可以建立快照，可是因爲拷貝的是整個Redis內存數據，開銷和空間佔用都比較大，對磁盤的壓力都很大。此時AOF的優點就展示了出來，所以引出在Redis4.0中提出的AOF和RDB混合模式

AOF與RDB混合模式

混合模式同時使用了兩種方式來生成快照，在配置文件中指定的時間週期生成RDB，最後又將過程當中發生的寫操做以AOF的形式寫到快照文件中。