面對Redis持久化連環Call，你還頂得住嗎？
本文腦圖
Redis是一個基于內存的非關系型的數據庫，數據保存在內存中，但是內存中的數據也容易發生丟失。這里Redis就為我們提供了持久化的機制，分別是RDB(Redis DataBase)和AOF(Append Only File)。
Redis在以前的版本中是單線程的，而在6.0后對Redis的io模型做了優化，io Thread為多線程的，但是worker Thread仍然是單線程。
在Redis啟動的時候就會去加載持久化的文件，如果沒有就直接啟動，在啟動后的某一時刻會繼續持久化內存中產生的數據。
接下來我們就來詳細了解Redis的兩種持久化機制RDB(Redis DataBase)和AOF(Append Only File)。
RDB持久化機制
什么是RDB持久化呢？RDB持久化就是將當前進程的數據以生成快照的形式持久化到磁盤中。對于快照的理解，我們可以理解為將當前線程的數據以拍照的形式保存下來。
RDB持久化的時候會單獨fork一個與當前進程一摸一樣的子進程來進行持久化，因此RDB持久化有如下特點：
- 開機恢復數據快。
- 寫入持久化文件快。
RDB的持久化也是Redis默認的持久化機制，它會把內存中的數據以快照的形式寫入默認文件名為dump.rdb中保存。
在安裝后的Redis中，Redis的配置都在redis.conf文件中，如下圖所示，dbfilename就是配置RDB的持久化文件名。
持久化觸發時機
在RDB機制中觸發內存中的數據進行持久化，有以下三種方式：
（1）save命令：
save命令不會fork子進程，通過阻塞當前Redis服務器，直到RDB完成為止，所以該命令在生產中一般不會使用。save命令執行原理圖如下:
在redis.conf的配置中dir的配置就是RDB持久化后生成rdb二進制文件所在的位置，默認的位置是./，表示當前位置，哪里啟動redis，就會在哪里生成持久化文件，如下圖所示：
下面我們進行一下實操，演示一下二進制文件生成的過程，在我本機的電腦虛擬機中，我所在的位置如下，該文件夾是新創建的redis的數據存儲文件夾。
然后我們直接在該位置啟動我們的Redis服務，啟動的命令如下：
- /root/redis-4.0.6/src/redis-server /root/redis-4.0.6/redis.conf
接著通過該命令：ps -aux | grep redis，查看我們的redis服務是否正常啟動，若是顯示如下圖所示，則表示Redis是正常啟動的：
正常啟動后，直接登陸Redis，可以通過以下命令登陸Redis，如下圖所示：
因為當前中Redis是新安裝的，數據都是為空，什么都沒有，然后通過下圖的命令隨意向Redis中輸入幾條命令，最后執行save命令，在該文件夾下就會出現dump.rdb持久化的數據文件。
當然上面說到，在新安裝的Redis中默認的RDB數據持久化位置為./文件，一般我們會把它改成服務器自己的特定位置下，原理都是一樣的，可以自己進行嘗試，這里不再進行演示。
（2）bgsave命令：
bgsave命令會在后臺fork一個與Redis主線程一模一樣的子線程，由子線程負責內存中的數據持久化。
這樣fork與主線程一樣的子線程消耗了內存，但是不會阻塞主線程處理客戶端請求，是以空間換時間的方式快照內存中的數據到到文件中。
bgsave命令阻塞只會發生在fork子線程的時候，這段時間發生的非常短，可以忽略不計，如下圖是 bgsave執行的流程圖：
上面說到redis.conf中的dir配置是配置持久化文件生成的指定的目錄，dbfilename是配置生成的文件名，也可以通過命令行使用命令來動態的設置這兩個配置，命令如下：
- config set dir{newDir}
- config set dbfilename{newFileName}
（3）自動化
除了上面在命令行使用save和bgsave命令觸發持久化，也可以在redis.conf配置文件中，完成配置，如下圖所示：
在新安裝的redis中由默認的以上三個save配置，save 900 1表示900秒內如果至少有1個key值變化，則進行持久化保存數據；
save 300 10則表示300秒內如果至少有10個key值發生變化，則進行持久化，save 60 10000以此類推。
通過以上的分析可以得出以下save和bgsave的對比區別：
- save是同步持久化數據，而bgsave是異步持久化數據。
- save不會fork子進程，通過主進程持久化數據，會阻塞處理客戶端的請求，而bdsave會fork子進程持久化數據，同時還可以處理客戶端請求，高效。
- save不會消耗內存，而bgsave會消耗內存。
RDB的優缺點
缺點： RDB持久化后的文件是緊湊的二進制文件，適合于備份、全量復制、大規模數據恢復的場景，對數據完整性和一致性要求不高，RDB會丟失最后一次快照的數據。
優點： 開機的恢復數據快，寫入持久化文件快。
AOF持久化機制
AOF持久化機制是以日志的形式記錄Redis中的每一次的增刪改操作，不會記錄查詢操作，以文本的形式記錄，打開記錄的日志文件就可以查看操作記錄。
AOF是默認不開啟的，若是想開啟AOF，在如下圖的配置修改即可：
只需要把appendonly no修改為appendonly yes即可開啟，在AOF中通過appendfilename配置生成的文件名，該文件名默認為appendonly.aof，路徑也是通過dir配置的，這個與RDB的一樣，具體的配置信息如下圖所示：
AOF觸發機制
AOF帶來的持久化更加安全可靠，默認提供三種觸發機制，如下所示：
- no：表示等操作系統等數據緩存同步到磁盤中（快、持久化沒保證）。
- always：同步持久化，每次發生數據變更時，就會立即記錄到磁盤中（慢，安全）。
- everysec：表示每秒同步一次（默認值，很快，但是會丟失一秒內的數據）。
AOF中每秒同步也是異步完成的，效率是非常高的，由于該機制對日志文件的寫入操作是采用append的形式。
因此在寫入的過程即使宕機，也不會丟失已經存入日志文件的數據，數據的完整性是非常高的。
在新安裝的Redis的配置文件中，AOF的配置如下所示：
AOF重寫機制
但是，在寫入所有的操作到日志文件中時，就會出現日志文件很多重復的操作，甚至是無效的操作，導致日志文件越來越大。
所謂的無效的的操作，舉個例子，比如某一時刻對一個k++，然后后面的某一時刻k--，這樣k的值是保持不變的，那么這兩次的操作就是無效的。
如果像這樣的無效操作很多，記錄的文件臃腫，就浪費了資源空間，所以在Redis中出現了rewrite機制。
redis提供了bgrewriteaof命令。將內存中的數據以命令的方式保存到臨時文件中，同時會fork出一條新進程來將文件重寫。
重寫AOF的日志文件不是讀取舊的日志文件瘦身，而是將內存中的數據用命令的方式重寫一個AOF文件，重新保存替換原來舊的日志文件，因此內存中的數據才是最新的。
重寫操作也會fork一個子進程來處理重寫操作，重寫以內存中的數據作為重寫的源，避免了操作的冗余性，保證了數據的最新。
在Redis以append的形式將修改的數據寫入老的磁盤中 ，同時Redis也會創建一個新的文件用于記錄此期間有哪些命令被執行。
下面進行演示一下AOF的操作，首先先打開AOF機制，修改配置文件中的appendonly no為appendonly yes，然后執行如下圖的操作：
都顯示執行成功，ls以下查看此時當前的文件夾終究會出現appendonly.aof
，AOF的數據持久化文件，通過cat命令查看內容：
從上面的存儲的文件中可以看出，每一個命令是非常有規律的，比如第一次執行key *映射到該配置文件中的命令如下：
- *2 //表示該命令兩組key 為一組 * 為一組
- $6 //表示SELECT有6字符
- SELECT
- $1 //表示下面的0一個字符
- 0
然后執行set k1 1的命令，此命令映射到文件中的命令如下：
- *3 //表示該命令有三組set為一組 k1為一組 1為一組
- $3 // 表示set有三個字符
- set // 表示執行了set命令
- $2 // 表示k1有兩個字符
- k1 // key值
- $1 // 便是value值的字符長度為1
- 1 // value值
當AOF的日志文件增長到一定大小的時候Redis就能夠bgrewriteaof對日志文件進行重寫瘦身。當AOF配置文件大于改配置項時自動開啟重寫（這里指超過原大小的100%）。
該配置可以通過如下的配置項進行配置：
AOF的優缺點
優點： AOF更好保證數據不會被丟失，最多只丟失一秒內的數據，通過fork一個子進程處理持久化操作，保證了主進程不會進程io操作，能高效的處理客戶端的請求。
另外重寫操作保證了數據的有效性，即使日志文件過大也會進行重寫。
AOF的日志文件的記錄可讀性非常的高，即使某一時刻有人執行flushall清空了所有數據，只需要拿到aof的日志文件，然后把最后一條的flushall給刪除掉，就可以恢復數據。
缺點： 對于相同數量的數據集而言，AOF文件通常要大于RDB文件。RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。AOF在運行效率上往往會慢于RDB。
混合持久化
在redis4.0后混合持久化（RDB+AOF）對重寫的優化，4.0版本的混合持久化默認是關閉的，可以通過以下的配置開啟混合持久化：
混合持久化也是通過bgrewriteaof來完成的，不同的是當開啟混合持久化時，fork出的子進程先將共享內存的數據以RDB方式寫入aof文件中，然后再將重寫緩沖區的增量命令以AOF方式寫入文件中。
寫入完成后通知主進程統計信息，并將新的含有RDB格式和AOF格式的AOF文件替換舊的AOF文件。簡單的說：新的AOF文件前半段是以RDB格式的全量數據后半段是AOF格式的增量數據。
優點： 混合持久化結合RDB持久化和AOF持久化的優點，由于絕大部分的格式是RDB格式，加載速度快，增量數據以AOF方式保存，數據更少的丟失。
RDB和AOF優勢和劣勢
rdb適合大規模的數據恢復，由于rdb是以快照的形式持久化數據，恢復的數據快，在一定的時間備份一次，而aof的保證數據更加完整，損失的數據只在秒內。
具體哪種更適合生產，在官方的建議中兩種持久化機制同時開啟，如果兩種機制同時開啟，優先使用aof持久化機制。
