本篇文章帶大家聊聊redis中的高可用與持久化，看看redis 持久化的功能、兩種方式（rdb和aof），希望對大家有所幫助！

一文詳解redis中的高可用與持久化

一、Redis 高可用

1. Redis 高可用概述

??在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時(shí)間，衡量的標(biāo)準(zhǔn)是在多長時(shí)間內(nèi)可以提供正常服務(wù)（99.9%、99.99%、99.999%等等）。【相關(guān)推薦：Redis視頻教程】

??但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)（如主從分離、快速容災(zāi)技術(shù)），還需要考慮數(shù)據(jù)容量的擴(kuò)展、數(shù)據(jù)安全不會丟失等。

2. Redis 高可用策略

在Redis中，實(shí)現(xiàn)高可用的技術(shù)主要包括持久化、主從分離、哨兵和集群。

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

二、Redis 持久化

1. Redis 持久化的功能

??Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲在內(nèi)存中，為了避免服務(wù)器斷電等原因?qū)е翿edis進(jìn)程異常退出后數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式（數(shù)據(jù)或命令）從內(nèi)存保存到硬盤；當(dāng)下次Redis重啟時(shí)，利用持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進(jìn)行災(zāi)難備份，可以將持久化文件拷貝到一個遠(yuǎn)程位置。

2. Redis 持久化的兩種方式

RDB持久化
原理是將Redis在內(nèi)存中的數(shù)據(jù)庫記錄定時(shí)保存到磁盤上。
AOF持久化（append only file）
原理是將Redis的操作日志以追加的方式寫入文件，類似于mysql的binlog。
由于AOF持久化的實(shí)時(shí)性更好，即當(dāng)進(jìn)程意外退出時(shí)丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。

3. RDB 持久化

??RDB持久化是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中當(dāng)前進(jìn)程中的數(shù)據(jù)生成快照保存到硬盤（因此也稱為快照持久化），用二進(jìn)制壓縮存儲，保存的文件后綴是rdb；當(dāng)Redis重新啟動時(shí)，可以讀取快照文件恢復(fù)數(shù)據(jù)。

3.1 觸發(fā)條件

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

3.1.1 手動觸發(fā)

save命令和bgsave命令都可以生成RDB文件。
save命令會阻塞Redis服務(wù)器進(jìn)程，直到RDB文件創(chuàng)建完畢為止，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請求。
bgsave命令會fork()一個子進(jìn)程，由子進(jìn)程來負(fù)責(zé)創(chuàng)建RDB文件，父進(jìn)程（即Redis主進(jìn)程）則繼續(xù)處理請求。
bgsave命令執(zhí)行過程中，只有fork子進(jìn)程時(shí)會阻塞服務(wù)器，而對于save命令，整個過程都會阻塞服務(wù)器，因此save已基本被廢棄，線上環(huán)境要杜絕save的使用。

3.1.2 自動觸發(fā)

在自動觸發(fā)RDB持久化時(shí)，Redis也會選擇bgsave而不是save來進(jìn)行持久化。

3.2 配置方式

通過修改配置文件進(jìn)行設(shè)定：save m n
自動觸發(fā)最常見的情況是在配置文件中通過save m n，指定當(dāng)m秒內(nèi)發(fā)生n次變化時(shí)，會觸發(fā)bgsave。

[root@localhost ~]# vim /etc/redis/6379.conf ##219行，以下三個save條件滿足任意一個時(shí)，都會引起bgsave的調(diào)用save 900 1	##當(dāng)時(shí)間到900秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsavesave 300 10	##當(dāng)時(shí)間到300秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsavesave 60 10000	##當(dāng)時(shí)間到60秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10000次變化，則執(zhí)行bgsave##254行，指定RDB文件名dbfilename dump.rdb##264行，指定RDB文件和AOF文件所在目錄dir /var/lib/redis/6379##242行，是否開啟RDB文件壓縮rdbcompression yes

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

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

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

3.4 執(zhí)行流程

一文詳解redis中的高可用與持久化

