前言

在上一篇文章中，介紹了Redis內(nèi)存模型，從這篇文章開始，將依次介紹Redis高可用相關的知識——持久化、復制(及讀寫分離)、哨兵、以及集群。

一、Redis高可用概述

在介紹Redis高可用之前，先說明一下在Redis的語境中高可用的含義。

我們知道，在web服務器中，高可用是指服務器可以正常訪問的時間，衡量的標準是在多長時間內(nèi)可以提供正常服務（99.9%、99.99%、99.999% 等等）。但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(如主從分離、快速容災技術)，還需要考慮數(shù)據(jù)容量的擴展、數(shù)據(jù)安全不會丟失等。

在Redis中，實現(xiàn)高可用的技術主要包括持久化、復制、哨兵和集群，下面分別說明它們的作用，以及解決了什么樣的問題。

1. 持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲在硬盤，保證數(shù)據(jù)不會因進程退出而丟失。
2. 復制：復制是高可用Redis的基礎，哨兵和集群都是在復制基礎上實現(xiàn)高可用的。復制主要實現(xiàn)了數(shù)據(jù)的多機備份，以及對于讀操作的負載均衡和簡單的故障恢復。缺陷：故障恢復無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。
3. 哨兵：在復制的基礎上，哨兵實現(xiàn)了自動化的故障恢復。缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。
4. 集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現(xiàn)了較為完善的高可用方案。

二、Redis持久化概述

持久化的功能：Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲在內(nèi)存中，為了避免進程退出導致數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式(數(shù)據(jù)或命令)從內(nèi)存保存到硬盤；當下次Redis重啟時，利用持久化文件實現(xiàn)數(shù)據(jù)恢復。除此之外，為了進行災難備份，可以將持久化文件拷貝到一個遠程位置。

Redis持久化分為RDB持久化和AOF持久化：前者將當前數(shù)據(jù)保存到硬盤，后者則是將每次執(zhí)行的寫命令保存到硬盤（類似于MySQL的binlog）；由于AOF持久化的實時性更好，即當進程意外退出時丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。

下面依次介紹RDB持久化和AOF持久化；由于Redis各個版本之間存在差異，如無特殊說明，以Redis3.0為準。

三、RDB持久化

RDB持久化是將當前進程中的數(shù)據(jù)生成快照保存到硬盤(因此也稱作快照持久化)，保存的文件后綴是rdb；當Redis重新啟動時，可以讀取快照文件恢復數(shù)據(jù)。

1. 觸發(fā)條件

RDB持久化的觸發(fā)分為手動觸發(fā)和自動觸發(fā)兩種。

1) 手動觸發(fā)

save命令和bgsave命令都可以生成RDB文件。

save命令會阻塞Redis服務器進程，直到RDB文件創(chuàng)建完畢為止，在Redis服務器阻塞期間，服務器不能處理任何命令請求。

image

而bgsave命令會創(chuàng)建一個子進程，由子進程來負責創(chuàng)建RDB文件，父進程(即Redis主進程)則繼續(xù)處理請求。

image

此時服務器執(zhí)行日志如下：

image

bgsave命令執(zhí)行過程中，只有fork子進程時會阻塞服務器，而對于save命令，整個過程都會阻塞服務器，因此save已基本被廢棄，線上環(huán)境要杜絕save的使用；后文中也將只介紹bgsave命令。此外，在自動觸發(fā)RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化；下面介紹自動觸發(fā)RDB持久化的條件。

2) 自動觸發(fā)

save m n

自動觸發(fā)最常見的情況是在配置文件中通過save m n，指定當m秒內(nèi)發(fā)生n次變化時，會觸發(fā)bgsave。

例如，查看redis的默認配置文件(Linux下為redis根目錄下的redis.conf)，可以看到如下配置信息：

image

其中save 900 1的含義是：當時間到900秒時，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave；save 300 10和save 60 10000同理。當三個save條件滿足任意一個時，都會引起bgsave的調(diào)用。

save m n的實現(xiàn)原理

