Redis高可用詳解：持久化技術及方案選擇

時間 2019-12-09

標籤 redis 可用詳解持久技術方案選擇欄目 Redis 简体版

原文原文鏈接

Redis高可用詳解：持久化技術及方案選擇

0.3 2018.08.23 22:55 字數 9774 閱讀 542評論 0喜歡 9

前言html

本文將先說明上述幾種技術分別解決了Redis高可用的什麼問題，而後詳細介紹Redis的持久化技術，主要是RDB和AOF兩種持久化方案。在介紹RDB和AOF方案時，不只介紹其做用及操做方法，同時還會介紹持久化實現的一些原理細節及須要注意的問題。最後，介紹在實際使用中持久化方案的選擇以及常常遇到的問題等內容。ios

1、Redis高可用概述redis

在介紹Redis高可用以前，首先要說明一下在Redis的語境中高可用的含義。算法

咱們知道，在Web服務器中，高可用是指服務器能夠正常訪問的時間，衡量的標準是在多長時間內能夠提供正常服務（99.9%、99.99%、99.999%等等）。可是在Redis語境中，高可用的含義彷佛要寬泛一些，除了保證提供正常服務（如主從分離、快速容災技術等），還須要考慮數據容量的擴展、數據安全不會丟失等。數據庫

在Redis中，實現高可用的技術主要包括持久化、複製、哨兵和集羣，下面分別說明它們的做用，以及解決了什麼樣的問題：緩存

持久化：持久化是最簡單的高可用方法，有時甚至不被歸爲高可用的手段，主要做用是數據備份，即將數據存儲在硬盤，保證數據不會因進程退出而丟失。安全

複製：複製是高可用Redis的基礎，哨兵和集羣都是在複製基礎上實現高可用的。複製主要實現了數據的多機備份以及對於讀操做的負載均衡和簡單的故障恢復。缺陷是故障恢復沒法自動化、寫操做沒法負載均衡、存儲能力受到單機的限制。服務器

哨兵：在複製的基礎上，哨兵實現了自動化的故障恢復。缺陷是寫操做沒法負載均衡、存儲能力受到單機的限制。網絡

集羣：經過集羣，Redis解決了寫操做沒法負載均衡以及存儲能力受到單機限制的問題，實現了較爲完善的高可用方案。架構

2、Redis持久化概述

持久化的功能：Redis是內存數據庫，數據都是存儲在內存中，爲了不進程退出致使數據的永久丟失，須要按期將Redis中的數據以某種形式（數據或命令）從內存保存到硬盤。當下次Redis重啓時，利用持久化文件實現數據恢復。除此以外，爲了進行災難備份，能夠將持久化文件拷貝到一個遠程位置。

Redis持久化分爲RDB持久化和AOF持久化，前者將當前數據保存到硬盤，後者則是將每次執行的寫命令保存到硬盤（相似於MySQL的Binlog）。因爲AOF持久化的實時性更好，即當進程意外退出時丟失的數據更少，所以AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。

下面依次介紹RDB持久化和AOF持久化。因爲Redis各個版本之間存在差別，如無特殊說明，以Redis 3.0爲準。

3、RDB持久化

RDB持久化是將當前進程中的數據生成快照保存到硬盤（所以也稱做快照持久化），保存的文件後綴是rdb；當Redis從新啓動時，能夠讀取快照文件恢復數據。

一、觸發條件

RDB持久化的觸發分爲手動觸發和自動觸發兩種。

1）手動觸發

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

save命令會阻塞Redis服務器進程，直到RDB文件建立完畢爲止，在Redis服務器阻塞期間，服務器不能處理任何命令請求。

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

此時服務器執行日誌以下：

bgsave命令執行過程當中，只有fork子進程時會阻塞服務器，而對於save命令，整個過程都會阻塞服務器，所以save已基本被廢棄，線上環境要杜絕save的使用，後文中也將只介紹bgsave命令。此外，在自動觸發RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化。下面介紹自動觸發RDB持久化的條件。

2）自動觸發

save m n

自動觸發最多見的狀況是在配置文件中經過save m n，指定當m秒內發生n次變化時，會觸發bgsave。

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

其中save 900 1的含義是：當時間到900秒時，若是Redis數據發生了至少1次變化，則執行bgsave；save 300 10和save 60 10000同理。當三個save條件知足任意一個時，都會引發bgsave的調用。

save m n的實現原理

Redis的save m n，是經過serverCron函數、dirty計數器、和lastsave時間戳來實現的。

serverCron是Redis服務器的週期性操做函數，默認每隔100ms執行一次；該函數對服務器的狀態進行維護，其中一項工做就是檢查 save m n 配置的條件是否知足，若是知足就執行bgsave。

