關於Redis數據持久化的概念介紹

一、數據持久化的概述

Redis是內存數據庫，數據都是存儲在內存中，為瞭避免服務器斷電等原因導致Redis進程異常退出後數據的永久丟失，需要定期將Redis中的數據以某種形式(或命數據令)從內存保存到硬盤;當下次Redis重啟時，利用持久化文件實現數據恢復。除此之外，為瞭進行災難備份，可以將持久化文件拷貝到一個遠程位置（NFS) 。

Redis提供兩種方式進行持久化:
RDB持久化:原理是將Reids在內存中的數據庫記錄定時保存到磁盤上。(類似快照)

AOF持久化(append only file):原理是將Reids的操作日志以追加的方式寫入文件，類似於MySQL的binlogo(基於日志持久化方式）

由於AOF持久化的實時性更好，即當進程意外退出時丟失的數據更少（一般設置每秒保存一次），因此AOF是目前主流的持久化方式，RDB持久化基本都會開啟(用於集群)

1、RDB持久化

（1）RDB持久化是指在指定的時間間隔內將內存中當前進程中的數據生成快照保存到硬盤(因此也稱作快照持久化)，用二進制壓縮存儲，保存的文件後綴是rdb;當Redis重新啟動時，可以讀取快照文件恢復數據。

Redis數據庫文件，全稱Redis DataBase
-數據持久化方式之一
-數據持久化默認方式
-按照指定時間間隔，將內存中的數據集快照寫入硬盤-快照術語叫Snapshot
- 恢復時，將快照文件直接讀入內存
·定義RDB文件名
- dbfilename "dump.rdb"   #文件名

（2）觸發保存

優化設置，數據從內存保存到硬盤的頻率
- save 900 1     #15分鐘且有1個key改變時保存
- save 300 10     #5分鐘且有10個key改變時
- save 60 10000    #1分鐘且有10000個key改變時


手動進行存盤
- save    #阻塞寫存盤，保存過程中redis不允許寫入新數據
- bgsave   #不阻塞寫存盤

vim /etc/redis/6379.conf

#----219行----以下三個save條件滿足任意一個時，都會引起bgsave的調用
save 900 1 ：當時間到900秒時，如果redis數據發生瞭至少1次變化，則執行bgsave
save 300 10 ：當時間到300秒時，如果redis數據發生瞭至少10次變化，則執行bgsave
save 60 10000 ：當時間到60秒時，如果redis數據發生瞭至少10000次變化，則執行bgsave
#----242行----是否開啟RDB文件壓縮
rdbcompression yes
#----254行----指定RDB文件名
dbfilename dump.rdb
#----264行----指定RDB文件和AOF文件所在目錄
dir /var/lib/redis/6379

（3）其他自動觸發機制
除瞭save m n 以外，還有一些其他情況會觸發bgsave：
在主從復制場景下，如果從節點執行全量復制操作，則主節點會執行bgsave命令，並將rdb文件發送給從節點。

執行shutdown關閉命令時，也自動執行rdb持久化。

(4)執行流程:

使用RDB文件恢復數據
·備份數據
-備份dump.rdb 文件到其他位置
]# cp 數據庫目錄/dump.rdb  備份目錄

·恢復數據
-拷貝備份文件到數據庫目錄，重啟redis服務
]#cp 備份目錄/dump.rdb   數據庫目錄/

(4) 啟動時加載

RDB文件的載入工作是在服務器啟動時自動執行的，並沒有專門的命令。但是由於AOF的優先級更高，因此當AOF開啟時，Redis會優先載入 AOF文件來恢復數據；隻有當AOF關閉時，才會在Redis服務器啟動時檢測RDB文件，並自動載入。服務器載入RDB文件期間處於阻塞狀態，直到載入完成為止。
Redis（AOF關閉的時候）載入RDB文件時，會對RDB文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗

.AOF 持久化
RDB持久化是將進程數據寫入文件，而AOF持久化，則是將Redis執行的每次寫、刪除命令記錄到單獨的日志文件中，查詢操作不會記錄； 當Redis重啟時再次執行AOF文件中的命令來恢復數據。
與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。