Redis的save m n，是通過serverCron函數(shù)、dirty計數(shù)器、和lastsave時間戳來實現(xiàn)的。

serverCron是Redis服務器的周期性操作函數(shù)，默認每隔100ms執(zhí)行一次；該函數(shù)對服務器的狀態(tài)進行維護，其中一項工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執(zhí)行bgsave。如果覺得本文有用，可以加我的群：619881427 學習更多的Java架構技術知識，包括分布式架構，微服務架構，性能優(yōu)化，源碼分析等，已經(jīng)有小伙伴錄制好視頻免費分享給新加入進來的朋友。

dirty計數(shù)器是Redis服務器維持的一個狀態(tài)，記錄了上一次執(zhí)行bgsave/save命令后，服務器狀態(tài)進行了多少次修改(包括增刪改)；而當save/bgsave執(zhí)行完成后，會將dirty重新置為0。

例如，如果Redis執(zhí)行了set mykey helloworld，則dirty值會+1；如果執(zhí)行了sadd myset v1 v2 v3，則dirty值會+3；注意dirty記錄的是服務器進行了多少次修改，而不是客戶端執(zhí)行了多少修改數(shù)據(jù)的命令。

lastsave時間戳也是Redis服務器維持的一個狀態(tài)，記錄的是上一次成功執(zhí)行save/bgsave的時間。

save m n的原理如下：每隔100ms，執(zhí)行serverCron函數(shù)；在serverCron函數(shù)中，遍歷save m n配置的保存條件，只要有一個條件滿足，就進行bgsave。對于每一個save m n條件，只有下面兩條同時滿足時才算滿足：

（1）當前時間-lastsave > m

（2）dirty >= n

save m n 執(zhí)行日志

下圖是save m n觸發(fā)bgsave執(zhí)行時，服務器打印日志的情況：

image

其他自動觸發(fā)機制

除了save m n 以外，還有一些其他情況會觸發(fā)bgsave：

• 在主從復制場景下，如果從節(jié)點執(zhí)行全量復制操作，則主節(jié)點會執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點
• 執(zhí)行shutdown命令時，自動執(zhí)行rdb持久化，如下圖所示：

image

2. 執(zhí)行流程

前面介紹了觸發(fā)bgsave的條件，下面將說明bgsave命令的執(zhí)行流程，如下圖所示

image

圖片中的5個步驟所進行的操作如下：

1. Redis父進程首先判斷：當前是否在執(zhí)行save，或bgsave/bgrewriteaof（后面會詳細介紹該命令）的子進程，如果在執(zhí)行則bgsave命令直接返回。bgsave/bgrewriteaof 的子進程不能同時執(zhí)行，主要是基于性能方面的考慮：兩個并發(fā)的子進程同時執(zhí)行大量的磁盤寫操作，可能引起嚴重的性能問題。

2. 父進程執(zhí)行fork操作創(chuàng)建子進程，這個過程中父進程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令

3. 父進程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父進程，并可以響應其他命令

4. 子進程創(chuàng)建RDB文件，根據(jù)父進程內(nèi)存快照生成臨時快照文件，完成后對原有文件進行原子替換

5. 子進程發(fā)送信號給父進程表示完成，父進程更新統(tǒng)計信息

3. RDB文件

RDB文件是經(jīng)過壓縮的二進制文件，下面介紹關于RDB文件的一些細節(jié)。

存儲路徑

RDB文件的存儲路徑既可以在啟動前配置，也可以通過命令動態(tài)設定。

配置：dir配置指定目錄，dbfilename指定文件名。默認是Redis根目錄下的dump.rdb文件。

動態(tài)設定：Redis啟動后也可以動態(tài)修改RDB存儲路徑，在磁盤損害或空間不足時非常有用；執(zhí)行命令為config set dir {newdir}和config set dbfilename {newFileName}。如下所示(Windows環(huán)境)：

image

RDB文件格式

RDB文件格式如下圖所示

image

其中各個字段的含義說明如下：

