為什么需要持久化

Redis是基于內(nèi)存的NoSQL數(shù)據(jù)庫，讀寫速度自然快，但內(nèi)存是瞬時(shí)的，在redis服務(wù)關(guān)閉或重啟之后，redis存放在內(nèi)存的數(shù)據(jù)就會(huì)丟失，為了解決這個(gè)問題，redis提供了兩種持久化方式，以便在發(fā)生故障后恢復(fù)數(shù)據(jù)。

持久化選項(xiàng)

redis提供了兩種不同的持久化方式來將數(shù)據(jù)存儲(chǔ)到硬盤中。一種是快照方式（也叫RDB方式），它可以將莫一時(shí)刻存在于redis中的所有數(shù)據(jù)存儲(chǔ)到硬盤；另一種叫只追加文件（AOF）方式，它會(huì)定時(shí)的復(fù)制redis執(zhí)行的所有寫命令到硬盤。這兩種持久化方式各有千秋，既可以同時(shí)使用，也可以獨(dú)立使用，在某些情況下甚至可以兩種都不使用。

RDB方式

RDB方式也稱快照方式，通過創(chuàng)建快照來保存某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)副本（.rdb）到硬盤。在重啟服務(wù)器后，redis會(huì)加載這個(gè)rdb文件來還原數(shù)據(jù)。先來看一下rdb持久化配置。
vi redis.conf打開redis的配置文件，找到SNAPSHOTTING部分,發(fā)現(xiàn)如下內(nèi)容：

save 900 1
save 300 10
save 60 10000
……
dbfilename dump.rdb
dir ./

說明

• save seconds changes：表示在seconds秒后，如果有不少與changes個(gè)key發(fā)生改變，則保存一次快照?？梢钥吹?，rdb持久化默認(rèn)是開啟的，并且配置了三個(gè)save選項(xiàng)，如果想要關(guān)閉rdb持久化，將所有的save注釋掉就好了
• dbfilename：rdb文件名
• dir：rdb文件存放路徑

創(chuàng)建快照

BGSAVE：
BGSAVE命令可以用于創(chuàng)建一個(gè)快照，在redis接收到BGSAVE命令后會(huì)fork出一個(gè)子進(jìn)程，子進(jìn)程負(fù)責(zé)將快照寫入硬盤，而父進(jìn)程則繼續(xù)處理命令請(qǐng)求。需要注意的是redis在創(chuàng)建子進(jìn)程時(shí)會(huì)阻塞父進(jìn)程，時(shí)間長短與redis占用的內(nèi)存大小成正比。
除了手動(dòng)的調(diào)用BGSAVE命令外，BGSAVE命令的觸發(fā)條件有如下兩種：

• 用戶配置了save選項(xiàng)，從redis最近一次創(chuàng)建快照開始算起，當(dāng)任意一個(gè)save選項(xiàng)的條件被滿足時(shí)，會(huì)觸發(fā)一次BGSAVE命令。
• 在進(jìn)行主從復(fù)制連接時(shí)，剛連上來的從服務(wù)器會(huì)向主服務(wù)器發(fā)送SYNC命令請(qǐng)求數(shù)據(jù)同步，在主服務(wù)器收到SYNC命令后，會(huì)執(zhí)行一次BGSAVE命令，后將生成的rdb文件發(fā)送給從服務(wù)器進(jìn)行數(shù)據(jù)同步。

SAVE：
SAVE命令同樣可以創(chuàng)建一個(gè)快照，但與BGSAVE命令不同的是SAVE命令不會(huì)創(chuàng)建子進(jìn)程，所以接收到SAVE命令的redis服務(wù)器在快照創(chuàng)建完畢之前不會(huì)響應(yīng)其他任何命令。由于在創(chuàng)建快照的過程中沒有其他進(jìn)程搶奪資源，所以SAVE命令創(chuàng)建快照的速度會(huì)比BGSAVE命令創(chuàng)建快照更快一些。即使這樣，SAVE命令也并不常用，通常只會(huì)在沒有足夠內(nèi)存或等待快照生成完畢也無所謂的情況下才會(huì)使用。
例如，當(dāng)redis收到SHUTDOWN命令關(guān)閉服務(wù)時(shí)，就會(huì)執(zhí)行一次SAVE命令，阻塞所有客戶端，并在SAVE命令執(zhí)行完畢后關(guān)閉。

RDB方式的優(yōu)劣

優(yōu)勢(shì)：

僅用一個(gè)文件備份數(shù)據(jù)，災(zāi)后易于恢復(fù)相比于aof，rdb文件更小，并且加載rdb文件恢復(fù)數(shù)據(jù)也更快