2、開啟AOF

Redis服務器默認開啟RDB，關閉AOF；要開啟AOF，需要在配置文件中配置：
（1）、修改配置文件
vim /etc/redis/6379.conf

①Redis父進程首先判斷：當前是否在執行save，或bgsave/bgrewriteaof的子進程，如果在執行則bgsave命令直接返回。 bgsave/bgrewriteaof的子進程不能同時執行，主要是基於性能方面的考慮：兩個並發的子進程同時執行大量的磁盤寫操作，可能引起嚴重的性能問題。
②父進程執行fork操作創建子進程，這個過程中父進程是阻塞的，Redis不能執行來自客戶端的任何命令
③父進程fork後，bgsave命令返回”Background saving started”信息並不再阻塞父進程，並可以響應其他命令
④子進程創建RDB文件，根據父進程內存快照生成臨時快照文件，完成後對原有文件進行原子替換
⑤子進程發送信號給父進程表示完成，父進程更新統計信息

（2）、執行流程

#----700行----修改；開啟AOF
appendonly yes
#----704行----指定AOF文件名稱
appendfilename "appendonly.aof"
#----796行----是否忽略最後一條可能存在問題的指令
aof-load-truncated yes
#指redis在恢復時，會忽略最後一條可能存在問題的指令，默認為yes，即在aof寫入時，可能存在指令錯誤的問題（突然斷電導致未執行結束），這種情況下，yes會log並繼續，而no會直接恢復失敗
/etc/init.d/redis_6379 restart
#需要先取消密碼

文件重寫的觸發，分為手動觸發和自動觸發：

手動觸發：直接調用bgrewriteaof命令，該命令的執行與bgsave有些類似：都是fork子進程進行具體的工作，且都隻有在fork時阻塞。

自動觸發：通過設置auto-aof-rewrite-min-size選項和auto-aof-rewrite-percentage選項來自動執行BGREWRITEAOF。 隻有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作。

由於需要記錄Redis的每條寫命令，因此AOF不需要觸發，下面介紹AOF的執行流程。
AOF的執行流程包括：
命令追加(append)：將Redis的寫命令追加到緩沖區aof_buf
文件寫入(write)和文件同步(sync)：根據不同的同步策略將aof_buf中的內容同步到硬盤
文件重寫(rewrite)：定期重寫AOF文件，達到壓縮的目的
①、命令追加（append）
Redis先將寫命令追加到緩沖區，而不是直接寫入文件，主要是為瞭避免每次有寫命令都直接寫入硬盤，導致硬盤IO成為Redis負載的瓶頸。
命令追加的格式是Redis命令請求的協議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點。在AOF文件中，除瞭用於指定數據庫的select命令（如select 0為選中0號數據庫）是由Redis添加的，其他都是客戶端發送來的寫命令。
②、文件寫入（write）和文件同步（sync）
Redis提供瞭多種AOF緩存區的同步文件策略，策略涉及到操作系統的 write 函數和 fsync 函數，說明如下：
為瞭提高文件寫入效率，在現代操作系統中，當用戶調用write函數將數據寫入文件時，操作系統通常會將數據暫存到一個內存緩沖區裡，當緩沖區被填滿或超過瞭指定時限後，才真正將緩沖區的數據寫入到硬盤裡。這樣的操作雖然提高瞭效率，但也帶來瞭安全問題：如果計算機停機，內存緩沖區中的數據會丟失；因此系統同時提供瞭fsync、fdatasync等同步函數，可以強制操作系統立刻將緩沖區中的數據寫入到硬盤裡，從而確保數據的安全性。
AOF緩存區的同步文件策略存在三種同步方式，它們分別是：（vim /etc/redis/6379.conf ----》 729行 ）
appendfsync always： 命令寫入aof_buf後立即調用系統fsync操作同步到AOF文件，fsync完成後線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis隻能支持大約幾百TPS寫入，嚴重降低瞭Redis的性能；即便是使用固態硬盤（SSD），每秒大約也隻能處理幾萬個命令，而且會大大降低SSD的壽命。
appendfsync no： 命令寫入aof_buf後調用系統write操作，不對AOF文件做fsync同步；同步由操作系統負責，通常同步周期為30秒。這種情況下，文件同步的時間不可控，且緩沖區中堆積的數據會很多，數據安全性無法保證。
appendfsync everysec： 命令寫入aof_buf後調用系統write操作，write完成後線程返回；fsync同步文件操作由專門的線程每秒調用一次。everysec是前述兩種策略的折中，是性能和數據安全性的平衡，因此是Redis的默認配置，也是我們推薦的配置。
③、文件重寫（rewrite）
隨著時間流逝，Redis服務器執行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務器的正常運行，也會導致數據恢復需要的時間過長。
文件重寫是指定期重寫AOF文件，減小AOF文件的體積。
AOF重寫是把Redis進程內的數據轉化為寫命令，同步到新的AOF文件
不會對舊的AOF文件進行任何讀取、寫入操作
對於AOF持久化來說，文件重寫雖然是強烈推薦的，但並不是必須的；即使沒有文件重寫，數據也可以被持久化並在Redis啟動的時候導入；因此在一些實現中，會關閉自動的文件重寫，然後通過定時任務在每天的某一時刻定時執行。