1. REDIS：常量，保存著”REDIS”5個字符。

2. db_version：RDB文件的版本號，注意不是Redis的版本號。

3. SELECTDB 0 pairs：表示一個完整的數(shù)據(jù)庫(0號數(shù)據(jù)庫)，同理SELECTDB 3 pairs表示完整的3號數(shù)據(jù)庫；只有當數(shù)據(jù)庫中有鍵值對時，RDB文件中才會有該數(shù)據(jù)庫的信息(上圖所示的Redis中只有0號和3號數(shù)據(jù)庫有鍵值對)；如果Redis中所有的數(shù)據(jù)庫都沒有鍵值對，則這一部分直接省略。其中：SELECTDB是一個常量，代表后面跟著的是數(shù)據(jù)庫號碼；0和3是數(shù)據(jù)庫號碼；pairs則存儲了具體的鍵值對信息，包括key、value值，及其數(shù)據(jù)類型、內(nèi)部編碼、過期時間、壓縮信息等等。

4. EOF：常量，標志RDB文件正文內(nèi)容結束。

5. check_sum：前面所有內(nèi)容的校驗和；Redis在載入RBD文件時，會計算前面的校驗和并與check_sum值比較，判斷文件是否損壞。

壓縮

Redis默認采用LZF算法對RDB文件進行壓縮。雖然壓縮耗時，但是可以大大減小RDB文件的體積，因此壓縮默認開啟；可以通過命令關閉：

image

需要注意的是，RDB文件的壓縮并不是針對整個文件進行的，而是對數(shù)據(jù)庫中的字符串進行的，且只有在字符串達到一定長度(20字節(jié))時才會進行。

4. 啟動時加載

RDB文件的載入工作是在服務器啟動時自動執(zhí)行的，并沒有專門的命令。但是由于AOF的優(yōu)先級更高，因此當AOF開啟時，Redis會優(yōu)先載入AOF文件來恢復數(shù)據(jù)；只有當AOF關閉時，才會在Redis服務器啟動時檢測RDB文件，并自動載入。服務器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。

Redis啟動日志中可以看到自動載入的執(zhí)行：

image

Redis載入RDB文件時，會對RDB文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。

5. RDB常用配置總結

下面是RDB常用的配置項，以及默認值；前面介紹過的這里不再詳細介紹。

• save m n：bgsave自動觸發(fā)的條件；如果沒有save m n配置，相當于自動的RDB持久化關閉，不過此時仍可以通過其他方式觸發(fā)
• stop-writes-on-bgsave-error yes：當bgsave出現(xiàn)錯誤時，Redis是否停止執(zhí)行寫命令；設置為yes，則當硬盤出現(xiàn)問題時，可以及時發(fā)現(xiàn)，避免數(shù)據(jù)的大量丟失；設置為no，則Redis無視bgsave的錯誤繼續(xù)執(zhí)行寫命令，當對Redis服務器的系統(tǒng)(尤其是硬盤)使用了監(jiān)控時，該選項考慮設置為no
• rdbcompression yes：是否開啟RDB文件壓縮
• rdbchecksum yes：是否開啟RDB文件的校驗，在寫入文件和讀取文件時都起作用；關閉checksum在寫入文件和啟動文件時大約能帶來10%的性能提升，但是數(shù)據(jù)損壞時無法發(fā)現(xiàn)
• dbfilename dump.rdb：RDB文件名
• dir ./：RDB文件和AOF文件所在目錄

四、AOF持久化

RDB持久化是將進程數(shù)據(jù)寫入文件，而AOF持久化(即Append Only File持久化)，則是將Redis執(zhí)行的每次寫命令記錄到單獨的日志文件中（有點像MySQL的binlog）；當Redis重啟時再次執(zhí)行AOF文件中的命令來恢復數(shù)據(jù)。

與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。

1. 開啟AOF

Redis服務器默認開啟RDB，關閉AOF；要開啟AOF，需要在配置文件中配置：

appendonly yes

2. 執(zhí)行流程