dirty計數器是Redis服務器維持的一個狀態，記錄了上一次執行bgsave/save命令後，服務器狀態進行了多少次修改(包括增刪改)；而當save/bgsave執行完成後，會將dirty從新置爲0。

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

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

save m n的原理以下：每隔100ms，執行serverCron函數；在serverCron函數中，遍歷save m n配置的保存條件，只要有一個條件知足，就進行bgsave。對於每個save m n條件，只有下面兩條同時知足時纔算知足：

當前時間-lastsave > m

dirty >= n

save m n 執行日誌

下圖是save m n觸發bgsave執行時，服務器打印日誌的狀況：

其餘自動觸發機制

除了save m n之外，還有一些其餘狀況會觸發bgsave：

在主從複製場景下，若是從節點執行全量複製操做，則主節點會執行bgsave命令，並將rdb文件發送給從節點；

執行shutdown命令時，自動執行rdb持久化，以下圖所示：

二、執行流程

前面介紹了觸發bgsave的條件，下面將說明bgsave命令的執行流程，以下圖所示：

圖片中的5個步驟所進行的操做以下：

Redis父進程首先判斷：當前是否在執行save，或bgsave/bgrewriteaof（後面會詳細介紹該命令）的子進程，若是在執行則bgsave命令直接返回。bgsave/bgrewriteaof 的子進程不能同時執行，主要是基於性能方面的考慮：兩個併發的子進程同時執行大量的磁盤寫操做，可能引發嚴重的性能問題。

父進程執行fork操做建立子進程，這個過程當中父進程是阻塞的，Redis不能執行來自客戶端的任何命令；

父進程fork後，bgsave命令返回」Background saving started」信息並再也不阻塞父進程，並能夠響應其餘命令；

子進程建立RDB文件，根據父進程內存快照生成臨時快照文件，完成後對原有文件進行原子替換；

子進程發送信號給父進程表示完成，父進程更新統計信息。

三、RDB文件

RDB文件是通過壓縮的二進制文件，下面介紹關於RDB文件的一些細節。

存儲路徑

RDB文件的存儲路徑既能夠在啓動前配置，也能夠經過命令動態設定。

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

動態設定：Redis啓動後也能夠動態修改RDB存儲路徑，在磁盤損害或空間不足時很是有用；執行命令爲config set dir {newdir}和config set dbfilename {newFileName}。以下所示(Windows環境)：

RDB文件格式

RDB文件格式以下圖所示（圖片來源：《Redis設計與實現》）：

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

REDIS：常量，保存着「REDIS」5個字符。

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

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

EOF：常量，標誌RDB文件正文內容結束。

check_sum：前面全部內容的校驗和；Redis在載入RBD文件時，會計算前面的校驗和並與check_sum值比較，判斷文件是否損壞。

壓縮

Redis默認採用LZF算法對RDB文件進行壓縮。雖然壓縮耗時，可是能夠大大減少RDB文件的體積，所以壓縮默認開啓；能夠經過命令關閉：

須要注意的是，RDB文件的壓縮並非針對整個文件進行的，而是對數據庫中的字符串進行的，且只有在字符串達到必定長度(20字節)時纔會進行。

四、啓動時加載

RDB文件的載入工做是在服務器啓動時自動執行的，並無專門的命令。可是因爲AOF的優先級更高，所以當AOF開啓時，Redis會優先載入AOF文件來恢復數據；只有當AOF關閉時，纔會在Redis服務器啓動時檢測RDB文件，並自動載入。服務器載入RDB文件期間處於阻塞狀態，直到載入完成爲止。

Redis啓動日誌中能夠看到自動載入的執行：

Redis載入RDB文件時，會對RDB文件進行校驗，若是文件損壞，則日誌中會打印錯誤，Redis啓動失敗。

五、RDB經常使用配置總結

下面是RDB經常使用的配置項，以及默認值（前面介紹過的這裏再也不詳細介紹）：

save m n：bgsave自動觸發的條件；若是沒有save m n配置，至關於自動的RDB持久化關閉，不過此時仍能夠經過其餘方式觸發。

stop-writes-on-bgsave-error yes：當bgsave出現錯誤時，Redis是否中止執行寫命令；設置爲yes，則當硬盤出現問題時，能夠及時發現，避免數據的大量丟失；設置爲no，則Redis無視bgsave的錯誤繼續執行寫命令，當對Redis服務器的系統(尤爲是硬盤)使用了監控時，該選項考慮設置爲no。

rdbcompression yes：是否開啓RDB文件壓縮。

