詳解Redis主從復(fù)制和哨兵機制

1. Redis主從復(fù)制

1.1 Redis主從復(fù)制

Redis主從復(fù)制主要有兩個角色，主機（master）對外提供讀寫功能，從機（slave）對外只提供讀功能，主機定期把數(shù)據(jù)同步到從機上保證數(shù)據(jù)一致性。

Redis主機數(shù)據(jù)同步到從機上有兩種方式，一種是全量同步，另一種是增量同步。

主從復(fù)制不會阻塞master，在數(shù)據(jù)同步時，master還可以繼續(xù)處理客戶端請求，因為redis會產(chǎn)生一個新的進程來解決同步問題。

一個redis也可以是從也可以是主（樹狀主從），可以減輕主機壓力。

1.2 Redis主從配置

只需要修改從服務(wù)器上的redis.conf文件：

# slaveof 《masterip》 《masterport》

# 表示當(dāng)前【從服務(wù)器】對應(yīng)的【主服務(wù)器】的IP是192.168.10.135，端口是6379。

slaveof 192.168.10.135 6379

啟動主服務(wù)器 redis-server redis.conf

進入從服務(wù)器文件夾，啟動從服務(wù)器

查看主服務(wù)器信息：redis-cli -p 6379 info Replication，可以看到有幾個從服務(wù)器

1.3 實現(xiàn)原理

redis的主從同步分為兩種，分為全量同步和增量同步。

只有從機第一次連接上主機是全量同步。