由于需要記錄Redis的每條寫命令，因此AOF不需要觸發(fā)，下面介紹AOF的執(zhí)行流程。

AOF的執(zhí)行流程包括：

• 命令追加(append)：將Redis的寫命令追加到緩沖區(qū)aof_buf；
• 文件寫入(write)和文件同步(sync)：根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤；
• 文件重寫(rewrite)：定期重寫AOF文件，達到壓縮的目的。

1) 命令追加(append)

Redis先將寫命令追加到緩沖區(qū)，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導致硬盤IO成為Redis負載的瓶頸。

命令追加的格式是Redis命令請求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優(yōu)點；具體格式略。在AOF文件中，除了用于指定數(shù)據(jù)庫的select命令（如select 0 為選中0號數(shù)據(jù)庫）是由Redis添加的，其他都是客戶端發(fā)送來的寫命令。

2) 文件寫入(write)和文件同步(sync)

Redis提供了多種AOF緩存區(qū)的同步文件策略，策略涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù)，說明如下：

為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中，當用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時，操作系統(tǒng)通常會將數(shù)據(jù)暫存到一個內(nèi)存緩沖區(qū)里，當緩沖區(qū)被填滿或超過了指定時限后，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會丟失；因此系統(tǒng)同時提供了fsync、fdatasync等同步函數(shù)，可以強制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里，從而確保數(shù)據(jù)的安全性。

AOF緩存區(qū)的同步文件策略由參數(shù)appendfsync控制，各個值的含義如下：

• always：命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴重降低了Redis的性能；即便是使用固態(tài)硬盤（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。
• no：命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對AOF文件做fsync同步；同步由操作系統(tǒng)負責，通常同步周期為30秒。這種情況下，文件同步的時間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會很多，數(shù)據(jù)安全性無法保證。如果覺得本文有用，可以加我的群：619881427 學習更多的Java架構技術知識，包括分布式架構，微服務架構，性能優(yōu)化，源碼分析等，已經(jīng)有小伙伴錄制好視頻免費分享給新加入進來的朋友。
• everysec：命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線程返回；fsync同步文件操作由專門的線程每秒調(diào)用一次。everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認配置，也是我們推薦的配置。

3) 文件重寫(rewrite)

隨著時間流逝，Redis服務器執(zhí)行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務器的正常運行，也會導致數(shù)據(jù)恢復需要的時間過長。

文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF重寫是把Redis進程內(nèi)的數(shù)據(jù)轉化為寫命令，同步到新的AOF文件；不會對舊的AOF文件進行任何讀取、寫入操作!

關于文件重寫需要注意的另一點是：對于AOF持久化來說，文件重寫雖然是強烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動的時候導入；因此在一些實現(xiàn)中，會關閉自動的文件重寫，然后通過定時任務在每天的某一時刻定時執(zhí)行。

文件重寫之所以能夠壓縮AOF文件，原因在于：

• 過期的數(shù)據(jù)不再寫入文件
• 無效的命令不再寫入文件：如有些數(shù)據(jù)被重復設值(set mykey v1, set mykey v2)、有些數(shù)據(jù)被刪除了(sadd myset v1, del myset)等等
• 多條命令可以合并為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3。不過為了防止單條命令過大造成客戶端緩沖區(qū)溢出，對于list、set、hash、zset類型的key，并不一定只使用一條命令；而是以某個常量為界將命令拆分為多條。這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。

image

通過上述內(nèi)容可以看出，由于重寫后AOF執(zhí)行的命令減少了，文件重寫既可以減少文件占用的空間，也可以加快恢復速度。

文件重寫的觸發(fā)

文件重寫的觸發(fā)，分為手動觸發(fā)和自動觸發(fā)：

手動觸發(fā)：直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進程進行具體的工作，且都只有在fork時阻塞。

image

此時服務器執(zhí)行日志如下：

image

自動觸發(fā)：根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)，以及aof_current_size和aof_base_size狀態(tài)確定觸發(fā)時機。