劣勢(shì)：

如果redis服務(wù)因故障關(guān)閉或重啟，會(huì)丟失最近一次快照創(chuàng)建后寫入的數(shù)據(jù)當(dāng)數(shù)據(jù)量很大的時(shí)候，創(chuàng)建子進(jìn)程會(huì)導(dǎo)致redis較長時(shí)間的停頓

AOF方式

簡單來說，AOF持久化會(huì)將被執(zhí)行的寫命令寫到aof文件的末尾，以此來記錄數(shù)據(jù)發(fā)生的變化。因此，redis只要從頭到尾重新執(zhí)行一遍aof文件中包含的所有寫命令，就可以恢復(fù)數(shù)據(jù)。

打開redis配置文件可以看到：

# 是否開啟aof持久化，默認(rèn)為關(guān)閉（no）
appendonly yes
# 設(shè)置對(duì)aof文件的同步頻率
# 每接收到一條寫命令就進(jìn)行一次同步，數(shù)據(jù)保障最有力，但對(duì)性能影響十分嚴(yán)重
appendfsync always
# 每秒進(jìn)行一次同步，推薦
appendfsync everysec
# 由操作系統(tǒng)來決定何時(shí)進(jìn)行同步
appendfsync no
# 重寫aof相關(guān)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

重寫/壓縮aof文件

由于aof持久化會(huì)不斷地記錄redis的寫命令，隨著redis的運(yùn)行，aof文件會(huì)越來越大，占用過多的硬盤空間，并增加redis進(jìn)行數(shù)據(jù)還原操作的時(shí)間。因此，必須要有避免aof文件體積過大的控制方案。

redis提供了BGREWRITEAOF命令對(duì)aof文件進(jìn)行重寫，BGREWRITEAOF會(huì)通過移除原aof文件中冗余的命令來盡可能的減小aof文件的體積。BGREWRITEAOF的工作原理與BGSAVE很像，會(huì)由redis創(chuàng)建一個(gè)子進(jìn)程，再由子進(jìn)程對(duì)aof文件進(jìn)行重寫。

當(dāng)然，BGREWRITEAOF命令同樣也有自動(dòng)觸發(fā)的機(jī)制，可通過配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size來自動(dòng)執(zhí)行。例如，配置了auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb，并且開啟了aof持久化，那么在aof文件體積大于64mb且當(dāng)前文件比上一次重寫后的文件體積大了一倍(100%)以上時(shí)，redis會(huì)自動(dòng)執(zhí)行BGREWRITEAOF命令。

AOF持久化的優(yōu)劣

優(yōu)勢(shì)

可以將丟失數(shù)據(jù)的時(shí)間窗口降低至1秒，并且不會(huì)對(duì)性能在成太大影響aof對(duì)于日志文件采用的是追加模式，因此在寫入過程中即使出現(xiàn)宕機(jī)，也不會(huì)破壞日志文件中已經(jīng)存在的內(nèi)容；若只寫入一半數(shù)據(jù)就宕機(jī)，在redis下次啟動(dòng)時(shí)，可通過redis-check-aod工具來解決數(shù)據(jù)一致性的問題

劣勢(shì)

aof文件的體積一直是AOF持久化最大的缺陷，即使有重寫aof文件的機(jī)制存在載入aof文件恢復(fù)數(shù)據(jù)的過程會(huì)比載入rdb文件耗時(shí)更長

 主從復(fù)制

盡管redis性能十分優(yōu)秀，但還是會(huì)遇到無法快速處理請(qǐng)求的問題，為了抗高并發(fā)帶來的數(shù)據(jù)庫性能問題，redis可以像關(guān)系型數(shù)據(jù)庫一樣進(jìn)行主從復(fù)制、讀寫分離。即向主服務(wù)器寫入數(shù)據(jù)，從服務(wù)器實(shí)時(shí)收到更新，并使用從服務(wù)器處理所有的讀請(qǐng)求，而不是像以前一樣將所有讀請(qǐng)求都發(fā)送給主服務(wù)器，造成主服務(wù)器壓力過大，通常讀請(qǐng)求會(huì)隨機(jī)地選擇使用哪一個(gè)從服務(wù)器，從而使負(fù)載均衡地分配到每一個(gè)從服務(wù)器上。下圖是一個(gè)簡單的redis主從架構(gòu)。

主從復(fù)制配置

首先在你的redis目錄下執(zhí)行vi redis6380.conf在當(dāng)前目錄下創(chuàng)建一個(gè)redis配置文件，寫入如下內(nèi)容：

