前言
只有光頭才能變強
好的，今天我們要上【鉑金二】了，如果還沒有上鉑金的，趕緊先去蹭蹭經驗再回來(不然不帶你上分了)：
在上篇中丟擲了一個問題：
拋個問題：如果從伺服器掛了，沒關係，我們一般會有多個從伺服器，其他的請求可以交由沒有掛的從伺服器繼續處理。如果主伺服器掛了，怎麼辦？因為我們的寫請求由主伺服器處理，只有一臺主伺服器，那就無法處理寫請求了？
Redis提供了哨兵(Sentinal)機制供我們解決上面的情況。如果主伺服器掛了，我們可以將從伺服器升級為主伺服器，等到舊的主伺服器(掛掉的那個)重連上來，會將它(掛掉的主伺服器)變成從伺服器。
- 這個過程叫做主備切換(故障轉移)
在正常的情況下，主從加哨兵(Sentinal)機制是這樣子的：
主伺服器掛了，主從複製操作就中止了，並且哨兵系統是可以察覺出主服務掛了。：
Redis提供哨兵機制可以將選舉一臺從伺服器變成主伺服器
然後舊的主伺服器如果重連了，會變成從伺服器：
這篇文章主要講講Redis的哨兵(Sentinal)機制的一些細節。希望看完對大家有所幫助~
一、哨兵(Sentinal)機制
High Availability: Redis Sentinel is the official high availability solution for Redis.
哨兵(Sentinal)機制主要用於實現Redis的高可用性，主要的功能如下：
- Monitoring. Sentinel constantly checks if your master and slave instances are working as expected.
- Sentinel不停地監控Redis主從伺服器是否正常工作
- Notification. Sentinel can notify the system administrator, another computer programs, via an API, that something is wrong with one of the monitored Redis instances.
- 如果某個Redis例項有故障，那麼哨兵負責傳送訊息通知管理員
- Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.
- 如果主伺服器掛掉了，會自動將從伺服器提升為主伺服器(包括配置都會修改)。
- Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.
- Sentinel可以作為配置中心，能夠提供當前主伺服器的資訊。
下面來具體講講Sentinel是如何將從伺服器提升為主伺服器的。
tips:Sentinel可以讓我們的Redis實現高可用，Sentinel作為這麼一個元件，自身也必然是高可用的(不可能是單點的)
1.1啟動和初始化Sentinel
首先我們要知道的是：Sentinel本質上只是一個執行在特殊模式下的Redis伺服器。因為Sentinel做的事情和Redis伺服器是不一樣的，所以它們的初始化是有所區別的(比如，Sentinel在初始化的時候並不會載入AOF/RDB檔案，因為Sentinel根本就不用資料庫)。
然後，在啟動的時候會將普通Redis伺服器的程式碼替換成Sentinel專用程式碼。(所以Sentinel雖然作為Redis伺服器，但是它不能執行SET、DBSIZE等等命令，因為命令表的程式碼被替換了)
接著，初始化Sentinel的狀態，並根據給定的配置檔案初始化Sentinel監視的主伺服器列表。
最後，Sentinel會建立兩個連向主伺服器的網路連線：
- 命令連線(傳送和接收命令)
- 訂閱連線(訂閱主伺服器的
_sentinel_:hello頻道)
1.2獲取和更新資訊
Sentinel通過主伺服器傳送INFO命令來獲得主伺服器屬下所有從伺服器的地址資訊，併為這些從伺服器建立相應的例項結構。
當發現有新的從伺服器出現時，除了建立對應的從伺服器例項結構，Sentinel還會建立命令連線和訂閱連線。
在Sentinel執行的過程中，通過命令連線會以每兩秒一次的頻率向監視的主從伺服器的_sentinel_:hello頻道傳送命令(主要傳送Sentinel本身的資訊，監聽主從伺服器的資訊)，並通過訂閱連線接收_sentinel_:hello頻道的資訊。
- 這樣一來一回，我們就可以更新每個Sentinel例項結構的資訊。
1.3判斷主伺服器是否下線了
判斷主伺服器是否下線有兩種情況：
- 主觀下線
- Sentinel會以每秒一次的頻率向與它建立命令連線的例項(包括主從伺服器和其他的Sentinel)傳送PING命令，通過PING命令返回的資訊判斷例項是否線上
- 如果一個主伺服器在
down-after-milliseconds毫秒內連續向Sentinel傳送無效回覆，那麼當前Sentinel就會主觀認為該主伺服器已經下線了。
- 客觀下線
- 當Sentinel將一個主伺服器判斷為主觀下線以後，為了確認該主伺服器是否真的下線，它會向同樣監視該主伺服器的Sentinel詢問，看它們是否也認為該主伺服器是否下線。
- 如果足夠多的Sentinel認為該主伺服器是下線的，那麼就判定該主服務為客觀下線，並對主伺服器執行故障轉移操作。
在多少毫秒內無效回覆才認定主伺服器是主觀下線的，以及有多少個Sentinel認為主伺服器是下線才認定為客觀下線。這都是可以配置的
1.4選舉領頭Sentinel和故障轉移
當一個主伺服器認為為客觀下線以後，監視這個下線的主伺服器的各種Sentinel會進行協商，選舉出一個領頭的Sentinel，領頭的Sentinel會對下線的主伺服器執行故障轉移操作。
選舉領頭Sentinel的規則也比較多，總的來說就是先到先得(哪個快，就選哪個)
選舉出領頭的Sentinel之後，領頭的Sentinel會對已下線的主伺服器執行故障轉移操作，包括三個步驟：
- 在已下線主伺服器屬下的從伺服器中，挑選一個轉換為主伺服器
- 讓已下線主伺服器屬下的所有從伺服器改為複製新的主伺服器
- 已下線的主伺服器重新連線時，讓他成為新的主伺服器的從伺服器
- (這三步實際上就是文章開頭的圖片)
挑選某一個從伺服器作為主伺服器也是有策略的，大概如下：
- （1）跟master斷開連線的時長
- （2）slave優先順序
- （3）複製offset
- （4）run id
最後
這篇文章主要講解了Sentinel的作用和工作的基本過程(我覺得已經基本OK了)，其中也涉及到了很多的細節，這裡我就沒有一一整理出來了。想要深入學習的同學最好自己看看書或者文件~~
tips:目前為止的主從+哨兵架構可以說Redis是高可用的，但要清楚的是：Redis還是會丟失資料的
丟失資料有兩種情況：
- 非同步複製導致的資料丟失
- 有部分資料還沒複製到從伺服器，主伺服器就當機了，此時這些部分資料就丟失了
- 腦裂導致的資料丟失
- 有時候主伺服器脫離了正常網路，跟其他從伺服器不能連線。此時哨兵可能就會認為主伺服器下線了(然後開啟選舉，將某個從伺服器切換成了主伺服器)，但是實際上主伺服器還執行著。這個時候，叢集裡就會有兩個伺服器(也就是所謂的腦裂)。
- 雖然某個從伺服器被切換成了主伺服器，但是可能客戶端還沒來得及切換到新的主伺服器，客戶端還繼續寫向舊主伺服器寫資料。舊的伺服器重新連線時，會作為從伺服器複製新的主伺服器(這意味著舊資料丟失)。
可以通過以下兩個配置儘量減少資料丟失的可能：
min-slaves-to-write 1
min-slaves-max-lag 10
複製程式碼從零單排學Redis【鉑金三】，敬請期待~
參考資料：
- 《Redis設計與實現》
- 《Redis實戰》
如果你覺得我寫得還不錯，瞭解一下：
- 堅持原創的技術公眾號：Java3y。
- 文章的目錄導航(精美腦圖+海量視訊資源)：github.com/ZhongFuChen…