• auto-aof-rewrite-min-size：執(zhí)行AOF重寫時，文件的最小體積，默認值為64MB。
• auto-aof-rewrite-percentage：執(zhí)行AOF重寫時，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。

其中，參數(shù)可以通過config get命令查看：

image

狀態(tài)可以通過info persistence查看：

image

只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個參數(shù)同時滿足時，才會自動觸發(fā)AOF重寫，即bgrewriteaof操作。

自動觸發(fā)bgrewriteaof時，可以看到服務器日志如下：

image

文件重寫的流程

文件重寫流程如下圖所示：

image

關于文件重寫的流程，有兩點需要特別注意：(1)重寫由父進程fork子進程進行；(2)重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存。

對照上圖，文件重寫的流程如下：

1. Redis父進程首先判斷當前是否存在正在執(zhí)行 bgsave/bgrewriteaof的子進程，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。前面曾介紹過，這個主要是基于性能方面的考慮。

2. 父進程執(zhí)行fork操作創(chuàng)建子進程，這個過程中父進程是阻塞的。

3.1) 父進程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父進程，并可以響應其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機制的正確。

3.2) 由于fork操作使用寫時復制技術，子進程只能共享fork操作時的內(nèi)存數(shù)據(jù)。由于父進程依然在響應命令，因此Redis使用AOF重寫緩沖區(qū)(圖中的aof_rewrite_buf)保存這部分數(shù)據(jù)，防止新AOF文件生成期間丟失這部分數(shù)據(jù)。也就是說，bgrewriteaof執(zhí)行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區(qū)。

4. 子進程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。

5.1) 子進程寫完新的AOF文件后，向父進程發(fā)信號，父進程更新統(tǒng)計信息，具體可以通過info persistence查看。

5.2) 父進程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務器當前狀態(tài)一致。

5.3) 使用新的AOF文件替換老文件，完成AOF重寫。

3. 啟動時加載

前面提到過，當AOF開啟時，Redis啟動時會優(yōu)先載入AOF文件來恢復數(shù)據(jù)；只有當AOF關閉時，才會載入RDB文件恢復數(shù)據(jù)。

當AOF開啟，且AOF文件存在時，Redis啟動日志：

image

當AOF開啟，但AOF文件不存在時，即使RDB文件存在也不會加載(更早的一些版本可能會加載，但3.0不會)，Redis啟動日志如下：

image

文件校驗

與載入RDB文件類似，Redis載入AOF文件時，會對AOF文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。但如果是AOF文件結尾不完整(機器突然宕機等容易導致文件尾部不完整)，且aof-load-truncated參數(shù)開啟，則日志中會輸出警告，Redis忽略掉AOF文件的尾部，啟動成功。aof-load-truncated參數(shù)默認是開啟的：

image

偽客戶端

因為Redis的命令只能在客戶端上下文中執(zhí)行，而載入AOF文件時命令是直接從文件中讀取的，并不是由客戶端發(fā)送；因此Redis服務器在載入AOF文件之前，會創(chuàng)建一個沒有網(wǎng)絡連接的客戶端，之后用它來執(zhí)行AOF文件中的命令，命令執(zhí)行的效果與帶網(wǎng)絡連接的客戶端完全一樣。

4. AOF常用配置總結

下面是AOF常用的配置項，以及默認值；前面介紹過的這里不再詳細介紹。

• appendonly no：是否開啟AOF
• appendfilename "appendonly.aof"：AOF文件名
• dir ./：RDB文件和AOF文件所在目錄
• appendfsync everysec：fsync持久化策略
• no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕文件重寫時CPU和硬盤的負載（尤其是硬盤），但是可能會丟失AOF重寫期間的數(shù)據(jù)；需要在負載和安全性之間進行平衡
• auto-aof-rewrite-percentage 100：文件重寫觸發(fā)條件之一
• auto-aof-rewrite-min-size 64mb：文件重寫觸發(fā)提交之一
• aof-load-truncated yes：如果AOF文件結尾損壞，Redis啟動時是否仍載入AOF文件

