Redis持久化

Redis持久化

簡介

Redis是一款單線程、高性能的基於內存的非關係型數據庫，經常使用來作分佈式緩存。Redis的數據所有都是存儲在內存裏，若是服務器忽然宕機，數據就會所有丟失。Redis有持久化機制來保證服務器宕機的狀況下數據不丟失。

Redis有兩種持久化的方式。RDB和AOF。

RDB

持久化就是將數據寫入磁盤，以持久化保存的過程。

**在指定的時間間隔內將內存中的數據集快照寫入磁盤。**恢復時將快照文件直接讀取到內存中。

RDB過程

Redis回單首創建（fork）一個子進程來持久化，會先將內存中的數據寫入一個臨時文件中，待持久化過程結束了，再用臨時文件把上次持久化的文件替換掉。整個過程當中，主進程不須要進行任何IO操做，保證了主進程的性能。

RDB默認保存在dump.rdb文件中。

-rw-rw-r-- 1 admin admin   180968 Jul  6 23:19 appendonly.aof
-rw-rw-r-- 1 admin admin 323 Jul 6 23:20 dump.rdb -rwxrwxr-x 1 admin admin 17072128 Jan 12 04:17 kinsinghRkRXtnt7Z -rw-r--r-- 1 admin admin 50744 Jan 12 04:17 red2.so 複製代碼

Fork:

fork的做用是複製一個與當前進程同樣的進程。新進程爲當前進程的子進程。子進程的數據和主進程同樣，可是一個全新的進程。子進程讀取內存中的數據，而後序列化到磁盤上。

什麼時候觸發RDB？

1. 自動觸發

redis.conf文件中的配置位置SNAPSHOTTING：

# save "" 
 save 900 1 save 300 10 save 60 10000 複製代碼

分別表示：「900秒內至少有一個key被改動、300秒內至少有10個key被改動、60秒內至少有10000個key被改動」時，觸發一次RDB操做，自動保存數據集。

save "" 表示關閉RDB。

2. 手動觸發

save或者是bgsave命令。

• save命令會阻塞，生產環境慎重。
• bgsave是在後臺異步進行快照保存，同時還能夠響應客戶端的請求。

優劣勢

1. 優點

• 整個redis中只有這一個備份文件，不用常常進行備份。適合大規模的數據恢復。
• 性能最大化。經過fork子進程來持久化，同時主進程又能繼續處理客戶端的請求。
• 相較於AOF機制，若是數據集很大，啓動時數據恢復效率更高更快。

2. 劣勢

• 若是服務器忽然宕機，還將來得及持久化的數據將會丟失。若是對數據完整性要求較高，不建議採用這種方式。
• 因爲是fork了一個與當前進程同樣的進程，包含當前進程的全部數據，因此，內存中的數據增長了一倍，性能會有所影響。

AOF

AOF過程

以日誌的形式來記錄每一個寫操做，將Redis執行過的全部寫指令都記錄下來（讀操做不須要記錄），將命令追加到日誌文件中。

Redis啓動時會讀取該文件從新構建數據，也就是將文件中保存的命令從新執行一遍，也就是重放。

AOF默認保存在appendonly.aof文件中。

-rw-rw-r-- 1 admin admin   180968 Jul  6 23:19 appendonly.aof
-rw-rw-r-- 1 admin admin 323 Jul 6 23:20 dump.rdb -rwxrwxr-x 1 admin admin 17072128 Jan 12 04:17 kinsinghRkRXtnt7Z -rw-r--r-- 1 admin admin 50744 Jan 12 04:17 red2.so 複製代碼

redis.conf文件中的配置位置APPEND ONLY MODE:

appendonly yes
 # The name of the append only file (default: "appendonly.aof")  appendfilename "appendonly.aof" 複製代碼

AOF配置項：

# appendfsync always
appendfsync everysec # appendfsync no 複製代碼

appendfsync表示redis多久將數據fsync到磁盤一次。

默認是appendfsync everysec 也就是每隔一秒就執行一次。這種配置下，即便服務器忽然宕機，最多隻丟失一秒鐘的數據。

appendfsync always表示每當有寫命令執行時都進行一次fsync，這樣能保證數據完整，可是十分影響性能。

Rewite(AOF重寫)

若是採用文件追加方式，那麼AOF文件會愈來愈大，重啓恢復時會很是耗時。因此，redis提供了AOF重寫機制，當AOF文件超過設定的閾值時，redis將aof文件重寫，只保存恢復數據的最小執行集。

rewirte原理：

AOF文件持續增加而過大時，會fork出一個新的進程來重寫文件，建立出臨時文件，將內存中的數據的set語句命令追加到臨時文件中，而後用臨時文件替換掉原來的aof文件。

rewirte沒有讀取原來的AOF文件。

觸發機制：

• bgrewiteaof 手動觸發
• Redis會記錄上次重寫時的AOF大小，默認是當AO文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。

no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 複製代碼

Redis-check-aof --fix

若是AOF文件出錯了怎麼辦？

若是在AOF的過程當中服務器宕機，命令沒有所有追加到日誌中，形成AOF文件出錯，那麼redis重啓時會拒絕載入這個文件。

咱們使用Redis-check-aof --fix來修復出錯的文件。

優劣勢

1. 優點

• 更高的數據安全性和完整性。默認狀況下每秒同步，最多丟失一秒的數據。
• Fsync也是後臺異步的，效率很是高。
• 提供 Redis-check-aof --fix機制，確保數據正確性。

2. 劣勢

• AOF文件相較於RDB文件大得多，數據恢復效率低。
• AOF雖然是後臺異步fsync追加日誌文件，不管是每秒同步仍是每修改同步，都是消耗一部分性能。

總結

• RDB保存某一時刻內存數據集的快照。
• AOF以追加形式保存的命令日誌文件。
• 一般AOF文件比RDB文件大，數據恢復效率較低。
• AOF數據安全性、完整性比RDB高，RDB丟失數據風險大。
• 根據fsync策略不一樣，AOF對redis的性能影響比RDB大。

若是同時開啓了兩種持久話方式，redis數據恢復時會採用哪種呢？

若是同時開啓兩種持久化方式，redis重啓時會採用AOF文件來恢復數據。由於AOF文件保存的數據比RDB要完整，RDB丟失數據的風險要大一些。

本文使用 mdnice 排版