斷線重連很有可能觸發(fā)全量同步也有可能是增量同步（master判斷runid`是否一致）。

runid

每個redis服務(wù)器，不論主服務(wù)器還是從服務(wù)，都會有自己的運行id。PSYNC runid 這個命令，runid是指上一次復(fù)制主服務(wù)器的運行id，如果沒有保存這個id，PSYNC的命令會使用”PSYNC ？ -1” 這種形式發(fā)送給Master，請求主服務(wù)器進行全量復(fù)制。

offset（復(fù)制偏移量）

主服務(wù)器和從服務(wù)器會分別維護一個復(fù)制偏移量，主服務(wù)器每次向從服務(wù)器傳播N個字節(jié)的數(shù)據(jù)時，就將自己的復(fù)制偏移量的值加上N，從服務(wù)器每次收到主服務(wù)器傳播來的N個字節(jié)的數(shù)據(jù)時，就將自己的復(fù)制偏移量值加上N。

復(fù)制積壓緩沖區(qū)

復(fù)制積壓緩沖區(qū)是由主服務(wù)器維護一個固定長度（fixed-size）先進先出（FIFO）隊列，默認(rèn)大小是1MB。它主要的作用就是當(dāng)主服務(wù)器進行命令傳播時，不僅將命令發(fā)送給所有從服務(wù)器，還會將命令入隊到復(fù)制積壓緩沖區(qū)。如果主服務(wù)器向從服務(wù)器傳播數(shù)據(jù)時發(fā)生斷線，主服務(wù)器會將復(fù)制積壓緩沖區(qū)偏移量的所有數(shù)據(jù)都發(fā)送給從服務(wù)器（發(fā)送的是斷線之后的的數(shù)據(jù)）。

PSYNC執(zhí)行過程

1.Slave接受從客戶端發(fā)送過來的SLAVEOF命令。

當(dāng)前服務(wù)器判斷自己是否保存Master runid是否是第一次復(fù)制。

如果是第一次復(fù)制那么當(dāng)前服務(wù)器向Master發(fā)送PSYNC ？ -1命令，主動請求Master進行全量同步。

如果已經(jīng)父之過Master，那么當(dāng)前從服務(wù)器向Master發(fā)送PSYNC runid offset命令。

Master接收到PSYNC 命令后首先判斷runid是否和本機的id一致，如果runid和本機id不一致則返回+FULLRESYNC runid offset命令執(zhí)行全量同步操作，當(dāng)前服務(wù)器會將runid保存起來，在下次發(fā)送PSUNC時使用。

如果判斷runid和本機id一致，Master則會再次判斷offset偏移量和本機的偏移量相差有沒有超過復(fù)制積壓緩沖區(qū)大小，如果沒有那么就給Slave發(fā)送CONTINUE，此時Slave只需要等待Master傳回失去連接期間丟失的命令；

全量同步

Redis的全量同步主要分為三個階段：

同步快照階段：Master創(chuàng)建并發(fā)送快照給Slave，Slave再入快照并解析。Master同時將此階段產(chǎn)生的新的命令寫入到積壓緩沖區(qū)中。

同步寫緩沖階段：Master向Slave同步存儲在緩沖區(qū)的寫操作命令。

同步增量階段：Master向SLave同步寫操作命令。

增量同步

Redis增量同步主要是指Slave完成初始化開始正常工作時，Master發(fā)生的寫操作同步到Slave的過程。

通常情況下，Master沒執(zhí)行一個寫命令就會想Slave發(fā)送相同的寫命令，然后Slave接受并執(zhí)行。

2. 哨兵（sentinel）機制

2.1 哨兵機制介紹

sentinel進程是用于監(jiān)控Redis集群中Master主服務(wù)器工作的狀態(tài)。

在Master主服務(wù)器發(fā)生故障的時候，可以實現(xiàn)Master和Slave服務(wù)器的切換，保證系統(tǒng)的高可用。

2.2 為什么要有哨兵機制？

Redis主從復(fù)制的缺點：沒有辦法對master進行動態(tài)選舉，需要使用Sentinel機制完成動態(tài)選舉。

2.3 哨兵的作用

監(jiān)控（Monitoring）：sentinel會不斷檢查Master和Slave是否運行正常。

提醒（Notification）：當(dāng)被監(jiān)控的某個Redis節(jié)點出現(xiàn)問題時， sentinel 可以通過 API向管理員或者其他應(yīng)用程序發(fā)送通知。

自動故障轉(zhuǎn)移（Automatic failover）：當(dāng)Master不能正常操作時哨兵會開始一次故障轉(zhuǎn)移。 它會將失效的Master的其中一個Slave升級為新的Master，并讓其他Slave改為復(fù)制新的Master。 當(dāng)客戶端試圖連接失效的Master時，集群會向客戶端顯示新的Master的地址。 Master和Slave切換后，Master的redis.conf、Slave的reids.conf和senisentinel的sentinel.conf配置文件的內(nèi)容都會相應(yīng)的改變，即，Master主服務(wù)器的redis.conf配置文件中會多一行slaveof的配置，sentinel.conf的監(jiān)控目標(biāo)會隨之調(diào)換。

2.4 故障判斷原理分析

每個sentinel進程每秒鐘一次的頻率向整個集群中Master、Slave以及其它Sentinel進程發(fā)送一個PING命令。

如果一個實例（instance）距離最后一次有效回復(fù)PING命令超過down-after-milliseconds選項所指定的值，這個實例會被sentinel進程標(biāo)記為主觀下線（SDOWN）。

如果一個Master主服務(wù)器被標(biāo)記為主觀下線（SDOWN），則正在監(jiān)視這個Master主服務(wù)器的所有 Sentinel進程要以每秒一次的頻率確認(rèn)Master主服務(wù)器的確進入了主觀下線狀態(tài)。

當(dāng)有足夠數(shù)量的 Sentinel進程（大于等于配置文件指定的值）在指定的時間范圍內(nèi)確認(rèn)Master主服務(wù)器進入了主觀下線狀態(tài)（SDOWN）， 則Master主服務(wù)器會被標(biāo)記為客觀下線（ODOWN）。

在一般情況下， 每個 Sentinel進程會以每 10 秒一次的頻率向集群中的所有Master主服務(wù)器、Slave從服務(wù)器發(fā)送 INFO 命令。

當(dāng)Master主服務(wù)器被 Sentinel進程標(biāo)記為客觀下線（ODOWN）時，Sentinel進程向下線的 Master主服務(wù)器的所有 Slave從服務(wù)器發(fā)送 INFO 命令的頻率會從 10 秒一次改為每秒一次。

若沒有足夠數(shù)量的 Sentinel進程同意 Master主服務(wù)器下線， Master主服務(wù)器的客觀下線狀態(tài)就會被移除。若 Master主服務(wù)器重新向 Sentinel進程發(fā)送 PING 命令返回有效回復(fù)，Master主服務(wù)器的主觀下線狀態(tài)就會被移除。