文件重寫之所以能夠壓縮AOF文件，原因在於：
 過期的數據不再寫入文件
 無效的命令不再寫入文件：如有些數據被重復設值(set mykey v1, set mykey v2)、有些數據被刪除瞭(sadd myset v1, del myset)等。
 多條命令可以合並為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合並為sadd myset v1 v2 v3。

文件重寫的觸發，分為手動觸發和自動觸發：

手動觸發：直接調用bgrewriteaof命令，該命令的執行與bgsave有些類似：都是fork子進程進行具體的工作，且都隻有在fork時阻塞。

自動觸發：通過設置auto-aof-rewrite-min-size選項和auto-aof-rewrite-percentage選項來自動執行BGREWRITEAOF。 隻有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作。

auto-aof-rewrite-percentage 100 ：當前AOF文件大小(即aof_current_size)是上次日志重寫時AOF文件大小(aof_base_size)兩倍時，發生BGREWRITEAOF操作
   auto-aof-rewrite-min-size 64mb ：當前AOF文件執行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由於文件尺寸較小導致頻繁的BGREWRITEAOF



vim /etc/redis/6379.conf
#----729行----
auto-aof-rewrite-percentage 100
#當前AOF文件大小（即aof_current_size）是上次日志重寫時AOF文件大小（aof_base_size）的兩倍時，發生bgrewriteaof操作
auto-aof-rewrite-min-size 64mb 
#當前AOF文件執行bgrewriteaof命令的最小值，避免剛開始啟動redis時由於文件尺寸較小導致頻繁的bgrewriteaof

註意：
	重寫由父進程fork子進程進行
	重寫期間Redis執行的寫命令，需要追加到新的AOF文件中，為此Redis引入瞭aof_rewrite_buf緩存。

（3）、文件重寫的流程如下

Redis父進程首先判斷當前是否存在正在執行bgsave/bgrewriteaof的子進程，如果存在則bgrewriteaof命令直接返回，如果存在 bgsave命令則等bgsave執行完成後再執行。
父進程執行fork操作創建子進程，這個過程中父進程是阻塞的。
父進程fork後，bgrewriteaof命令返回”Background append only file rewrite started”信息並不再阻塞父進程， 並可以響應其他命令。Redis的所有寫命令依然寫入AOF緩沖區，並根據appendfsync策略同步到硬盤，保證原有AOF機制的正確。
由於fork操作使用寫時復制技術，子進程隻能共享fork操作時的內存數據。由於父進程依然在響應命令，因此Redis使用AOF重寫緩沖區(aof_rewrite_buf)保存這部分數據，防止新AOF文件生成期間丟失這部分數據。也就是說，bgrewriteaof執行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區。
子進程根據內存快照，按照命令合並規則寫入到新的AOF文件。
子進程寫完新的AOF文件後，向父進程發信號，父進程更新統計信息，具體可以通過info persistence查看。
父進程把AOF重寫緩沖區的數據寫入到新的AOF文件，這樣就保證瞭新AOF文件所保存的數據庫狀態和服務器當前狀態一致。
使用新的AOF文件替換老文件，完成AOF重寫。

