Redis主從復(fù)制的問題

Redis 主從復(fù)制 可將 主節(jié)點 數(shù)據(jù)同步給 從節(jié)點，從節(jié)點此時有兩個作用：

1. 一旦 主節(jié)點宕機，從節(jié)點 作為 主節(jié)點 的 備份 可以隨時頂上來。
2. 擴展 主節(jié)點 的 讀能力，分擔(dān)主節(jié)點讀壓力。

主從復(fù)制 同時存在以下幾個問題：

1. 一旦 主節(jié)點宕機，從節(jié)點 晉升成 主節(jié)點，同時需要修改 應(yīng)用方 的 主節(jié)點地址，還需要命令所有 從節(jié)點去 復(fù)制 新的主節(jié)點，整個過程需要 人工干預(yù)。
2. 主節(jié)點 的 寫能力 受到 單機的限制。
3. 主節(jié)點 的 存儲能力 受到 單機的限制。
4. 原生復(fù)制 的弊端在早期的版本中也會比較突出，比如：Redis 復(fù)制中斷 后，從節(jié)點 會發(fā)起 psync。此時如果 同步不成功，則會進(jìn)行 全量同步，主庫 執(zhí)行 全量備份 的同時，可能會造成毫秒或秒級的 卡頓。

Redis 的 哨兵（Sentinel）深入探究

Redis Sentinel的架構(gòu)

Redis的哨兵機制就是解決我們以上主從復(fù)制存在缺陷（選舉問題），保證我們的Redis高可用，實現(xiàn)自動化故障發(fā)現(xiàn)與故障轉(zhuǎn)移。

該系統(tǒng)執(zhí)行以下三個任務(wù)：

“

監(jiān)控：哨兵會不斷檢查你的主服務(wù)器和從服務(wù)器是否運作正常。

提醒：當(dāng)被監(jiān)控的某個Redis服務(wù)器出現(xiàn)問題時，哨兵可以通過API給程序員發(fā)送通知

自動故障轉(zhuǎn)移：主服務(wù)器宕機，哨兵會開始一次自動故障轉(zhuǎn)移操作，升級一個從服務(wù)器為主服務(wù)器，并讓其他從服務(wù)器改為復(fù)制新的主服務(wù)器.

配置 Sentinel

Redis 源碼中包含了一個名為 sentinel.conf 的文件， 這個文件是一個帶有詳細(xì)注釋的 Sentinel 配置文件示例。

運行一個 Sentinel 所需的最少配置如下所示：

“

1）sentinel monitor mymaster 192.168.10.202 6379 2

Sentine監(jiān)聽的maste地址，第一個參數(shù)是給master起的名字，第二個參數(shù)為master IP，第三個為master端口，第四個為當(dāng)該master掛了的時候，若想將該master判為失效，
在Sentine集群中必須至少2個Sentine同意才行，只要該數(shù)量不達(dá)標(biāo)，則就不會發(fā)生故障遷移。
-----------------------------------------------------------------------------------------------

2）sentinel down-after-milliseconds mymaster 30000

表示master被當(dāng)前sentinel實例認(rèn)定為失效的間隔時間，在這段時間內(nèi)一直沒有給Sentine返回有效信息，則認(rèn)定該master主觀下線。
只有在足夠數(shù)量的 Sentinel 都將一個服務(wù)器標(biāo)記為主觀下線之后， 服務(wù)器才會被標(biāo)記為客觀下線，``將服務(wù)器標(biāo)記為客觀下線所需的 Sentinel 數(shù)量由對主服務(wù)器的配置決定。
-----------------------------------------------------------------------------------------------

3）sentinel parallel-syncs mymaster 2

當(dāng)在執(zhí)行故障轉(zhuǎn)移時，設(shè)置幾個slave同時進(jìn)行切換master，該值越大，則可能就有越多的slave在切換master時不可用，可以將該值設(shè)置為1，即一個一個來，這樣在某個
slave進(jìn)行切換master同步數(shù)據(jù)時，其余的slave還能正常工作，以此保證每次只有一個從服務(wù)器處于不能處理命令請求的狀態(tài)。
-----------------------------------------------------------------------------------------------

4）sentinel can-failover mymaster ``yes

在sentinel檢測到O_DOWN后，是否對這臺redis啟動failover機制
-----------------------------------------------------------------------------------------------

5）sentinel auth-pass mymaster 20180408

設(shè)置sentinel連接的master和slave的密碼，這個需要和redis.conf文件中設(shè)置的密碼一樣
-----------------------------------------------------------------------------------------------

6）sentinel failover-timeout mymaster 180000

failover過期時間，當(dāng)failover開始后，在此時間內(nèi)仍然沒有觸發(fā)任何failover操作，當(dāng)前sentinel將會認(rèn)為此次failoer失敗。 
執(zhí)行故障遷移超時時間，即在指定時間內(nèi)沒有大多數(shù)的sentinel 反饋master下線，該故障遷移計劃則失效
-----------------------------------------------------------------------------------------------

7）sentinel config-epoch mymaster 0

選項指定了在執(zhí)行故障轉(zhuǎn)移時， 最多可以有多少個從服務(wù)器同時對新的主服務(wù)器進(jìn)行同步。這個數(shù)字越小， 完成故障轉(zhuǎn)移所需的時間就越長。
-----------------------------------------------------------------------------------------------

8）sentinel notification-script mymaster ``/var/redis/notify``.sh

當(dāng)failover時，可以指定一個``"通知"``腳本用來告知當(dāng)前集群的情況。
腳本被允許執(zhí)行的最大時間為60秒，如果超時，腳本將會被終止(KILL)
-----------------------------------------------------------------------------------------------