五、方案選擇與常見問題

前面介紹了RDB和AOF兩種持久化方案的細節(jié)，下面介紹RDB和AOF的特點、如何選擇持久化方案，以及在持久化過程中常遇到的問題等。

1. RDB和AOF的優(yōu)缺點

RDB和AOF各有優(yōu)缺點：

RDB持久化

優(yōu)點：RDB文件緊湊，體積小，網(wǎng)絡傳輸快，適合全量復制；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優(yōu)點之一是對性能的影響相對較小。

缺點：RDB文件的致命缺點在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實時持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

與RDB持久化相對應，AOF的優(yōu)點在于支持秒級持久化、兼容性好，缺點是文件大、恢復速度慢、對性能影響大。

2. 持久化策略選擇

在介紹持久化策略之前，首先要明白無論是RDB還是AOF，持久化的開啟都是要付出性能方面代價的：對于RDB持久化，一方面是bgsave在進行fork操作時Redis主進程會阻塞，另一方面，子進程向硬盤寫數(shù)據(jù)也會帶來IO壓力；對于AOF持久化，向硬盤寫數(shù)據(jù)的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題（后面會詳細介紹這種阻塞），此外，AOF文件的重寫與RDB的bgsave類似，會有fork時的阻塞和子進程的IO壓力問題。相對來說，由于AOF向硬盤中寫數(shù)據(jù)的頻率更高，因此對Redis主進程性能的影響會更大。

在實際生產(chǎn)環(huán)境中，根據(jù)數(shù)據(jù)量、應用對數(shù)據(jù)的安全要求、預算限制等不同情況，會有各種各樣的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一種，或同時開啟RDB和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一起考慮，因為主從復制與持久化同樣具有數(shù)據(jù)備份的功能，而且主機master和從機slave可以獨立的選擇持久化方案。

下面分場景來討論持久化策略的選擇，下面的討論也只是作為參考，實際方案可能更復雜更具多樣性。

（1）如果Redis中的數(shù)據(jù)完全丟棄也沒有關系（如Redis完全用作DB層數(shù)據(jù)的cache），那么無論是單機，還是主從架構，都可以不進行任何持久化。

（2）在單機環(huán)境下（對于個人開發(fā)者，這種情況可能比較常見），如果可以接受十幾分鐘或更多的數(shù)據(jù)丟失，選擇RDB對Redis的性能更加有利；如果只能接受秒級別的數(shù)據(jù)丟失，應該選擇AOF。

（3）但在多數(shù)情況下，我們都會配置主從環(huán)境，slave的存在既可以實現(xiàn)數(shù)據(jù)的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉后繼續(xù)提供服務。

在這種情況下，一種可行的做法是：

master：完全關閉持久化（包括RDB和AOF），這樣可以讓master的性能達到最好

slave：關閉RDB，開啟AOF（如果對數(shù)據(jù)安全要求不高，開啟RDB關閉AOF也可以），并定時對持久化文件進行備份（如備份到其他文件夾，并標記好備份的時間）；然后關閉AOF的自動重寫，然后添加定時任務，在每天Redis閑時（如凌晨12點）調(diào)用bgrewriteaof。

這里需要解釋一下，為什么開啟了主從復制，可以實現(xiàn)數(shù)據(jù)的熱備份，還需要設置持久化呢？因為在一些特殊情況下，主從復制仍然不足以保證數(shù)據(jù)的安全，例如：

• master和slave進程同時停止：考慮這樣一種場景，如果master和slave在同一棟大樓或同一個機房，則一次停電事故就可能導致master和slave機器同時關機，Redis進程停止；如果沒有持久化，則面臨的是數(shù)據(jù)的完全丟失。
• master誤重啟：考慮這樣一種場景，master服務因為故障宕掉了，如果系統(tǒng)中有自動拉起機制（即檢測到服務停止后重啟該服務）將master自動重啟，由于沒有持久化文件，那么master重啟后數(shù)據(jù)是空的，slave同步數(shù)據(jù)也變成了空的；如果master和slave都沒有持久化，同樣會面臨數(shù)據(jù)的完全丟失。需要注意的是，即便是使用了哨兵(關于哨兵后面會有文章介紹)進行自動的主從切換，也有可能在哨兵輪詢到master之前，便被自動拉起機制重啟了。因此，應盡量避免“自動拉起機制”和“不做持久化”同時出現(xiàn)。

