Redis進階篇(三)：Redis持久化深入理解

1. RDB持久化

1.1 創建

簡單回顧下RDB文件的創建。

有兩種創建方式：

1. save.阻塞進程去處理(期間不處理別的請求)
2. 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的數據段和它的排版方式很相似。
比如：\0 \0 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文件的大小。

1. AOF體積過大不利於存儲。
2. AOF體積過大，使用AOF數據還原的時間更長。

AOF重寫多個鍵值對的數據一定是使用一條數據完成嗎

發生在重寫列表、哈希表、集合、有序集合可能會帶有多個元素的鍵時。

不是，如果它的值超過64項，則會用多條命令來完成。(避免客戶端輸入緩衝區溢出)

AOF誰來執行

Redis不希望AOF重寫造成服務器阻塞，所以用子進程(帶有數據副本)去處理。

AOF期間有新的數據進來會導致AOF文件與當前數據不一致嗎

不會。爲了解決這個問題，Reids設置了AOF重寫緩衝區(創建子進程後開啓)，當Redis執行命令時，redis會同時將這個信息發送給aof_buf和AOF重寫緩衝區。

擴展

過期鍵的刪除策略

1. 定時刪除。過期鍵較多的情況下，大量的CPU用於刪除鍵而影響了客戶端的請求。
2. 惰性刪除。只有過期鍵被訪問才刪除，可能會導致過期鍵過多，造成內存浪費和溢出。
3. 定期刪除。限制時長和頻率對過期鍵進行刪除，難點在於時長和頻率難以確定。

Redis的過期鍵刪除策略

Redis採用的是惰性刪除和定期刪除，配合這兩種策略來取得CPU和內存的平衡。

RDB和AOF文件中會包含過期鍵嗎

不包含。

在生成RDB和AOF文件時，程序會對鍵進行檢查，已過期的鍵不保存到文件中。

---

關注我的公衆號，隨時閱讀我的全部文章。

想看往期文章, 請點擊我的GitHub地址: https://github.com/fantj2016/java-reader

---

---