Redis父進(jìn)程首先判斷：當(dāng)前是否在執(zhí)行save，或bgsave/bgrewriteaof的子進(jìn)程，如果在執(zhí)行則bgsave命令直接返回。bgsave/bgrewriteaof的子進(jìn)程不能同時(shí)執(zhí)行，主要是基于性能方面的考慮；兩個并發(fā)的子進(jìn)程同時(shí)執(zhí)行大量的磁盤寫操作，可能引起嚴(yán)重的性能問題。
父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個過程中父進(jìn)程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令。
父進(jìn)程fork后，bgsave命令返回“background saving started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令
子進(jìn)程創(chuàng)建RDB文件，根據(jù)父進(jìn)程內(nèi)存快照生成臨時(shí)快照文件，完成后對原有文件進(jìn)行原子替換
子進(jìn)程發(fā)送信號給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計(jì)信息

3.5 啟動時(shí)加載

??RDB文件的載入工作是在服務(wù)器啟動時(shí)自動執(zhí)行的，并沒有專門的命令。但是由于AOF的優(yōu)先級更高，因此當(dāng)AOF開啟時(shí)，Redis會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時(shí)，才會在Redis服務(wù)器啟動時(shí)檢測RDB文件，并自動載入。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。
??Redis載入RDB文件時(shí)，會對RDB文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。

4. AOF 持久化

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

4.1 開啟 AOF

Redis服務(wù)器默認(rèn)開啟RDB，關(guān)閉AOF；要開啟AOF，需要在配置文件中配置

[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，開啟AOFappendonly yes##704行，指定AOF文件名稱appendfilename "appendonly.aof"##796行，是否忽略最后一條可能存在問題的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ... Redis stopped Starting Redis server...

4.2 執(zhí)行流程

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

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

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

4.2.1 命令追加（append）

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

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

4.2.2 文件寫入（write）和文件同步（sync）

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

4.2.3 三種同步方式

AOF緩存區(qū)的同步文件策略存在三種同步方式，通過對/etc/redis/6379.conf的729行的修改進(jìn)行配置。

4.2.3.1 appendfsync always

命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴(yán)重降低了Redis的性能；即便是使用固態(tài)硬盤（SSD），每秒大約也就只能處理幾萬個命令，而且會大大降低SSD的壽命。

4.2.3.2 appendfsync no

命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對AOF文件做fsync同步；同步由操作系統(tǒng)負(fù)載，通常同步周期為30秒。這種情況下，文件同步的時(shí)間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會很多，數(shù)據(jù)安全性無法保證。

4.2.3.3 appendfsync everysec（推薦）

命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線程返回：fsync同步文件操作由專門的線程每秒調(diào)用一次。everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，一次是Redis的默認(rèn)配置，也是我們推薦的配置。

4.2.4 文件重寫（rewrite）

隨著時(shí)間流逝，Redis服務(wù)器執(zhí)行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務(wù)器的正常運(yùn)行，也會導(dǎo)致數(shù)據(jù)恢復(fù)需要的時(shí)間過長。
文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF重寫是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令，同步到新的AOF文件；不會對舊的AOF文件進(jìn)行任何讀取、寫入操作。
關(guān)于文件重寫需要注意的另一點(diǎn)是：對于AOF持久化來說，文件重寫雖然是強(qiáng)烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動的時(shí)候?qū)耄灰虼嗽谝恍┈F(xiàn)實(shí)中，會關(guān)閉自動的文件重寫，然后定時(shí)任務(wù)在每天的某一時(shí)刻定時(shí)執(zhí)行。

4.2.4.1 具有壓縮功能的原因

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

過期的數(shù)據(jù)不再寫入文件。
無效的命令不再寫入文件：如有些數(shù)據(jù)被重復(fù)設(shè)置（set mykey v1,set mykey v2）、有些數(shù)據(jù)被刪除了（set myset v1,del myset）等。
多條命令可以合并為一個：如sadd myset v1,sadd myset v2,sadd myset v3可以合并為sadd myset v1 v2 v3。

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

