Redis持久化深入理解
用過Redis的都知道，Redis有兩種持久化方式：RDB和AOF，他們的區別大家應該都清楚，所以今天主要想分享一下這兩種持久化方式的底層原理以及實現。
如果讓你手寫一個持久化(架構級)的功能，你沒有思路的話，那希望這個文章可以給你靈感。
1. RDB持久化
1.1 建立
簡單回顧下RDB檔案的建立。
有兩種建立方式：
-
save.阻塞程序去處理(期間不處理別的請求)
-
bgsave.派生一個子程序去處理
1.2 載入
在redis服務啟動時，如果檢測到RDB檔案，會進行自動載入。
如果RDB檔案和AOF都存在，優先載入誰？
如果開啟了AOF，則會優先AOF
1.3 save的底層實現
save 900 1 save 300 10 save 60 10000
這是redis.conf配置檔案中關於RDB save時機的配置，它對映在redisServer結構體的saveparams欄位中：
struct redisServer{
....
// 儲存了redis.conf配置的屬性
struct saveparam *saveparams;
// 記錄上一次save的時間
time_t lastsave;
// 修改計數器
long long dirty;
...
};
那來看看它怎麼儲存的：
struct saveparam {
// 秒數
time_t seconds;
// 修改次數
int changes;
};
redis自己有一個定時任務每100毫秒執行一次，其中有一個任務就是檢查save條件是否滿足，如何判斷的呢？就是用lastsave與saveparam.seconds比較時間是否滿足，dirty與changes比較修改次數是否滿足。
那bgsave如何實現呢，new一個子執行緒，然後拷貝個數據副本，然後和save一樣處理。
好了，到這裡，用Java寫一個這應該是沒問題了，那RDB的檔案結構如何設計呢？我們來看看redis的設計。
1.4 RDB檔案結構
REDIS+資料庫版本號+資料型別+資料+EOF(表示資料結束)(377)+檢驗和
我們知道java中Class檔案結構很複雜，因為它包含了常量、介面、類、父類、欄位等面向物件的資訊，而RDB的就比較簡單了，因為它只需要存放資料即可。
和class結構一樣，它的開頭也是檔案標識REDIS+版本號標識.
[root@izuf6i2jk9azj2te13kjx8z redis-4.0.9]# od -c dump.rdb 0000000 R E D I S 0 0 0 8 372 t r e d i s 0000020 - v e r 005 4 . 0 . 9 372 n r e d i 0000040 s - b i t s 300 @ 372 005 c t i m e 302 0000060 231 ; 017 ] 372 b u s e d - m e m 302 310 0000100 p r 0 372 f a o f - p r e a m b l 0000120 e 300 0 376 0 373 ( 0 0 006 k - 7 5 9 9 0000140 006 v - 7 5 9 9 0 022 c p t : 254 355 0 0000160 005 t 0 a g e t O n e 4 303 L 220 ^ 303 0000200 037 254 355 0 005 s r 0 % c o m . f a n 0000220 t . c o r e . r e s p o n s e . 0000240 S 005 e r v e r R 240 016 030 222 224 e 250 : 0000260 035 323 ? 002 0 003 I 0 006 s t a t u s L 0000300 0 004 d a t 031 0 022 L j a v a / l 0000320 a n g / O b j e c t ; L 0 003 m s 0000340 g 340 005 032 f S t r i n g ; x p 0 0 0000360 0 310 y 0 036 340 005 y 037 p o j o . C 0000400 o m p e t i t i o n Z 276 231 334 b 025 ... 0140540 a 004 j a v a 377 v 006 n u m b e r 024 0140560 002 0 0 0 006 0 0 0 001 0 002 0 003 0 004 0 0140600 005 0 006 0 016 004 l i s t 001 027 027 0 0 0 0140620 024 0 0 0 006 0 0 362 002 363 002 364 002 365 002 366 0140640 002 367 377 377 - 022 036 ] 367 332 257 _
分析：
R E D I S:RDB檔案標誌 0 0 0 8：版本號 372:結束符 r e d i s 0000020 - v e r 005 4 . 0 . 9:redis-version4.0.9 r e d i 0000040 s - b i t s 300 @:redis的位數64或32 c t i m e 302 0000060 231 ; 017 ]:時間戳 u s e d - m e m 302 310 0000100 p r 0:redis使用記憶體的大小 374：RDB_OPCODE_EXPIRETIME_MS(帶有過期時間標識) 0: 表示字串 最後8位元組為校驗和
更詳細的可以檢視http://redisbook.com/preview/rdb/rdb_struct.html
手寫過Jedis的朋友都熟悉RESP協議，RDB的資料段和它的排版方式很相似。比如： 003 m s g 005 h e l l o 377就表示鍵值對：msg(3個長度):hello(5個長度)
AOF
AOF以拼接和重寫命令的方式來實現。
# 是否開啟aof appendonly yes # 檔名稱 appendfilename "appendonly.aof" # 同步方式 ##每次收到寫命令就立即強制寫入磁碟，最慢的，但是保證完全的持久化，不推薦使用 # appendfsync always ##每秒鐘強制寫入磁碟一次，在效能和持久化方面做了很好的折中，系統預設 appendfsync everysec ##完全依賴os，效能最好,持久化沒保證 # appendfsync no # aof重寫期間是否同步 no-appendfsync-on-rewrite no # 重寫觸發配置 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 載入aof時如果有錯如何處理 aof-load-truncated yes # 檔案重寫策略 aof-rewrite-incremental-fsync yes
這一段配置中，大家著重理解同步方式的配置。redis預設採用的每秒一次寫入AOF檔案的策略。
實現原理
struct redisServer {
// ...
// 存放AOF緩衝
sds aof_buf;
// ...
};
當有新的命令進來，redis就會將其(協議化後)追加到aof_buf的末尾。
同理，redis的事件迴圈也會監聽AOF的配置，如果滿足配置檔案中的同步方式appendfsync everysec等，就會將aof_buf中的內容儲存到AOF檔案裡。
為什麼要進行AOF重寫
我們知道，redis對AOF有重寫機制，用來控制AOF檔案的大小。
-
AOF體積過大不利於儲存。
-
AOF體積過大，使用AOF資料還原的時間更長。
AOF重寫多個鍵值對的資料一定是使用一條資料完成嗎
發生在重寫列表、雜湊表、集合、有序集合可能會帶有多個元素的鍵時。
不是，如果它的值超過64項，則會用多條命令來完成。(避免客戶端輸入緩衝區溢位)
AOF誰來執行
Redis不希望AOF重寫造成伺服器阻塞，所以用子程序(帶有資料副本)去處理。
AOF期間有新的資料進來會導致AOF檔案與當前資料不一致嗎
不會。為了解決這個問題，Reids設定了AOF重寫緩衝區(建立子程序後開啟)，當Redis執行命令時，redis會同時將這個資訊傳送給aof_buf和AOF重寫緩衝區。
擴充套件
過期鍵的刪除策略
-
定時刪除。過期鍵較多的情況下，大量的CPU用於刪除鍵而影響了客戶端的請求。
-
惰性刪除。只有過期鍵被訪問才刪除，可能會導致過期鍵過多，造成記憶體浪費和溢位。
-
定期刪除。限制時長和頻率對過期鍵進行刪除，難點在於時長和頻率難以確定。
Redis的過期鍵刪除策略
Redis採用的是惰性刪除和定期刪除，配合這兩種策略來取得CPU和記憶體的平衡。
RDB和AOF檔案中會包含過期鍵嗎
不包含。
在生成RDB和AOF檔案時，程式會對鍵進行檢查，已過期的鍵不儲存到檔案