（4）、啟動時加載
當AOF開啟時，Redis啟動時會優先載入AOF文件來恢復數據；隻有當AOF關閉時，才會載入RDB文件恢復數據。
當AOF開啟，但AOF文件不存在時，即使RDB文件存在也不會加載。
Redis載入AOF文件時，會對AOF文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。但如果是AOF文件結尾不完整(機器突然宕機等容易導致文件尾部不完整)，且aof-load-truncated參數開啟，則日志中會輸出警告，Redis忽略掉AOF文件的尾部，啟動成功。aof-load-truncated參數默認是開啟的。

二 .RDB 和 AOF 的優缺點

 1、 RDB 持久化優缺點

優點：RDB文件緊湊，體積小，網絡傳輸快，適合全量復制；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對性能的影響相對較小。
缺點：RDB文件的致命缺點在於其數據快照的持久化方式決定瞭必然做不到實時持久化，而在數據越來越重要的今天，數據的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
對於RDB持久化，一方面是bgsave在進行fork操作時Redis主進程會阻塞，另一方面，子進程向硬盤寫數據也會帶來IO壓力。

2、 AOF 持久化優缺點

與RDB持久化相對應，AOF的優點在於支持秒級持久化、兼容性好，缺點是文件大、恢復速度慢、對性能影響大。
對於AOF持久化，向硬盤寫數據的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題。
AOF文件的重寫與RDB的bgsave類似，會有fork時的阻塞和子進程的IO壓力問題。相對來說，由於AOF向硬盤中寫數據的頻率更高，因此對 Redis主進程性能的影響會更大
.Redis 性能管理
9.1查看Redis內存使用

redis-cli -h 192.168.184.10 -p 6379 #登錄
info memory #輸入指令進行查看

9.2內存碎片率
操作系統分配的內存值used_memory_rss除以Redis使用的內存值used_memory計算得出內存碎片是由操作系統低效的分配/回收物理內存導致的（不連續的物理內存分配）
跟蹤內存碎片率對理解Redis實例的資源性能是非常重要的：
內存碎片率稍大於1是合理的，這個值表示內存碎片率比較低
內存碎片率超過1.5，說明Redis消耗瞭實際需要物理內存的150%，其中50%是內存碎片率。需要在redis-cli工具上輸入shutdown save 命令，並重啟 Redis 服務器。
內存碎片率低於1的，說明Redis內存分配超出瞭物理內存，操作系統正在進行內存交換。需要增加可用物理內存或減少 Redis 內存占用。

9.3內存使用率
redis實例的內存使用率超過可用最大內存，操作系統將開始進行內存與swap空間交換。
避免內存交換發生的方法：
（1）針對緩存數據大小選擇安裝 Redis 實例
（2）盡可能的使用Hash數據結構存儲
（3）設置key的過期時間

9.4 內回收key
保證合理分配redis有限的內存資源。
當達到設置的最大閥值時，需選擇一種key的回收策略，默認情況下回收策略是禁止刪除。

配置文件中修改 maxmemory-policy 屬性值：

vim /etc/redis/6379.conf

#----598取消註釋----
maxmemory-policy noenviction

volatile-lru	：使用LRU算法從已設置過期時間的數據集合中淘汰數據
volatile-ttl	：從已設置過期時間的數據集合中挑選即將過期的數據淘汰
volatile-random	：從已設置過期時間的數據集合中隨機挑選數據淘汰
allkeys-lru		：使用LRU算法從所有數據集合中淘汰數據
allkeys-random	：從數據集合中任意選擇數據淘汰
noenviction		：禁止淘汰數據

到此這篇關於關於Redis數據的持久化的概念介紹的文章就介紹到這瞭,更多相關Redis數據持久化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：

• Redis 持久化 RDB 與 AOF的執行過程
• Redis持久化深入詳解
• Redis做數據持久化的解決方案及底層原理
• 硬核 Redis 高頻面試題解析
• docker安裝redis掛載容器卷同時開啟持久化