（4）異地災備：上述討論的幾種持久化策略，針對的都是一般的系統(tǒng)故障，如進程異常退出、宕機、斷電等，這些故障不會損壞硬盤。但是對于一些可能導致硬盤損壞的災難情況，如火災地震，就需要進行異地災備。例如對于單機的情形，可以定時將RDB文件或重寫后的AOF文件，通過scp拷貝到遠程機器，如阿里云、AWS等；對于主從的情形，可以定時在master上執(zhí)行bgsave，然后將RDB文件拷貝到遠程機器，或者在slave上執(zhí)行bgrewriteaof重寫AOF文件后，將AOF文件拷貝到遠程機器上。一般來說，由于RDB文件文件小、恢復快，因此災難恢復常用RDB文件；異地備份的頻率根據(jù)數(shù)據(jù)安全性的需要及其他條件來確定，但最好不要低于一天一次。

3. fork阻塞：CPU的阻塞

在Redis的實踐中，眾多因素限制了Redis單機的內(nèi)存不能過大，例如：

• 當面對請求的暴增，需要從庫擴容時，Redis內(nèi)存過大會導致擴容時間太長；
• 當主機宕機時，切換主機后需要掛載從庫，Redis內(nèi)存過大導致掛載速度過慢；
• 以及持久化過程中的fork操作，下面詳細說明。

首先說明一下fork操作：

父進程通過fork操作可以創(chuàng)建子進程；子進程創(chuàng)建后，父子進程共享代碼段，不共享進程的數(shù)據(jù)空間，但是子進程會獲得父進程的數(shù)據(jù)空間的副本。在操作系統(tǒng)fork的實際實現(xiàn)中，基本都采用了寫時復制技術，即在父/子進程試圖修改數(shù)據(jù)空間之前，父子進程實際上共享數(shù)據(jù)空間；但是當父/子進程的任何一個試圖修改數(shù)據(jù)空間時，操作系統(tǒng)會為修改的那一部分(內(nèi)存的一頁)制作一個副本。

雖然fork時，子進程不會復制父進程的數(shù)據(jù)空間，但是會復制內(nèi)存頁表（頁表相當于內(nèi)存的索引、目錄）；父進程的數(shù)據(jù)空間越大，內(nèi)存頁表越大，fork時復制耗時也會越多。

在Redis中，無論是RDB持久化的bgsave，還是AOF重寫的bgrewriteaof，都需要fork出子進程來進行操作。如果Redis內(nèi)存過大，會導致fork操作時復制內(nèi)存頁表耗時過多；而Redis主進程在進行fork時，是完全阻塞的，也就意味著無法響應客戶端的請求，會造成請求延遲過大。

對于不同的硬件、不同的操作系統(tǒng)，fork操作的耗時會有所差別，一般來說，如果Redis單機內(nèi)存達到了10GB，fork時耗時可能會達到百毫秒級別（如果使用Xen虛擬機，這個耗時可能達到秒級別）。因此，一般來說Redis單機內(nèi)存一般要限制在10GB以內(nèi)；不過這個數(shù)據(jù)并不是絕對的，可以通過觀察線上環(huán)境fork的耗時來進行調(diào)整。觀察的方法如下：執(zhí)行命令info stats，查看latest_fork_usec的值，單位為微秒。

為了減輕fork操作帶來的阻塞問題，除了控制Redis單機內(nèi)存的大小以外，還可以適度放寬AOF重寫的觸發(fā)條件、選用物理機或高效支持fork操作的虛擬化技術等，例如使用Vmware或KVM虛擬機，不要使用Xen虛擬機。

