用過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文件時，程序會對鍵進行檢查，已過期的鍵不保存到文件中。