include /usr/local/redis-4.0.13/redis.conf
port 6380
pidfile /var/run/redis_6380.pid
logfile 6380.log
dbfilename dump6380.rdb

說明：

• include：向當(dāng)前配置文件中引入所指向的配置文件的配置信息，這里引入的是redis默認(rèn)配置文件，其中已經(jīng)設(shè)置過遠(yuǎn)程訪問、密碼等，沒必要在新的配置文件中重新設(shè)置。對(duì)于有必要重新配置的配置信息來說（如端口號(hào)），include行下進(jìn)行的配置可以覆蓋引用的配置。
• port：端口號(hào)，我們的主從服務(wù)器是跑在同一臺(tái)虛擬機(jī)上的，因此需要配置不同的端口號(hào)。
• pidfile：自定義的pid文件，后臺(tái)程序的pid存在這個(gè)文件里。
• logfile：日志文件。
• dbfilename：rdb文件的名字。
  

經(jīng)過上述操作，一個(gè)新的主服務(wù)器就配置好了，接下來配置從服務(wù)器，同樣在當(dāng)前目錄下創(chuàng)建一個(gè)redis配置文件起名redis6382vi redis6382.conf

include /usr/local/redis-4.0.13/redis.conf
port 6382
pidfile /var/run/redis_6382.pid
logfile 6382.log
dbfilename dump6382.rdb
slaveof 127.0.0.1 6380
masterauth 主服務(wù)器的密碼

其中有一些從服務(wù)器額外的配置：

• slaveof：表示我是誰的從服務(wù)器，需要制定主服務(wù)器的ip地址和端口號(hào)
• masterauth：假如你的主服務(wù)器配置了密碼，那么需要在此進(jìn)行配置，否則從服務(wù)器將無法連接到主服務(wù)器

其他的從服務(wù)器配置也都類似，注意分配端口號(hào)，我這里又配置了一個(gè)6384。
配置成功后，在src目錄下使用./redis-server ../redis6380.conf就可以開啟主服務(wù)器了，接下來開啟從服務(wù)器會(huì)自動(dòng)連到主服務(wù)器上，注意指定對(duì)應(yīng)的配置文件。
執(zhí)行ps -ef | grep redis看到如下內(nèi)容則表示主從服務(wù)器啟動(dòng)成功：

root      2625     1  0 16:15 ?        00:00:00 ./redis-server *:6380
root      2630     1  0 16:15 ?        00:00:00 ./redis-server *:6382
root      2636     1  0 16:15 ?        00:00:00 ./redis-server *:6384

在主從服務(wù)器都啟動(dòng)好了以后，進(jìn)入主服務(wù)器的客戶端./redis-cli -p 6380 -a 你的密碼，執(zhí)行info replication可以查看主從服務(wù)器信息，如下

127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6382,state=online,offset=336,lag=1
slave1:ip=127.0.0.1,port=6384,state=online,offset=336,lag=1
master_replid:b5c68a979b28d2a9ef53476510758b5d1795418b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:336
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:336

同樣，在從服務(wù)器客戶端中執(zhí)行上述命令，也能夠得到信息

127.0.0.1:6384> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:686
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:b5c68a979b28d2a9ef53476510758b5d1795418b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:686
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:15
repl_backlog_histlen:672

至此，一個(gè)一主兩從、讀寫分離的redis架構(gòu)已經(jīng)配置好并成功啟動(dòng)了。

主從復(fù)制的啟動(dòng)過程

上圖是舊版主從Redis的啟動(dòng)過程，需要特殊說明的幾點(diǎn)是：

• 從服務(wù)器在進(jìn)行初始連接的時(shí)候，數(shù)據(jù)庫中原有的所有數(shù)據(jù)都將被丟失，并替換成主服務(wù)器發(fā)送來的數(shù)據(jù)
• 從服務(wù)器不負(fù)責(zé)key的過期操作，而是被動(dòng)的接受主服務(wù)器發(fā)來的命令，當(dāng)一個(gè) master 讓一個(gè) key 到期（或由于 LRU 算法將之驅(qū)逐）時(shí)，它會(huì)合成一個(gè) DEL 命令并傳輸?shù)剿械?slave
• SYNC是一個(gè)非常耗費(fèi)資源的操作，在BGSAVE期間主服務(wù)器的總吞吐量下降，接著耗費(fèi)大量的主從服務(wù)器的網(wǎng)絡(luò)資源傳送rdb文件，在從服務(wù)器載入rdb文件時(shí)會(huì)無法響應(yīng)客戶端的請(qǐng)求；但SYNC最大的缺陷是在從服務(wù)器因斷線進(jìn)行重新連接時(shí)，沒必要申請(qǐng)一個(gè)rdb文件從頭再加載一次，因?yàn)檫@個(gè)新的rdb文件中包含的大部分?jǐn)?shù)據(jù)很可能在斷線之前就已經(jīng)寫入了從服務(wù)器，此時(shí)從服務(wù)器只需要得到在斷線期間寫入的數(shù)據(jù)就得了
  

 部分重同步