4.2.4.2 文件重寫的觸發(fā)

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

手動觸發(fā)：直接調(diào)用bfrewriteaof命令，該命令的執(zhí)行與bgsave有些類似，都是fork進(jìn)程進(jìn)行具體的工作，且都只有在fork時(shí)阻塞。
自動觸發(fā)：通過設(shè)置auto-aof-rewrite-min-size選項(xiàng)和auto-aof-rewrite-percentage選項(xiàng)來自動執(zhí)行bgrewriteaof。只有當(dāng)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項(xiàng)同時(shí)滿足時(shí)，才會自動觸發(fā)AOF重寫，即bgrewriteaof操作。

自動觸發(fā)的配置位于/etc/redis/6379.conf的771行和772行

auto-aof-rewrite-percentage 100
當(dāng)前AOF文件大小（即aof_current_size）是上次日志重寫時(shí)AOF文件大小（aof_base_size）兩倍時(shí)，發(fā)生bgrewriteaof操作
auto-aof-rewrite-min-size 64mb
當(dāng)前AOF文件執(zhí)行bgrewriteaof命令的最小值，避免剛開始啟動Redis時(shí)由于文件尺寸較小導(dǎo)致頻繁的bgrewriteaof

4.2.4.3 文件重寫的流程

一文詳解redis中的高可用與持久化
文件重寫的流程如下：

Redis父進(jìn)程首先平判斷當(dāng)前是否存在正在執(zhí)行bgsave/bgrewriteaof的子進(jìn)程；如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。
父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個過程中父進(jìn)程是阻塞的。
父進(jìn)程fork后，bgrewriteaof命令返回“Background append only file rewrite started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機(jī)制的正確。
由于fork操作使用寫時(shí)復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時(shí)的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然在響應(yīng)命令，因此Redis使用AOF重寫緩沖區(qū)（aof_rewrite_buf）保存這部分?jǐn)?shù)據(jù)，防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。也就是說，bgrewriteaof執(zhí)行期間，Redis的寫命令同時(shí)追加到aof_buf和aof_rewrite_buf兩個緩沖區(qū)。
子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。
子進(jìn)程寫完新的AOF文件后，向父進(jìn)程發(fā)信號，父進(jìn)程更新統(tǒng)計(jì)信息，具體可以通過info persistence查看。
父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務(wù)器當(dāng)前狀態(tài)一致。
使用新的AOF文件替換老文件，文成AOF重寫。

關(guān)于文件重寫的流程，有兩點(diǎn)需要特別注意：

重寫由父進(jìn)程fork子進(jìn)程進(jìn)行
重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入例如aof_rewrite_buf緩存

4.3 啟動時(shí)加載

當(dāng)AOF開啟時(shí)，Redis啟動時(shí)會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時(shí)，才會載入RDB文件恢復(fù)數(shù)據(jù)。
當(dāng)AOF開啟，但AOF文件不存在時(shí)，即使RDB文件存在也不會加載。
Redis載入AOF文件時(shí)，會對AOF文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。但如果是AOF文件結(jié)尾不完整（機(jī)器突然宕機(jī)等容易導(dǎo)致文件尾部不完整），且aof_load_truncated參數(shù)開啟，則日志中會輸出警告，Redis忽略掉AOF文件的尾部，啟動成功。aof_load_truncated參數(shù)默認(rèn)是開啟的。

5. RDB 和 AOF 的優(yōu)缺點(diǎn)

RDB持久化

優(yōu)點(diǎn)：RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；恢復(fù)速度比AOF快很多。當(dāng)然，與AOF相比，RDB最重要的優(yōu)點(diǎn)之一是對性能的影響相對較小。
缺點(diǎn)：RDB文件的知名缺點(diǎn)在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實(shí)時(shí)持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時(shí)候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
對于RDB持久化，一方面是bgsave在進(jìn)行fork操作時(shí)Redis主進(jìn)程會阻塞，另一方面，子進(jìn)程向硬盤寫數(shù)據(jù)也會帶來IO壓力。