rdbchecksum yes：是否開啓RDB文件的校驗，在寫入文件和讀取文件時都起做用；關閉checksum在寫入文件和啓動文件時大約能帶來10%的性能提高，可是數據損壞時沒法發現。

dbfilename dump.rdb：RDB文件名。

dir ./：RDB文件和AOF文件所在目錄。

4、AOF持久化

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

與RDB相比，AOF的實時性更好，所以已成爲主流的持久化方案。

一、開啓AOF

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

appendonly yes

二、執行流程

因爲須要記錄Redis的每條寫命令，所以AOF不須要觸發，下面介紹AOF的執行流程。

AOF的執行流程包括：

命令追加(append)：將Redis的寫命令追加到緩衝區aof_buf；

文件寫入(write)和文件同步(sync)：根據不一樣的同步策略將aof_buf中的內容同步到硬盤；

文件重寫(rewrite)：按期重寫AOF文件，達到壓縮的目的。

1) 命令追加(append)

Redis先將寫命令追加到緩衝區，而不是直接寫入文件，主要是爲了不每次有寫命令都直接寫入硬盤，致使硬盤IO成爲Redis負載的瓶頸。

命令追加的格式是Redis命令請求的協議格式，它是一種純文本格式，具備兼容性好、可讀性強、容易處理、操做簡單避免二次開銷等優勢；具體格式略。在AOF文件中，除了用於指定數據庫的select命令（如select 0 爲選中0號數據庫）是由Redis添加的，其餘都是客戶端發送來的寫命令。

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

Redis提供了多種AOF緩存區的同步文件策略，策略涉及到操做系統的write函數和fsync函數，說明以下：

爲了提升文件寫入效率，在現代操做系統中，當用戶調用write函數將數據寫入文件時，操做系統一般會將數據暫存到一個內存緩衝區裏，當緩衝區被填滿或超過了指定時限後，才真正將緩衝區的數據寫入到硬盤裏。這樣的操做雖然提升了效率，但也帶來了安全問題：若是計算機停機，內存緩衝區中的數據會丟失；所以系統同時提供了fsync、fdatasync等同步函數，能夠強制操做系統馬上將緩衝區中的數據寫入到硬盤裏，從而確保數據的安全性。

AOF緩存區的同步文件策略由參數appendfsync控制，各個值的含義以下：

always：命令寫入aof_buf後當即調用系統fsync操做同步到AOF文件，fsync完成後線程返回。這種狀況下，每次有寫命令都要同步到AOF文件，硬盤IO成爲性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴重下降了Redis的性能；即使是使用固態硬盤（SSD），每秒大約也只能處理幾萬個命令，並且會大大下降SSD的壽命。

no：命令寫入aof_buf後調用系統write操做，不對AOF文件作fsync同步；同步由操做系統負責，一般同步週期爲30秒。這種狀況下，文件同步的時間不可控，且緩衝區中堆積的數據會不少，數據安全性沒法保證。

everysec：命令寫入aof_buf後調用系統write操做，write完成後線程返回；fsync同步文件操做由專門的線程每秒調用一次。everysec是前述兩種策略的折中，是性能和數據安全性的平衡，所以是Redis的默認配置，也是咱們推薦的配置。

