什麼是“腦裂”
“腦裂” 就是雙master
你的 cluster 裡面有兩個節點， 兩個結點都會覺得現在沒有 master，
是以每個都把自己選舉成 master
觀點1：1 叢集奇數2 投票過半和3 任期大小
1、zooKeeper預設采用了Quorums這種方式來防止"腦裂"現象。
即隻有叢集中超過半數節點投票才能選舉出Leader。
這樣的方式可以確定leader的唯一性,要麼選出唯一的一個leader,要麼選舉失敗。在zookeeper中Quorums作用如下：
1] 叢集中最少的節點數用來選舉leader保證叢集可用。
2] 通知用戶端資料已經安全儲存前叢集中最少數量的節點數已經儲存了該資料。
一旦這些節點儲存了該資料，用戶端将被通知已經安全儲存了，可以繼續其他任務。而叢集中剩餘的節點将會最終也儲存了該資料。
假設某個leader假死，其餘的followers選舉出了一個新的leader。
這時，舊的leader複活并且仍然認為自己是leader，這個時候它向其他followers發出寫請求也是會被拒絕的。
因為每當新leader産生時，會生成一個epoch标号(辨別目前屬于那個leader的統治時期)，這個epoch是遞增的，followers如果确認了新的leader存在，知道其epoch，就會拒絕epoch小于現任leader epoch的所有請求。
那有沒有follower不知道新的leader存在呢，有可能，但肯定不是大多數，否則新leader無法産生。
Zookeeper的寫也遵循quorum機制，是以，得不到大多數支援的寫是無效的，舊leader即使各種認為自己是leader，依然沒有什麼作用。
https://raft.github.io/
【當問到這個問題時候，現在還是一片空白，感覺很難回答，其實你思路就是基本流程，不需要特别處理】
假死：由于心跳逾時（網絡原因導緻的）認為master死了，但其實master還存活着 假死導緻腦裂的一個根源問題就是假死。timeout
腦裂：由于假死會發起新的master選舉，選舉出一個新的master，但舊的master網絡又通了， 導緻出現了兩個master ，有的用戶端連接配接到老的master 有的用戶端連結到新的master。
zk quorum（半數機制）機制解決腦裂，但是timeout造成正常情況下誤判？？？如何解決
逾時機制：
- [源碼解析] 從TimeoutException看Flink的心跳機制
- ubbo的逾時機制和重試機制
- Hystrix逾時機制
-
Netty HashedWheelTimer時間輪源碼學習 好多概念，
這裡隻說一個 輪盤定時器 HashedWheelTimer
從小工到專家：設計循環隊列 也提到了。
俄羅斯輪盤
Kafka中的時間輪（TimingWheel）是一個存儲定時任務的環形隊列，底層采用數組實作，數組中的每個元素可以存放一個定時任務清單（TimerTaskList）。TimerTaskList是一個環形的雙向連結清單，連結清單中的每一項表示的都是定時任務項（TimerTaskEntry），其中封裝了真正的定時任務TimerTask
其實時間輪就是一個不存在hash沖突的資料結構
就拿秒表來說，它總是落在 0 - 59 秒，每走一圈，又會重新開始。
觀點2: 對假死現象
選舉是保證raft安全性的基礎，心跳是保證叢集能夠盡快從Leader當機或者網絡分區中恢複的關鍵。etcd中将心跳和計時做了內建，抽象成tick
為什麼需要預選
添加預選的原因是為了在網絡狀況不佳時，減少選舉次數。
舉個具體場景，當叢集中的網絡不穩定時，會有部分Follower不能及時地收到Leader的心跳，這時候就會有Follower發起選舉。
但是網絡原因，它自身也很難拿到超過半數選票當選，或者當選之後也很快就會有别的節點因為收不到心跳而再次發起選舉，這就導緻了叢集經常處于選舉狀态而不可用。
為了防止這種情況的頻繁發生，添加預選階段，等于把Leader挂掉這件事從單個節點自己判斷，變成了半數節點一起判斷，大大減少了誤判。
凡事都有利有弊，當Leader雖然沒挂掉，但性能有問題時，可能隻影響了不到一半的節點。添加預選之後可能會導緻性能不佳的Leader很難被選下去，進而影響讀寫性能。
作者：空擋
連結：https://www.jianshu.com/p/ff6aaa66ea0f
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
上面看不懂就對了，
現在從這個問題開始old leader根據什麼來降級的，需要了解raft過程
條分縷析 Raft 算法
本文整理自 Ongaro 在 Youtube 上的視訊。
系統模型
我們假設：
- 伺服器可能會當機、會停止運作過段時間再恢複，但是非拜占庭的（即它的行為是非惡意的，不會篡改資料等）；
- 網絡通信會中斷，消息可能會丢失、延遲或亂序；可能會網絡分區；
Raft 是基于 Leader 的共識算法，故主要考慮：
- Leader 正常運作
- Leader 故障，必須選出新的 Leader
優點：隻有一個 Leader，簡單。
難點：Leader 發生改變時，可能會使系統處于不一緻的狀态，是以，下一任 Leader 必須進行清理；
難點：Leader 發生改變時，可能會使系統處于不一緻的狀态，是以，下一任 Leader 必須進行清理；
系統正常運作時，隻有一個 Leader，其餘都是 Followers.
大家可以看到：
這裡說明candidate狀态變化，通過上面2個圖
你會發現，有3個狀态 1， 後退 2 不變 3 前進
問題是：原則上我們可以無限重複分割選票，
假如選舉同一時間開始，同一時間逾時，同一時間再次選舉，如此循環。
解決辦法很簡單：
- 節點随機選擇逾時時間，通常在 [T, 2T] 之間（T =
electionTimeout
- 這樣，節點不太可能再同時開始競選，先競選的節點有足夠的時間來索要其他節點的選票
- T >> broadcast time(T 遠大于廣播時間)時效果更佳
這裡對上面問題的回答，
逾時設定 并不少固定不變的，而是【t,2t】 之内随機時間。
Raft在網絡分區時leader選舉的一個疑問？
共識算法-raft論文分析
Raft 作者親自出的 Raft 試題，你能做對幾道
資料
[1]
MIT 6.824 Distributed Systems Spring 2020 中文翻譯版合集: https://www.bilibili.com/video/av91748150
如何安全的上司選舉（思考在雙master也符合這個規則嗎）
https://raft.github.io/raft.pdf
隐含條件：
1. vlolatile state on leaders 代表 不會持久化： 這個是很重要的一點。
2. 上個任期遺漏資料，不能通過上一個版本任期+寫入大多數來保證安全。例子1
大家可以看到，故障發送後，通過大多數判斷這個原則，失效了。
因為缺少 關鍵的“leader”，就是它 下線了。【過半失效、
crash的服務，你是不知道的。無法通過個數來統計了。
大家可以看到，圖c中的 s5，為什麼能被選擇上。最後一個任期 3大于其他 節點2，s1（不統一）【任期大規則失效】
rpc請求參數隐含一個條件：單節點不知道那個是安全的，那個不是安全的。
統計個數方式不行，是以通過最新的一個記錄做判斷。
同樣一個例子，一個寫入過半資料是安全的，另外一個寫入過半不是安全的。
差别在什麼地方？
Case 2: Leader 試圖送出之前任期的日志
如圖所示的情況，在任期 2 時記錄僅寫在 S1 和 S2 兩個節點上，由于某種原因，任期 3 的 Leader S5 并不知道這些記錄，S5 建立了自己的三條記錄然後當機了，然後任期 4 的 Leader S1 被選出，S1 試圖與其它伺服器的日志進行比對。是以它複制了任期 2 的日志到 S3。
此時 index=3 的記錄時是不安全的。
因為 S1 可能在此時當機，然後 S5 可能從 S2、S3、S4 獲得選票成為任期 5 的 Leader。一旦 S5 成為新 Leader，它将覆寫 index=3-5 的日志，S1-S3 的這些記錄都将消失。
我們還要需要一條新的規則，來處理這種情況。
觀察如下：下面2個情況寫入大多數節點後無法保證安全：
情況1: leader挂掉後，在目前term内：通過寫入大多數節點就是安全 判斷失效。例如 3個節點，寫入2個是安全的，其中一個節點挂掉 但是寫入和沒有寫入個數為1 無法判斷【統計個數失效】
情況2:當新選舉 ，term=4，通過先處理 tern=2的，也寫入大多數節點。5個寫入三個 依然被覆寫的可能。【曆史資料先同步失效】
抽象一下，圖9 ,節點s5,當選擇leader條件是，s1和s2必然同意。
還缺少一票。
假設s4 core了，必須s3同意。這保證,安全。安全安全。
s5 投票來自2部分：
什麼情況下是寫入安全的
- 目前leader節點，在任期内，必須有請求，并且該請求，寫入到大多數節點。
- 這樣不會出現被小于目前任期的資料覆寫。
初步推測：必須目前任期内，第一個日志寫入到大多數節點。此時說明
這個位置坐穩了。
動手驗證日志複制
這裡假設2個規則 ，
在最後一條日志中（不一定是安全的），不能比我的小，
不然就❌。
大家可以看到，s2 在成為leader後,term=5,和term=4還有資料沒有同步安全。
此時資料特點是：index=8的日志 和新增 index =9的日志。
任期5内日志，同步到其他節點 s1,s4 節點s5（s3 crash）
s1，s4，s5 其中 index =8 和index =9 日志是一塊 “ack” 安全寫入成功。
的。s2最後做統計，安全寫入成功。
大家可以看出：這裡有關鍵地方。
用戶端 沒有請求 和有請求
為什麼新的選舉後，結果是不一樣的？
這個觀察很重要!!!
隐藏了一個主要規則
上面隻是保證了，内部一緻性，與用戶端關系如何呢？
這裡講述各種故障場景。
當新的 Leader 上任後，日志可能不會非常幹淨，因為前一任上司可能在完成日志複制之前就當機了。Raft 對此的處理方式是：無需采取任何特殊處理。
當新 Leader 上任後，他不會立即進行任何清理操作，他将會在正常運作期間進行清理。
原因是當一個新的 Leader 上任時，往往意味着有機器故障了，那些機器可能當機或網絡不通，是以沒有辦法立即清理他們的日志。在機器恢複運作之前，我們必須保證系統正常運作。
大前提是 Raft 假設了 Leader 的日志始終是對的。是以 Leader 要做的是，随着時間推移，讓所有 Follower 的日志最終都與其比對。
來源：https://my.oschina.net/tantexian/blog/2876308
6. 資料到達 Leader 節點，成功複制到 Follower 所有或多數節點，資料在所有節點都處于已送出狀态，但還未響應 Client
這個階段 Leader 挂掉，Cluster 内部資料其實已經是一緻的，Client 重複重試基于幂等政策對一緻性無影響。
3 資料到達 Leader 節點，成功複制到 Follower 所有節點，但還未向 Leader 響應接收
這個階段 Leader 挂掉，雖然資料在 Follower 節點處于未送出狀态（Uncommitted）但保持一緻，重新選出 Leader 後可完成資料送出，此時 Client 由于不知到底送出成功沒有，可重試送出。
針對這種情況 Raft 要求 RPC 請求實作幂等性，也就是要實作内部去重機制。
1.RequestVote RPC 是appid記錄，不是commitid記錄。
2. 最終v3寫入其他節點
3. 如果用戶端請求 自己構造一個，然後同步。
一句話：leader不會自己撤銷已經寫入的log。
用戶端看到失敗，也不會撤銷。
資料到達 Leader 節點，成功複制到 Follower 部分節點，但還未向 Leader 響應接收
這個階段 Leader 挂掉，資料在 Follower 節點處于未送出狀态（Uncommitted）且不一緻，Raft 協定要求投票隻能投給擁有最新資料的節點。是以擁有最新資料的節點會被選為 Leader 再強制同步資料到 Follower，資料不會丢失并最終一緻。
（這裡假設最新的被選舉，也可能不是）
大家可以看到，在沒有網絡分區情況下，對用戶端沒有傳回成功，
目前資料在内部：
無論follwer 部分成功寫入，全部成功寫入，全部确認成功情況下，全部确認成功。都能保證内部的一緻性。【是否重複不保證】
用戶端假如逾時：在伺服器内部 可能多個情況。有可能寫入成功
有可能寫入不成功。但是内部是資料一緻的。
還剩下最重要一個情況，也是本章的問題
7. 網絡分區導緻的腦裂情況，出現雙 Leader
網絡分區将原先的 Leader 節點和 Follower 節點分隔開，Follower 收不到 Leader 的心跳将發起選舉産生新的 Leader。
這時就産生了雙 Leader，原先的 Leader 獨自在一個區，向它送出資料不可能複制到多數節點是以永遠送出不成功。
向新的 Leader 送出資料可以送出成功，網絡恢複後舊的 Leader 發現叢集中有更新任期（Term）的新 Leader 則自動降級為 Follower 并從新 Leader 處同步資料達成叢集資料一緻。
綜上窮舉分析了最小叢集（3 節點）面臨的所有情況，可以看出 Raft 協定都能很好的應對一緻性問題，并且很容易了解。
打住 ，到這裡還沒有結束。
回到題目開始，假如是通過一個機房，上面2個節點分區了，其他都正常。
仔細觀察 上面拓撲結構特點
這裡有概念
星型拓撲圖#
優點：
- 節點擴充，移動友善
- 網絡傳輸速度快
- 維護容易
缺點：
- 核心交換機工作負荷重
- 網絡布線複雜
- 廣播傳輸影響性能
網狀拓撲結構
主幹網，廣域網搭建
全網狀拓撲圖
容錯能力強
成本高
怎麼有點p2p的味道。
https://www.cnblogs.com/mindwind/p/5231986.html
更多問題：
https://www.zhihu.com/question/357207584