Redis是基于內(nèi)存的NoSQL數(shù)據(jù)庫，讀寫速度自然快，但內(nèi)存是瞬時的，在redis服務(wù)關(guān)閉或重啟之后，redis存放在內(nèi)存的數(shù)據(jù)就會丟失，為了解決這個問題，redis提供了兩種持久化方式，以便在發(fā)生故障后恢復(fù)數(shù)據(jù)。
redis提供了兩種不同的持久化方式來將數(shù)據(jù)存儲到硬盤中。一種是快照方式（也叫RDB方式），它可以將莫一時刻存在于redis中的所有數(shù)據(jù)存儲到硬盤；另一種叫只追加文件（AOF）方式，它會定時的復(fù)制redis執(zhí)行的所有寫命令到硬盤。這兩種持久化方式各有千秋，既可以同時使用，也可以獨(dú)立使用，在某些情況下甚至可以兩種都不使用。
RDB方式
RDB方式也稱快照方式，通過創(chuàng)建快照來保存某個時間點(diǎn)上的數(shù)據(jù)副本（.rdb）到硬盤。在重啟服務(wù)器后，redis會加載這個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 ./
說明
創(chuàng)建快照
BGSAVE：
BGSAVE命令可以用于創(chuàng)建一個快照，在redis接收到BGSAVE命令后會fork出一個子進(jìn)程，子進(jìn)程負(fù)責(zé)將快照寫入硬盤，而父進(jìn)程則繼續(xù)處理命令請求。需要注意的是redis在創(chuàng)建子進(jìn)程時會阻塞父進(jìn)程，時間長短與redis占用的內(nèi)存大小成正比。
除了手動的調(diào)用BGSAVE命令外，BGSAVE命令的觸發(fā)條件有如下兩種：
BGSAVE命令。SYNC命令請求數(shù)據(jù)同步，在主服務(wù)器收到SYNC命令后，會執(zhí)行一次BGSAVE命令，后將生成的rdb文件發(fā)送給從服務(wù)器進(jìn)行數(shù)據(jù)同步。SAVE：
SAVE命令同樣可以創(chuàng)建一個快照，但與BGSAVE命令不同的是SAVE命令不會創(chuàng)建子進(jìn)程，所以接收到SAVE命令的redis服務(wù)器在快照創(chuàng)建完畢之前不會響應(yīng)其他任何命令。由于在創(chuàng)建快照的過程中沒有其他進(jìn)程搶奪資源，所以SAVE命令創(chuàng)建快照的速度會比BGSAVE命令創(chuàng)建快照更快一些。即使這樣，SAVE命令也并不常用，通常只會在沒有足夠內(nèi)存或等待快照生成完畢也無所謂的情況下才會使用。
例如，當(dāng)redis收到SHUTDOWN命令關(guān)閉服務(wù)時，就會執(zhí)行一次SAVE命令，阻塞所有客戶端，并在SAVE命令執(zhí)行完畢后關(guān)閉。
RDB方式的優(yōu)劣
優(yōu)勢：
僅用一個文件備份數(shù)據(jù)，災(zāi)后易于恢復(fù)相比于aof，rdb文件更小，并且加載rdb文件恢復(fù)數(shù)據(jù)也更快
劣勢：
如果redis服務(wù)因故障關(guān)閉或重啟，會丟失最近一次快照創(chuàng)建后寫入的數(shù)據(jù)當(dāng)數(shù)據(jù)量很大的時候，創(chuàng)建子進(jìn)程會導(dǎo)致redis較長時間的停頓
AOF方式
簡單來說，AOF持久化會將被執(zhí)行的寫命令寫到aof文件的末尾，以此來記錄數(shù)據(jù)發(fā)生的變化。因此，redis只要從頭到尾重新執(zhí)行一遍aof文件中包含的所有寫命令，就可以恢復(fù)數(shù)據(jù)。
打開redis配置文件可以看到：
# 是否開啟aof持久化，默認(rèn)為關(guān)閉（no） appendonly yes # 設(shè)置對aof文件的同步頻率 # 每接收到一條寫命令就進(jìn)行一次同步，數(shù)據(jù)保障最有力，但對性能影響十分嚴(yán)重 appendfsync always # 每秒進(jìn)行一次同步，推薦 appendfsync everysec # 由操作系統(tǒng)來決定何時進(jìn)行同步 appendfsync no # 重寫aof相關(guān) auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
重寫/壓縮aof文件
由于aof持久化會不斷地記錄redis的寫命令，隨著redis的運(yùn)行，aof文件會越來越大，占用過多的硬盤空間，并增加redis進(jìn)行數(shù)據(jù)還原操作的時間。因此，必須要有避免aof文件體積過大的控制方案。
redis提供了BGREWRITEAOF命令對aof文件進(jìn)行重寫，BGREWRITEAOF會通過移除原aof文件中冗余的命令來盡可能的減小aof文件的體積。BGREWRITEAOF的工作原理與BGSAVE很像，會由redis創(chuàng)建一個子進(jìn)程，再由子進(jìn)程對aof文件進(jìn)行重寫。
當(dāng)然，BGREWRITEAOF命令同樣也有自動觸發(fā)的機(jī)制，可通過配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size來自動執(zhí)行。例如，配置了auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb，并且開啟了aof持久化，那么在aof文件體積大于64mb且當(dāng)前文件比上一次重寫后的文件體積大了一倍(100%)以上時，redis會自動執(zhí)行BGREWRITEAOF命令。
AOF持久化的優(yōu)劣
優(yōu)勢
可以將丟失數(shù)據(jù)的時間窗口降低至1秒，并且不會對性能在成太大影響aof對于日志文件采用的是追加模式，因此在寫入過程中即使出現(xiàn)宕機(jī)，也不會破壞日志文件中已經(jīng)存在的內(nèi)容；若只寫入一半數(shù)據(jù)就宕機(jī)，在redis下次啟動時，可通過redis-check-aod工具來解決數(shù)據(jù)一致性的問題
劣勢
aof文件的體積一直是AOF持久化最大的缺陷，即使有重寫aof文件的機(jī)制存在載入aof文件恢復(fù)數(shù)據(jù)的過程會比載入rdb文件耗時更長
盡管redis性能十分優(yōu)秀，但還是會遇到無法快速處理請求的問題，為了抗高并發(fā)帶來的數(shù)據(jù)庫性能問題，redis可以像關(guān)系型數(shù)據(jù)庫一樣進(jìn)行主從復(fù)制、讀寫分離。即向主服務(wù)器寫入數(shù)據(jù)，從服務(wù)器實(shí)時收到更新，并使用從服務(wù)器處理所有的讀請求，而不是像以前一樣將所有讀請求都發(fā)送給主服務(wù)器，造成主服務(wù)器壓力過大，通常讀請求會隨機(jī)地選擇使用哪一個從服務(wù)器，從而使負(fù)載均衡地分配到每一個從服務(wù)器上。下圖是一個簡單的redis主從架構(gòu)。
首先在你的redis目錄下執(zhí)行vi redis6380.conf在當(dāng)前目錄下創(chuàng)建一個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
說明：
經(jīng)過上述操作，一個新的主服務(wù)器就配置好了，接下來配置從服務(wù)器，同樣在當(dāng)前目錄下創(chuàng)建一個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ù)器額外的配置：
其他的從服務(wù)器配置也都類似，注意分配端口號，我這里又配置了一個6384。
配置成功后，在src目錄下使用./redis-server ../redis6380.conf就可以開啟主服務(wù)器了，接下來開啟從服務(wù)器會自動連到主服務(wù)器上，注意指定對應(yīng)的配置文件。
執(zhí)行ps -ef | grep redis看到如下內(nèi)容則表示主從服務(wù)器啟動成功：
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ù)器都啟動好了以后，進(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
至此，一個一主兩從、讀寫分離的redis架構(gòu)已經(jīng)配置好并成功啟動了。
上圖是舊版主從Redis的啟動過程，需要特殊說明的幾點(diǎn)是：
部分重同步
為了彌補(bǔ)舊版復(fù)制的缺陷，Redis從2.8版本開始使用PSYNC命令代替SYNC命令。PSYNC有完整重同步和部分重同步兩種模式，其中完整重同步和上述的舊版同步差不多，也是得發(fā)個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個字節(jié)的數(shù)據(jù)時，就將自己的復(fù)制偏移量加上N；從服務(wù)器收到N個字節(jié)的數(shù)據(jù)也會將自己的復(fù)制偏移量加上N。通過比較主從雙方的復(fù)制偏移量就可以很容易的確認(rèn)同步狀態(tài)。
復(fù)制積壓緩沖區(qū)
復(fù)制積壓緩沖區(qū)是由主服務(wù)器維護(hù)的一個固定長度的先進(jìn)先出的隊(duì)列，在主服務(wù)器進(jìn)行命令傳播的時候會順道讓命令入隊(duì)到復(fù)制積壓緩沖區(qū)中，如下：
由于復(fù)制積壓緩沖區(qū)是一個固定長度的隊(duì)列，所以它只會保存最近一段時間內(nèi)執(zhí)行的寫命令，并為隊(duì)列中的每個字節(jié)記錄對應(yīng)的復(fù)制偏移量。在從服務(wù)器發(fā)送PSYNC命令時，會攜帶上自己的復(fù)制偏移量，主服務(wù)器拿著這個偏移量去自己的復(fù)制積壓緩沖區(qū)中查看offset+1(即斷線后執(zhí)行的下一個命令)還在不在隊(duì)列中。如果還在，表示可以執(zhí)行部分重同步，后面會將從offset+1到隊(duì)尾的所有數(shù)據(jù)發(fā)送給從服務(wù)器；如果不在，那從服務(wù)器只能老老實(shí)實(shí)的去做完全重同步。
服務(wù)器運(yùn)行Id
服務(wù)器運(yùn)行Id說白了就是看主從服務(wù)器斷線之前是不是一家子。每一個redis服務(wù)器都有自己的運(yùn)行id，主從初次連接時，主服務(wù)器會把自己的服務(wù)器運(yùn)行id發(fā)送給從服務(wù)器保存起來，從服務(wù)器在重連接的時候會把之前保存的主服務(wù)器runid一并發(fā)給主服務(wù)器，主服務(wù)器會拿著這個runid和自己的runid進(jìn)行比對。如果一致，則表示該從服務(wù)器之前確實(shí)是從自己這里斷線的，接下來進(jìn)行偏移量的檢查；如果不一致，則表示這個從服務(wù)器先前是其他主服務(wù)器的slave，直接打去做完全重同步。
在之前執(zhí)行info replication命令的時候就可以看到服務(wù)器運(yùn)行id和復(fù)制偏移量。
綜上，一個新版redis復(fù)制的同步過程大致如下：
到此這篇關(guān)于Redis持久化與主從復(fù)制的實(shí)踐的文章就介紹到這了,更多相關(guān)Redis持久化與主從復(fù)制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
標(biāo)簽：大慶 吉安 果洛 朝陽 楊凌 江蘇 北京 臺州
巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《Redis持久化與主從復(fù)制的實(shí)踐》，本文關(guān)鍵詞 Redis,持久化,與,主從,復(fù)制,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。