3) 文件重寫(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。不過爲了防止單條命令過大形成客戶端緩衝區溢出，對於list、set、hash、zset類型的key，並不必定只使用一條命令；而是以某個常量爲界將命令拆分爲多條。這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。

經過上述內容能夠看出，因爲重寫後AOF執行的命令減小了，文件重寫既能夠減小文件佔用的空間，也能夠加快恢復速度。

文件重寫的觸發

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

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

此時服務器執行日誌以下：

自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數，以及aof_current_size和aof_base_size狀態肯定觸發時機。

auto-aof-rewrite-min-size：執行AOF重寫時，文件的最小體積，默認值爲64MB。

auto-aof-rewrite-percentage：執行AOF重寫時，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。

其中，參數能夠經過config get命令查看：

狀態能夠經過info persistence查看：

只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個參數同時知足時，纔會自動觸發AOF重寫，即bgrewriteaof操做。

自動觸發bgrewriteaof時，能夠看到服務器日誌以下：

文件重寫的流程

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

圖片來源：http://www.cnblogs.com/yangmingxianshen/p/8373205.html

關於文件重寫的流程，有兩點須要特別注意：

重寫由父進程fork子進程進行；

重寫期間Redis執行的寫命令，須要追加到新的AOF文件中，爲此Redis引入了aof_rewrite_buf緩存。

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

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重寫。

三、啓動時加載

前面提到過，當AOF開啓時，Redis啓動時會優先載入AOF文件來恢復數據；只有當AOF關閉時，纔會載入RDB文件恢復數據。

當AOF開啓，且AOF文件存在時，Redis啓動日誌：

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

文件校驗

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

僞客戶端

由於Redis的命令只能在客戶端上下文中執行，而載入AOF文件時命令是直接從文件中讀取的，並非由客戶端發送；所以Redis服務器在載入AOF文件以前，會建立一個沒有網絡鏈接的客戶端，以後用它來執行AOF文件中的命令，命令執行的效果與帶網絡鏈接的客戶端徹底同樣。

四、AOF經常使用配置總結

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

appendonly no：是否開啓AOF

appendfilename "appendonly.aof"：AOF文件名

dir ./：RDB文件和AOF文件所在目錄

appendfsync everysec：fsync持久化策略

no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；若是開啓該選項，能夠減輕文件重寫時CPU和硬盤的負載（尤爲是硬盤），可是可能會丟失AOF重寫期間的數據；須要在負載和安全性之間進行平衡

auto-aof-rewrite-percentage 100：文件重寫觸發條件之一

auto-aof-rewrite-min-size 64mb：文件重寫觸發提交之一

aof-load-truncated yes：若是AOF文件結尾損壞，Redis啓動時是否仍載入AOF文件

5、方案選擇與常見問題

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

一、RDB和AOF的優缺點

RDB和AOF各有優缺點：

RDB持久化

優勢：RDB文件緊湊，體積小，網絡傳輸快，適合全量複製；恢復速度比AOF快不少。固然，與AOF相比，RDB最重要的優勢之一是對性能的影響相對較小。

缺點：RDB文件的致命缺點在於其數據快照的持久化方式決定了必然作不到實時持久化，而在數據愈來愈重要的今天，數據的大量丟失不少時候是沒法接受的，所以AOF持久化成爲主流。此外，RDB文件須要知足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

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

二、持久化策略選擇

在介紹持久化策略以前，首先要明白不管是RDB仍是AOF，持久化的開啓都是要付出性能方面代價的：對於RDB持久化，一方面是bgsave在進行fork操做時Redis主進程會阻塞，另外一方面，子進程向硬盤寫數據也會帶來IO壓力；對於AOF持久化，向硬盤寫數據的頻率大大提升(everysec策略下爲秒級)，IO壓力更大，甚至可能形成AOF追加阻塞問題（後面會詳細介紹這種阻塞），此外，AOF文件的重寫與RDB的bgsave相似，會有fork時的阻塞和子進程的IO壓力問題。相對來講，因爲AOF向硬盤中寫數據的頻率更高，所以對Redis主進程性能的影響會更大。

在實際生產環境中，根據數據量、應用對數據的安全要求、預算限制等不一樣狀況，會有各類各樣的持久化策略；如徹底不使用任何持久化、使用RDB或AOF的一種，或同時開啓RDB和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一塊兒考慮，由於主從複製與持久化一樣具備數據備份的功能，並且主機master和從機slave能夠獨立的選擇持久化方案。

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

1）若是Redis中的數據徹底丟棄也沒有關係（如Redis徹底用做DB層數據的cache），那麼不管是單機，仍是主從架構，均可以不進行任何持久化。

2）在單機環境下（對於我的開發者，這種狀況可能比較常見），若是能夠接受十幾分鍾或更多的數據丟失，選擇RDB對Redis的性能更加有利；若是隻能接受秒級別的數據丟失，應該選擇AOF。

3）但在多數狀況下，咱們都會配置主從環境，slave的存在既能夠實現數據的熱備，也能夠進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務。

在這種狀況下，一種可行的作法是：

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

slave：關閉RDB，開啓AOF（若是對數據安全要求不高，開啓RDB關閉AOF也能夠），並定時對持久化文件進行備份（如備份到其餘文件夾，並標記好備份的時間）；而後關閉AOF的自動重寫，而後添加定時任務，在天天Redis閒時（如凌晨12點）調用bgrewriteaof。

這裏須要解釋一下，爲何開啓了主從複製，能夠實現數據的熱備份，還須要設置持久化呢？由於在一些特殊狀況下，主從複製仍然不足以保證數據的安全，例如：

master和slave進程同時中止：考慮這樣一種場景，若是master和slave在同一棟大樓或同一個機房，則一次停電事故就可能致使master和slave機器同時關機，Redis進程中止；若是沒有持久化，則面臨的是數據的徹底丟失。

master誤重啓：考慮這樣一種場景，master服務由於故障宕掉了，若是系統中有自動拉起機制（即檢測到服務中止後重啓該服務）將master自動重啓，因爲沒有持久化文件，那麼master重啓後數據是空的，slave同步數據也變成了空的；若是master和slave都沒有持久化，一樣會面臨數據的徹底丟失。須要注意的是，即使是使用了哨兵（關於哨兵後面會有文章介紹）進行自動的主從切換，也有可能在哨兵輪詢到master以前，便被自動拉起機制重啓了。所以，應儘可能避免「自動拉起機制」和「不作持久化」同時出現。

4）異地災備：上述討論的幾種持久化策略，針對的都是通常的系統故障，如進程異常退出、宕機、斷電等，這些故障不會損壞硬盤。可是對於一些可能致使硬盤損壞的災難狀況，如火災地震，就須要進行異地災備。

例如對於單機的情形，能夠定時將RDB文件或重寫後的AOF文件，經過scp拷貝到遠程機器，如阿里雲、AWS等；對於主從的情形，能夠定時在master上執行bgsave，而後將RDB文件拷貝到遠程機器，或者在slave上執行bgrewriteaof重寫AOF文件後，將AOF文件拷貝到遠程機器上。

通常來講，因爲RDB文件文件小、恢復快，所以災難恢復經常使用RDB文件；異地備份的頻率根據數據安全性的須要及其它條件來肯定，但最好不要低於一天一次。

三、fork阻塞：CPU的阻塞

在Redis的實踐中，衆多因素限制了Redis單機的內存不能過大，例如：

當面對請求的暴增，須要從庫擴容時，Redis內存過大會致使擴容時間太長；

當主機宕機時，切換主機後須要掛載從庫，Redis內存過大致使掛載速度過慢；

以及持久化過程當中的fork操做，下面詳細說明。

首先說明一下fork操做：

父進程經過fork操做能夠建立子進程；子進程建立後，父子進程共享代碼段，不共享進程的數據空間，可是子進程會得到父進程的數據空間的副本。在操做系統fork的實際實現中，基本都採用了寫時複製技術，即在父/子進程試圖修改數據空間以前，父子進程實際上共享數據空間；可是當父/子進程的任何一個試圖修改數據空間時，操做系統會爲修改的那一部分(內存的一頁)製做一個副本。

雖然fork時，子進程不會複製父進程的數據空間，可是會複製內存頁表（頁表至關於內存的索引、目錄）；父進程的數據空間越大，內存頁表越大，fork時複製耗時也會越多。

在Redis中，不管是RDB持久化的bgsave，仍是AOF重寫的bgrewriteaof，都須要fork出子進程來進行操做。若是Redis內存過大，會致使fork操做時複製內存頁表耗時過多；而Redis主進程在進行fork時，是徹底阻塞的，也就意味着沒法響應客戶端的請求，會形成請求延遲過大。

對於不一樣的硬件、不一樣的操做系統，fork操做的耗時會有所差異，通常來講，若是Redis單機內存達到了10GB，fork時耗時可能會達到百毫秒級別（若是使用Xen虛擬機，這個耗時可能達到秒級別）。所以，通常來講Redis單機內存通常要限制在10GB之內；不過這個數據並非絕對的，能夠經過觀察線上環境fork的耗時來進行調整。觀察的方法以下：執行命令info stats，查看latest_fork_usec的值，單位爲微秒。

爲了減輕fork操做帶來的阻塞問題，除了控制Redis單機內存的大小之外，還能夠適度放寬AOF重寫的觸發條件、選用物理機或高效支持fork操做的虛擬化技術等，例如使用Vmware或KVM虛擬機，不要使用Xen虛擬機。

四、AOF追加阻塞：硬盤的阻塞

前面提到過，在AOF中，若是AOF緩衝區的文件同步策略爲everysec，則：在主線程中，命令寫入aof_buf後調用系統write操做，write完成後主線程返回；fsync同步文件操做由專門的文件同步線程每秒調用一次。

這種作法的問題在於，若是硬盤負載太高，那麼fsync操做可能會超過1s；若是Redis主線程持續高速向aof_buf寫入命令，硬盤的負載可能會愈來愈大，IO資源消耗更快；若是此時Redis進程異常退出，丟失的數據也會愈來愈多，可能遠超過1s。

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

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

1）監控info Persistence中的aof_delayed_fsync：當AOF追加阻塞發生時（即主線程等待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追加阻塞頻繁發生，說明系統的硬盤負載太大；能夠考慮更換IO速度更快的硬盤，或者經過IO監控分析工具對系統的IO負載進行分析，如iostat（系統級io）、iotop（io版的top）、pidstat等。

五、info命令與持久化

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

1）info Persistence

執行結果以下：