4. AOF追加阻塞：硬盤的阻塞

前面提到過，在AOF中，如果AOF緩沖區(qū)的文件同步策略為everysec，則：在主線程中，命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后主線程返回；fsync同步文件操作由專門的文件同步線程每秒調(diào)用一次。

這種做法的問題在于，如果硬盤負載過高，那么fsync操作可能會超過1s；如果Redis主線程持續(xù)高速向aof_buf寫入命令，硬盤的負載可能會越來越大，IO資源消耗更快；如果此時Redis進程異常退出，丟失的數(shù)據(jù)也會越來越多，可能遠超過1s。

為此，Redis的處理策略是這樣的：主線程每次進行AOF會對比上次fsync成功的時間；如果距上次不到2s，主線程直接返回；如果超過2s，則主線程阻塞直到fsync同步完成。因此，如果系統(tǒng)硬盤負載過大導致fsync速度太慢，會導致Redis主線程的阻塞；此外，使用everysec配置，AOF最多可能丟失2s的數(shù)據(jù)，而不是1s。

AOF追加阻塞問題定位的方法：

（1）監(jiān)控info Persistence中的aof_delayed_fsync：當AOF追加阻塞發(fā)生時（即主線程等待fsync而阻塞），該指標累加。

（2）AOF阻塞時的Redis日志：

Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

（3）如果AOF追加阻塞頻繁發(fā)生，說明系統(tǒng)的硬盤負載太大；可以考慮更換IO速度更快的硬盤，或者通過IO監(jiān)控分析工具對系統(tǒng)的IO負載進行分析，如iostat（系統(tǒng)級io）、iotop（io版的top）、pidstat等。

5. info命令與持久化

前面提到了一些通過info命令查看持久化相關狀態(tài)的方法，下面來總結一下。

（1）info Persistence

執(zhí)行結果如下：

image

其中比較重要的包括：

• rdb_last_bgsave_status:上次bgsave 執(zhí)行結果，可以用于發(fā)現(xiàn)bgsave錯誤
• rdb_last_bgsave_time_sec:上次bgsave執(zhí)行時間（單位是s），可以用于發(fā)現(xiàn)bgsave是否耗時過長
• aof_enabled:AOF是否開啟
• aof_last_rewrite_time_sec: 上次文件重寫執(zhí)行時間（單位是s），可以用于發(fā)現(xiàn)文件重寫是否耗時過長
• aof_last_bgrewrite_status: 上次bgrewrite執(zhí)行結果，可以用于發(fā)現(xiàn)bgrewrite錯誤
• aof_buffer_length和aof_rewrite_buffer_length:aof緩存區(qū)大小和aof重寫緩沖區(qū)大小
• aof_delayed_fsync:AOF追加阻塞情況的統(tǒng)計

（2）info stats

其中與持久化關系較大的是：latest_fork_usec，代表上次fork耗時，可以參見前面的討論。

六、總結

本文主要內(nèi)容可以總結如下：

1、持久化在Redis高可用中的作用：數(shù)據(jù)備份，與主從復制相比強調(diào)的是由內(nèi)存到硬盤的備份。
2、RDB持久化：將數(shù)據(jù)快照備份到硬盤；介紹了其觸發(fā)條件（包括手動出發(fā)和自動觸發(fā)）、執(zhí)行流程、RDB文件等，特別需要注意的是文件保存操作由fork出的子進程來進行。如果覺得本文有用，可以加我的群：619881427 學習更多的Java架構技術知識，包括分布式架構，微服務架構，性能優(yōu)化，源碼分析等，已經(jīng)有小伙伴錄制好視頻免費分享給新加入進來的朋友。
3、AOF持久化：將執(zhí)行的寫命令備份到硬盤（類似于MySQL的binlog），介紹了其開啟方法、執(zhí)行流程等，特別需要注意的是文件同步策略的選擇（everysec）、文件重寫的流程。
4、一些現(xiàn)實的問題：包括如何選擇持久化策略，以及需要注意的fork阻塞、AOF追加阻塞等。