兩地三中心，如何部署奇數個節點？
文末本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗。轉載本文請聯系小姐姐味道公眾號。
兩地三中心，是有錢的公司，為保障數據安全和高可用，一個常見的需求，通常指的是 “同城雙活，異地備份”。
2 + 1 = 3，從描述上來看，就知道它們之間是有階級屬性的。
異地備份的機房，level上自然就比同城雙活的兩個機房低了一個檔次，否則也不會淪為備胎。辯證的看待這個問題，我們就能夠自如的處理感情上腳踏多只船的問題。
1. 部署結構
為了描述方便，我們把同城的兩個機房，稱為A和B。把可憐的備份機房，稱作機房C。
同城的兩個機房，距離上自然就近了一些。我們可以用圖直觀的表示一下這個距離差異。
所以這個備份機房，非常的沒有存在感。實際上，它也非常的有自知之明，只把自己放在一個備份的場景，能夠接受非常大的請求延遲和比較長的數據不一致窗口。
這么算下來，就只剩下A和B兩位陪你玩了，此之為雙活。
2. 奇數節點的意義
雙活的意思，是兩個機房要同時對外提供服務。運行在不同機房的服務，分為兩種，一種是有狀態的，一種是無狀態的。
無狀態的服務，由于自身并不存儲數據，只是作為傳話筒，處理上自然行云流水，沒什么值得好討論的。
難搞的是有狀態的服務。即使它像魚一樣記憶只有5秒，這部分記憶依然會對整個系統提出了高標準的要求------
我們需要有個集中的地方來存儲這些數據。
大家都是搞技術的，那就舉例幾個常見的組件。
Zookeeper動物園，需要做集中的配置中心或者分布式協調工作
Redis Cluster需要處理一些全局的緩存數據
ElasticSearch進行數據存儲
無數個案例告訴我們，要部署這些服務，得部署奇數個節點才行。為什么不能部署偶數個?因為有個腦殘的問題，那就是腦裂。
我們拿Zookeeper來說，假如我們部署了6個節點，那么你要兩個集群能夠可用，需要至少4個存活才行。你要是設置成了3個，那它就會出現問題。
如下圖，在6個節點的場景中，A和B機房網絡產生了閃斷。A機房的三個節點發現不能再連接B機房的節點，于是它們三個自己組個集群，并寫入了 a = 100, b = 300兩條數據;同理，B機房也組了個局，寫入了a = 100， b = 600兩條記錄。
而且它們都寫成功了。
一個集群變成了兩個，并寫入了不同的數據。那我到底以誰的數據為準呢?真是要了命。
這就是腦裂問題，我們不能把集群要求的最小節點設置成3，而是起碼要為4。
所以你看不管是ES還是raft協議，不管是paxos和zab，都推薦部署奇數個節點，然后把最小可用集群節點設置成 (n / 2 + 1) --- 此所謂有一半以上節點投票才成，且有更好的容錯性。
3. 如何部署奇數個節點
那這個問題該如何解決呢?
假如是同城三活，那么我們只需要在每個機房部署一個節點就可以了。但即使是雙活，都是公司非常有錢才能搞得起。現在搞個三活，你大概率會贏得老板一個心虛的白眼。
當然也可以采用 2 + 2 + 1的模式。
找不到一個專用的機房部署一套集群，但找幾個第三方的服務器，部署一下我們的幾個服務節點倒是可以的。
聽起來很美好，但實際上不會這么做。因為這批第三方的服務器，對帶寬、延遲 、安全、穩定的要求，一點都不低。
還是老老實實的在兩個中心玩吧，野花野草聞著香，但大概率有毒。
實際上，即使是姐妹花，A和B總是有些差異。只要我們別把A和B看的太對等，問題就好處理。
如上圖，在A機房部署3個節點，在B機房部署2個節點。只要你這么部署了，在你的腦子里，A就是要B的level高一些，雖然你對外宣稱它們是一樣的。
就像你腳踏兩只船，你和2人說都很愛ta。但一旦ta倆有沖突，你還是會毫不猶豫的選一個。
這就是考驗。
我們切回上圖，看一下幾種情況。在這種部署情況下，當發生腦裂，B機房的2個節點是無法提供服務的，所以也不會有異常數據進入。
當B機房整個發生問題，A機房還是能夠正常運行。
當A機房整個發生問題，B機房此時只有2個節點，不滿足最小的3個節點。這個時候該怎么辦呢?
沒錯，我們手動啟動一個。你看節點6的邊框是虛線的，也就意味著它是一個待命狀態，隨時待命轉正，完全的接管A的工作。
代價也是有的，畢竟A才是你心中的No.1。ta離你而去，給你造成了困擾。自己的選擇，就是含著淚，你也得把B給頂上去。
相信我，不過是小時段的陣痛，你很快會再次進入雙活的世界。到時候你是把B當作No.1，還是繼續換回A，都沒有問題。
而且這選擇很沒意義。
比起誰的level高，你想要雙活的根本原因，那就是誰都不相信。所以，就把未來交給薛定諤的貓吧----
誰讓你是個多情又多疑的程序員呢。
作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。
