AZ概念

AZ(可用區，Availability Zone)這個是AWS發明的概念，AWS引入可用區設計主要是為了提升用戶應用程序的高可用性。因為可用區與可用區之間在設計上是相互獨立的，也就是說它們會有獨立的供電、獨立的網絡等，這樣假如一個可用區出現問題時也不會影響另外的可用區。在一個區域內，可用區與可用區之間是通過高速網絡連接，從而保證有很低的延時。

ES腦裂問題

說完可用區，再來看看ES(Elastic Search)主動選舉機制：

elasticsearch集群一旦建立起來以后，會選舉出一個master，其他都為slave節點。但是具體操作的時候，每個節點都提供寫和讀的操作。就是說，你不論往哪個節點中做寫操作，這個數據也會分配到集群上的所有節點中。

這里有某個節點掛掉的情況，如果是slave節點掛掉了，那么首先關心，數據會不會丟呢?不會。如果你開啟了replicate，那么這個數據一定在別的機器上是有備份的。別的節點上的備份分片會自動升格為這份分片數據的主分片。這里要注意的是這里會有一小段時間的yellow狀態時間。

如果是主節點掛掉怎么辦呢?當從節點們發現和主節點連接不上了，那么他們會自己決定再選舉出一個節點為主節點。但是這里有個腦裂的問題，假設有5臺機器，3臺在一個機房，2臺在另一個機房，當兩個機房之間的聯系斷了之后，每個機房的節點會自己聚會，推舉出一個主節點。這個時候就有兩個主節點存在了，當機房之間的聯系恢復了之后，這個時候就會出現數據沖突了。

解決的辦法就是設置參數：

discovery.zen.minimum_master_nodes 

為3(超過一半的節點數)，那么當兩個機房的連接斷了之后，就會以大于等于3的機房的master為主，另外一個機房的節點就停止服務了。

AZ可用 + 腦裂放一塊怎么辦?

其實很難辦，為了做到不腦裂，就要設置最小可用節點要超過整個集群的一半。但是同樣，但是這樣做同樣，AZ通信斷了或者掛了一個AZ，整個服務可能節點數就不到集群的一半，服務就無法使用了，好像AZ的可靠性就沒有起到作用。

AWS是怎么弄的?

看AWS的開發文檔里面有如下說明：

每個 AWS 區域都是一個獨立的地理區域，其中包含多個相互隔離的位置，這些位置稱為可用區。為避免數據損失，并***限度地減少節點和數據中心故障時導致的停機時間，您可以使用 Amazon ES 控制臺，在同一區域的兩個可用區之間，分配屬于 Elasticsearch 群集的節點和副本索引分片。此分配稱為區域感知。如果啟用區域感知，則您還必須使用本機 Elasticsearch API 為您的群集創建副本分片。Amazon ES 在可用區的各節點之間分配副本，這會增加您的群集的可用性。為群集啟用區域感知會略微增加網絡延遲。

Important

區域感知要求實例數量為偶數。所有索引的默認配置均為副本數量等于 1。如果您為一個索引指定。副本數量等于 0，則區域感知不復制分片到第二個可用區。如果沒有副本分片，則無需將副本分發。到第二個可用區，啟用該功能不提供數據損失保護。

下圖顯示了啟用區域感知的四節點群集。該服務將所有主索引分片放在一個可用區中，將所有副本分片放在第二個可用區中。

不難看出來，AWS并沒有解決這個問題，而是做了一個取舍，要求兩個AZ節點數都為偶數，更多的是為了AZ之間更好的數據均衡。

【本文為51CTO專欄作者“大數據和云計算”的原創稿件，轉載請通過微信公眾號獲取聯系和授權】

戳這里，看該作者更多好文