9）sentinel leader-epoch mymaster 0

同時一時間最多0個slave可同時更新配置,建議數(shù)字不要太大,以免影響正常對外提供服務(wù)。

主觀下線和客觀下線

“

• 主觀下線：指的是單個 Sentinel 實例對服務(wù)器做出的下線判斷。
• 客觀下線：指的是多個 Sentinel 實例在對同一個服務(wù)器做出 SDOWN主觀下線 判斷。

Redis Sentinel的工作原理

1.每個 Sentinel 以每秒一次的頻率向它所知的主服務(wù)器、從服務(wù)器以及其他 Sentinel 實例發(fā)送一個 PING 命令。

2.如果一個實例距離最后一次有效回復(fù) PING 命令的時間超過指定的值， 那么這個實例會被 Sentinel 標(biāo)記為主觀下線。

3.正在監(jiān)視這個主服務(wù)器的所有 Sentinel 要以每秒一次的頻率確認(rèn)主服務(wù)器的確進(jìn)入了主觀下線狀態(tài)。

4.有足夠數(shù)量的 Sentinel 在指定的時間范圍內(nèi)同意這一判斷， 那么這個主服務(wù)器被標(biāo)記為客觀下線。

5.每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主服務(wù)器和從服務(wù)器發(fā)送 INFO 命令。當(dāng)一個主服務(wù)器被 Sentinel 標(biāo)記為客觀下線時， Sentinel 向下線主服務(wù)器的所有從服務(wù)器發(fā)送 INFO 命令的頻率會從 10 秒一次改為每秒一次。

6.Sentinel 和其他 Sentinel 協(xié)商 主節(jié)點 的狀態(tài)，如果 主節(jié)點 處于 SDOWN 狀態(tài)，則投票自動選出新的 主節(jié)點。將剩余的 從節(jié)點 指向 新的主節(jié)點 進(jìn)行 數(shù)據(jù)復(fù)制。

7.當(dāng)沒有足夠數(shù)量的 Sentinel 同意 主服務(wù)器 下線時， 主服務(wù)器 的 客觀下線狀態(tài) 就會被移除。當(dāng) 主服務(wù)器 重新向 Sentinel 的 PING 命令返回 有效回復(fù) 時，主服務(wù)器 的 主觀下線狀態(tài) 就會被移除。

自動發(fā)現(xiàn) Sentinel 和從服務(wù)器

一個 Sentinel 可以與其他多個 Sentinel 進(jìn)行連接， 各個 Sentinel 之間可以互相檢查對方的可用性， 并進(jìn)行信息交換。

你無須為運行的每個 Sentinel 分別設(shè)置其他 Sentinel 的地址， 因為 Sentinel 可以通過發(fā)布與訂閱功能來自動發(fā)現(xiàn)正在監(jiān)視相同主服務(wù)器的其他 Sentinel。

“

• 每個 Sentinel 會以每兩秒一次的頻率， 通過發(fā)布與訂閱功能， 向被它監(jiān)視的所有主服務(wù)器和從服務(wù)器的頻道發(fā)送一條信息， 信息中包含了 Sentinel 的 IP 地址、端口號和運行 ID （runid）。
• 每個 Sentinel 都訂閱了被它監(jiān)視的所有主服務(wù)器和從服務(wù)器的頻道， 查找之前未出現(xiàn)過的 sentinel 。當(dāng)一個 Sentinel 發(fā)現(xiàn)一個新的 Sentinel 時， 它會將新的 Sentinel 添加到一個列表中。
• Sentinel 發(fā)送的信息中還包括完整的主服務(wù)器當(dāng)前配置。如果一個 Sentinel 包含的主服務(wù)器配置比另一個 Sentinel 發(fā)送的配置要舊， 那么這個 Sentinel 會立即升級到新配置上。
• 在將一個新 Sentinel 添加到監(jiān)視主服務(wù)器的列表上面之前， Sentinel 會先檢查列表中是否已經(jīng)包含了和要添加的 Sentinel 擁有相同運行 ID 或者相同地址（包括 IP 地址和端口號）的 Sentinel ， 如果是的話， Sentinel 會先移除列表中已有的那些擁有相同運行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel

故障轉(zhuǎn)移

一次故障轉(zhuǎn)移操作由以下步驟組成：

“

• 發(fā)現(xiàn)主服務(wù)器已經(jīng)進(jìn)入客觀下線狀態(tài)。
• 對我們的當(dāng)前紀(jì)元進(jìn)行自增， 并嘗試在這個紀(jì)元中當(dāng)選。
• 如果當(dāng)選失敗， 那么在設(shè)定的故障遷移超時時間的兩倍之后， 重新嘗試當(dāng)選。如果當(dāng)選成功， 那么執(zhí)行以下步驟。
• 選出一個從服務(wù)器，并將它升級為主服務(wù)器。
• 向被選中的從服務(wù)器發(fā)送 SLAVEOF NO ONE 命令，讓它轉(zhuǎn)變?yōu)橹鞣?wù)器。
• 通過發(fā)布與訂閱功能， 將更新后的配置傳播給所有其他 Sentinel ， 其他 Sentinel 對它們自己的配置進(jìn)行更新。
• 向已下線主服務(wù)器的從服務(wù)器發(fā)送 SLAVEOF 命令， 讓它們?nèi)?fù)制新的主服務(wù)器。
• 當(dāng)所有從服務(wù)器都已經(jīng)開始復(fù)制新的主服務(wù)器時， 領(lǐng)頭 Sentinel 終止這次故障遷移操作。

參考：

https://redis.io/

https://www.cnblogs.com/bingshu/p/9776610.html