為了彌補(bǔ)舊版復(fù)制的缺陷，Redis從2.8版本開始使用PSYNC命令代替SYNC命令。PSYNC有完整重同步和部分重同步兩種模式，其中完整重同步和上述的舊版同步差不多，也是得發(fā)個(gè)rdb。但是部分重同步很牛X了：它可以只將斷線期間的寫入主服務(wù)器的寫命令發(fā)送給從服務(wù)器，耗費(fèi)資源更少，速度也快的多。如下圖。

部分重同步的實(shí)現(xiàn)原理并不復(fù)雜，由三部分構(gòu)成：復(fù)制偏移量（offset）、復(fù)制積壓緩沖區(qū)和服務(wù)器運(yùn)行id（runid）

復(fù)制偏移量
復(fù)制偏移量是用來確認(rèn)主從服務(wù)器的同步狀態(tài)的。主從服務(wù)器各自維護(hù)一份復(fù)制偏移量，當(dāng)主服務(wù)器向從服務(wù)器發(fā)送了N個(gè)字節(jié)的數(shù)據(jù)時(shí)，就將自己的復(fù)制偏移量加上N；從服務(wù)器收到N個(gè)字節(jié)的數(shù)據(jù)也會(huì)將自己的復(fù)制偏移量加上N。通過比較主從雙方的復(fù)制偏移量就可以很容易的確認(rèn)同步狀態(tài)。

復(fù)制積壓緩沖區(qū)
復(fù)制積壓緩沖區(qū)是由主服務(wù)器維護(hù)的一個(gè)固定長度的先進(jìn)先出的隊(duì)列，在主服務(wù)器進(jìn)行命令傳播的時(shí)候會(huì)順道讓命令入隊(duì)到復(fù)制積壓緩沖區(qū)中，如下：

由于復(fù)制積壓緩沖區(qū)是一個(gè)固定長度的隊(duì)列，所以它只會(huì)保存最近一段時(shí)間內(nèi)執(zhí)行的寫命令，并為隊(duì)列中的每個(gè)字節(jié)記錄對(duì)應(yīng)的復(fù)制偏移量。在從服務(wù)器發(fā)送PSYNC命令時(shí)，會(huì)攜帶上自己的復(fù)制偏移量，主服務(wù)器拿著這個(gè)偏移量去自己的復(fù)制積壓緩沖區(qū)中查看offset+1(即斷線后執(zhí)行的下一個(gè)命令)還在不在隊(duì)列中。如果還在，表示可以執(zhí)行部分重同步，后面會(huì)將從offset+1到隊(duì)尾的所有數(shù)據(jù)發(fā)送給從服務(wù)器；如果不在，那從服務(wù)器只能老老實(shí)實(shí)的去做完全重同步。

服務(wù)器運(yùn)行Id
服務(wù)器運(yùn)行Id說白了就是看主從服務(wù)器斷線之前是不是一家子。每一個(gè)redis服務(wù)器都有自己的運(yùn)行id，主從初次連接時(shí)，主服務(wù)器會(huì)把自己的服務(wù)器運(yùn)行id發(fā)送給從服務(wù)器保存起來，從服務(wù)器在重連接的時(shí)候會(huì)把之前保存的主服務(wù)器runid一并發(fā)給主服務(wù)器，主服務(wù)器會(huì)拿著這個(gè)runid和自己的runid進(jìn)行比對(duì)。如果一致，則表示該從服務(wù)器之前確實(shí)是從自己這里斷線的，接下來進(jìn)行偏移量的檢查；如果不一致，則表示這個(gè)從服務(wù)器先前是其他主服務(wù)器的slave，直接打去做完全重同步。

在之前執(zhí)行info replication命令的時(shí)候就可以看到服務(wù)器運(yùn)行id和復(fù)制偏移量。

綜上，一個(gè)新版redis復(fù)制的同步過程大致如下：

到此這篇關(guān)于Redis持久化與主從復(fù)制的實(shí)踐的文章就介紹到這了,更多相關(guān)Redis持久化與主從復(fù)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！