Redis 學習筆記2：持久化
1 什么是持久化
Redis 支持RDB和AOF 兩種持久化機制，持久化功能有效地避免因進程退出造成的數據丟失問題。當下次重啟時利用之前持久化的數據快照文件即可實現數據恢復。
配置文件：
save 100 時間，單位是s，100s內修改1次就會做更新
1.1 aof
aof 實時存儲：
1、aof的參數
- dir 存儲路徑 /. 表示在哪里啟動，文件在哪里生成
- appendonly：默認no，如果設置為yes，就打開了實時存儲
- appendfilename 存儲文件的名字
1.2 rdb
rdb 定時存儲：
1、rdb 的參數
- dir 存儲路徑 /. 表示在哪里啟動，文件在哪里生成
- rdbdfilename 存儲文件的名字
2、風險：容易丟失數據；避免風險：使用aof 實時存儲
3、如果數據沒有那么重要，可以使用rdb。
2 RDB持久化
是把當前進程數據生成快照保存到硬盤的過程，觸發RDB持久化過程分為手動觸發和自動觸發。
2.1 RDB 是什么
RDB在指定的時間間隔內將內存中的數據集快照寫入磁盤。
原理是redis 會單獨創建（fork）一個與當前進程一模一樣的子進程來進行持久化，這個子進程的所有數據（變量，環境變量，程序計數器等）都和原進程一模一樣，會先將數據寫入到一個臨時文件中，待持久化結束了，再用這個臨時文件替換上次持久化好的文件，是一個全量的過程。
整個過程，主進程不進行任何的io操作，這就確保了極高的性能。
問題1：這個持久化文件在哪里？
rdb有兩個參數：
- dir 存儲路徑 /. 表示在哪里啟動，文件在哪里生成
- rdbdfilename 存儲文件的名字
問題2：它什么時候fork子進程，或者什么時候觸發rdb持久化機制？
- shutdown時，如果沒有開啟aof，會觸發。
- 配置文件中默認的快照配置 :
- save 900 1 900秒內執行1次增刪改 就會觸發rdb
- save 300 10 300秒內執行10次增刪改 就會觸發rdb
- save 60 10000 60秒內執行10000次增刪改 就會觸發rdb
- 如果是集群的話，master就會把這些關掉（注釋掉）
- 執行命令 save 或者 bgsave ：
- save只保管，其他不管，全部阻塞；
- bgsave redis會在后臺異步進行快照操作，同時可以響應客戶端的請求。
1.執行flushall命令，但是里面是空的，無意義。（清空16個數據庫的數據）
2.2 手動觸發
手動觸發分別對應save和bgsave命令。
- ·save命令：阻塞當前Redis服務器，直到RDB過程完成為止，對于內存 比較大的實例會造成長時間阻塞，線上環境不建議使用
- ·bgsave命令：Redis進程執行fork操作創建子進程，RDB持久化過程由子進程負責，完成后自動結束。阻塞只發生在fork階段，一般時間很短。
3 AOF持久化
3.1 aof 是什么
AOF持久化以日志的形式記錄服務器所處理的每一個寫、刪除操作，查詢操作不記錄，以文本的方式記錄，可以打開文件看到詳細的操作記錄。是以增量的方式進行持久化，即一點點的進行持久化，不是一下子把所有數據都記錄下來。
原理是將redis的操作日志以追加的方式寫入文件，讀操作不記錄下來。
如：set k1 1 寫到文件，再運行這個文件，所有寫操作都做一遍。
問題1： 這個持久化文件在哪里？
aof的參數：
- dir 存儲路徑 /. 表示在哪里啟動，文件在哪里生成
- appendonly：默認no，如果設置為yes，就打開了實時存儲
- appendfilename 存儲文件的名字
問題2： 觸發機制是什么？
根據配置文件配置項：
- no：表示等操作系統進行數據緩存同步到磁盤（快，持久化沒保證）
- always：同步持久化，每次發生數據變更時，立即記錄到磁盤（慢，安全）
- everysec：表示每秒同步一次（快，但是可能會丟失1s的數據）
3.2 appendfile 文件說明：
*2 說明下面有2組命令，*
$6 代表長度為6，$
SELECT
0 代表數據放入0庫
*3
$3
set
$2
kk
$2
vv
3.3 aof 重寫機制
- 當AOF文件增長到一定大小的時候，redis能夠調用
bgrewriteaof對日志文件進行重寫。當AOF文件大小的增長率大于該配置項時自動開啟重寫（這里指超過原大小的100%）。
auto-aof-rewrite-percentage 100
- 當AOF文件增加到一定大小的時候，redis能夠調用bgrewriteaof對日志文件進行重寫。當AOF文件大小大于該配置項時自動開啟重寫。
auto-aof-rewrite-min-size 64mb
bgrewriteaof 是重寫的命令
3.4 redis 4.0 后混合持久化機制
- 4.0 版本的混合持久化默認關閉，通過 auto-use-rdb-preamble 配置參數控制。
- yes 表示開啟，no 表示禁用。
- 5.0 之后默認開啟。
混合持久化是通過bgrewriteaof完成的，不同的是當開啟混合持久化時，fork出的子進程先將共享的內存副本全量的以RDB方式寫入aof文件，然后再將重寫緩沖區的增量命令以AOF方式寫入到文件，寫入完成后通知主進程更新統計信息，并將新的含有RDB格式和AOF格式的AOF文件替換舊的AOF文件。
簡單說：新的AOF文件前半段是RDB格式的全量數據；后半段是AOF格式的增量數據。
優點：混合持久化結合了RDB持久化和AOF持久化的優點，由于絕大部分都是RDB格式，加載速度快，同時結合AOF。增量的數據以AOF方式保存了，數據更少丟失。
缺點：兼容性差，一旦開啟了混合持久化，在4.0之前版本都不能識別該aof文件，同時由于前部分是RDB格式，閱讀性比較差。
4 AOF和RDB的總結
1、redis提供了rdb持久化方案，為什么還要aof？
優化數據丟失問題，rdb會丟失最后一次快照后的數據，aof丟失不會超過2s的數據。
2、如果aof 和rdb同時存在，聽誰的？
aof
3、rdb和aof的優劣勢
1 RDB：
使用RDB好處：
- redis 數據庫只有這一個文件，方便備份，可以很容易將一個RDB文件移動到其他存儲介質上。
- RDB恢復大數據集的速度比AOF快。
- RDB可以最大化redis的性能：父進程在保存RDB文件時唯一要做的就是 fork 一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無需執行任何磁盤 I/O 操作。
使用RDB壞處：
- 需要盡量避免在服務區故障時丟失數據，雖然redis 允許設置不同的save point 來控制保存RDB文件的頻率，但是RDB文件需要保存整個數據集的狀態，所以它并不是一個輕松的操作。你可能會至少五分鐘才保存一次RDB文件，在這種情況下，一旦發生故障停機，就會丟失好幾分鐘的數據。
- 每次保存RDB的時候，Redis都要fork() 出一個子進程，并由子進程來進行實際的持久化工作。在數據集比較龐大地時候，fork()可能會非常耗時，造成服務器在某某毫秒內停止處理客戶端；如果數據集非常巨大，并且CPU時間非常緊張，那么這種停止時間甚至可能會長達整整一秒。雖然AOF重寫也需要進行 fork() ，但是無論AOF重寫的執行間隔有多長，數據的耐久性都不會有任何損失。
總結RDB：
rdb適合大規模數據恢復，對數據完整性和一致性不高，在一定間隔時間做一次備份，如果redis意外down機的話，就會丟失最后一次快照后的所有操作。
2 AOF：
使用AOF的好處：
- 讓redis變得非常耐久（nuch nore durable）
2.AOF文件是一個只進行追加操作的日志文件（append only log），因此對AOF文件的寫入不需要進行 seek，即使日志因為某些原因而包含未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機等），redis-check-aof 工具也可以輕易地修復這種問題。
3.redis 可以在AOF文件體積變得過大時，自動地在后臺對AOF進行重寫，重寫后的新 AOF 文件包含了恢復當前數據集所需要的最小命令集合。重寫操作絕對安全。 - AOF 文件有序地保存了對數據庫執行的所有的寫入操作，這些寫入操作以 Redis 協議的格式保存，因此 AOF 文件的內容非常容易被人讀懂，對文件進行分析也很輕松，導出AOF也很簡單。
使用AOF的壞處：
- 對于相同的數據集來說，AOF 文件的體積通常要大于RDB文件的體積
- 根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB。
- 在處理巨大的寫入載入時，RDB可以提供更有保證的最大延遲時間。
官方建議：兩種方式同時開啟，優先使用aof。
4、性能建議（只針對單機版redis持久化做性能建議）：
- 因為RDB文件只用作后備用途，只要15min備份一次就夠了，只保留 save 900 1 這條規則。
- 如果Enable AOF，好處就是在最惡劣情況下也只會丟失不超過2s的數據，啟動腳本較簡單，只load自己的aof文件就可以了。
- 代價一是帶來了持續的IO，二是AOF rewrite 的最后將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎不可避免。
- 只要硬盤許可，應該盡量減少AOF rewrite 頻率，AOF 重寫基礎可以設到5G以上。
浙公網安備 33010602011771號