摘要：前言分布式一致性原理剖析系列將會(huì)對(duì)的分布式一致性原理進(jìn)行詳細(xì)的剖析，介紹其實(shí)現(xiàn)方式原理以及其存在的問題等基于版本。中需要持久化的包括當(dāng)前版本號(hào)，每次更新加。收集不到足夠的，于是本次發(fā)布失敗，同時(shí)退出狀態(tài)。

前言
“Elasticsearch分布式一致性原理剖析”系列將會(huì)對(duì)Elasticsearch的分布式一致性原理進(jìn)行詳細(xì)的剖析，介紹其實(shí)現(xiàn)方式、原理以及其存在的問題等(基于6.2版本)。前一篇的內(nèi)容包括了ES的集群組成、節(jié)點(diǎn)發(fā)現(xiàn)與Master選舉、錯(cuò)誤檢測(cè)與集群擴(kuò)縮容等。本篇將在前一篇的基礎(chǔ)上，重點(diǎn)分析ES中meta更新的一致性問題，為了便于讀者理解 ，本文還介紹了Master管理集群的方式、meta組成、存儲(chǔ)方式等等。目錄如下：

Master如何管理集群

Meta組成、存儲(chǔ)和恢復(fù)

ClusterState的更新流程

如何解決當(dāng)前的一致性問題

小結(jié)

在上一篇文章中，我們介紹了ES集群的組成，如何發(fā)現(xiàn)節(jié)點(diǎn)，選舉Master等。那么在選舉出Master之后，Master如何管理集群呢？比如以下問題：

Master如何處理新建或刪除Index？

Master如何對(duì)Shard進(jìn)行重新調(diào)度，實(shí)現(xiàn)負(fù)載均衡？

既然要管理集群，那么Master節(jié)點(diǎn)必然需要以某種方式通知其他節(jié)點(diǎn)，從而讓其他節(jié)點(diǎn)執(zhí)行相應(yīng)的動(dòng)作，來完成某些事情。比如建立一個(gè)新的Index就需要將其Shard分配在某些節(jié)點(diǎn)上，在這些節(jié)點(diǎn)上需要?jiǎng)?chuàng)建出對(duì)應(yīng)Shard的目錄，并在內(nèi)存中創(chuàng)建對(duì)應(yīng)Shard的一些結(jié)構(gòu)等。

在ES中，Master節(jié)點(diǎn)是通過發(fā)布ClusterState來通知其他節(jié)點(diǎn)的。Master會(huì)將新的ClusterState發(fā)布給其他的所有節(jié)點(diǎn)，當(dāng)節(jié)點(diǎn)收到新的ClusterState后，會(huì)把新的ClusterState發(fā)給相關(guān)的各個(gè)模塊，各個(gè)模塊根據(jù)新的ClusterState判斷是否要做什么事情，比如創(chuàng)建Shard等。即這是一種通過Meta數(shù)據(jù)來驅(qū)動(dòng)各個(gè)模塊工作的方式。

在Master進(jìn)行Meta變更并通知所有節(jié)點(diǎn)的過程中，需要考慮Meta變更的一致性問題，假如這個(gè)過程中Master掛掉了，那么可能只有部分節(jié)點(diǎn)按照新的Meta執(zhí)行了操作。當(dāng)選舉出新的Master后，需要保證所有節(jié)點(diǎn)都要按照最新的Meta執(zhí)行操作，不能回退，因?yàn)橐呀?jīng)有節(jié)點(diǎn)按照新的Meta執(zhí)行操作了，再回退就會(huì)導(dǎo)致不一致。

ES中只要新Meta在一個(gè)節(jié)點(diǎn)上被commit，那么就會(huì)開始執(zhí)行相應(yīng)的操作。因此我們要保證一旦新Meta在某個(gè)節(jié)點(diǎn)上被commit，此后無論誰(shuí)是master，都要基于這個(gè)commit來產(chǎn)生更新的meta，否則就可能產(chǎn)生不一致。本文會(huì)分析ES處理這一問題的策略和存在的問題。

在介紹Meta更新流程前，我們先介紹一下ES中Meta的組成、存儲(chǔ)方式和恢復(fù)方式，不關(guān)心這部分內(nèi)容的讀者可以略過本節(jié)。

1. Meta：ClusterState、MetaData、IndexMetaData

Meta是用來描述數(shù)據(jù)的數(shù)據(jù)。在ES中，Index的mapping結(jié)構(gòu)、配置、持久化狀態(tài)等就屬于meta數(shù)據(jù)，集群的一些配置信息也屬于meta。這類meta數(shù)據(jù)非常重要，假如記錄某個(gè)index的meta數(shù)據(jù)丟失了，那么集群就認(rèn)為這個(gè)index不再存在了。ES中的meta數(shù)據(jù)只能由master進(jìn)行更新，master相當(dāng)于是集群的大腦。

ClusterState
集群中的每個(gè)節(jié)點(diǎn)都會(huì)在內(nèi)存中維護(hù)一個(gè)當(dāng)前的ClusterState，表示當(dāng)前集群的各種狀態(tài)。ClusterState中包含一個(gè)MetaData的結(jié)構(gòu)，MetaData中存儲(chǔ)的內(nèi)容更符合meta的特征，而且需要持久化的信息都在MetaData中，此外的一些變量可以認(rèn)為是一些臨時(shí)狀態(tài)，是集群運(yùn)行中動(dòng)態(tài)構(gòu)建出來的。

ClusterState內(nèi)容包括：
    long version: 當(dāng)前版本號(hào)，每次更新加1
    String stateUUID：該state對(duì)應(yīng)的唯一id
    RoutingTable routingTable：所有index的路由表
    DiscoveryNodes nodes：當(dāng)前集群節(jié)點(diǎn)
    MetaData metaData：集群的meta數(shù)據(jù)
    ClusterBlocks blocks：用于屏蔽某些操作
    ImmutableOpenMap customs: 自定義配置
    ClusterName clusterName：集群名

MetaData

上面提到，MetaData更符合meta的特征，而且需要持久化，那么我們看下這個(gè)MetaData中主要包含哪些東西：

MetaData中需要持久化的包括：
    String clusterUUID：集群的唯一id。
    long version：當(dāng)前版本號(hào)，每次更新加1
    Settings persistentSettings：持久化的集群設(shè)置
    ImmutableOpenMap indices: 所有Index的Meta
    ImmutableOpenMap templates：所有模版的Meta
    ImmutableOpenMap customs: 自定義配置

我們看到，MetaData主要是集群的一些配置，集群所有Index的Meta，所有Template的Meta。下面我們?cè)俜治鲆幌翴ndexMetaData，后面還會(huì)講到，雖然IndexMetaData也是MetaData的一部分，但是存儲(chǔ)上卻是分開存儲(chǔ)的。

IndexMetaData
IndexMetaData指具體某個(gè)Index的Meta，比如這個(gè)Index的shard數(shù)，replica數(shù)，mappings等。

IndexMetaData中需要持久化的包括：
    long version：當(dāng)前版本號(hào)，每次更新加1。
    int routingNumShards: 用于routing的shard數(shù), 只能是該Index的numberOfShards的倍數(shù)，用于split。
    State state: Index的狀態(tài), 是個(gè)enum，值是OPEN或CLOSE。
    Settings settings：numbersOfShards，numbersOfRepilicas等配置。
    ImmutableOpenMap mappings：Index的mapping
    ImmutableOpenMap customs：自定義配置。
    ImmutableOpenMap aliases： 別名
    long[] primaryTerms：primaryTerm在每次Shard切換Primary時(shí)加1，用于保序。
    ImmutableOpenIntMap> inSyncAllocationIds：處于InSync狀態(tài)的AllocationId，用于保證數(shù)據(jù)一致性，下一篇文章會(huì)介紹。

2. Meta的存儲(chǔ)

首先，在啟動(dòng)ES的一個(gè)節(jié)點(diǎn)時(shí)，會(huì)配置一個(gè)data目錄，例如下面這個(gè)目錄。該節(jié)點(diǎn)只有一個(gè)單shard的Index。

$tree
.
`-- nodes
    `-- 0
        |-- _state
        |   |-- global-1.st
        |   `-- node-0.st
        |-- indices
        |   `-- 2Scrm6nuQOOxUN2ewtrNJw
        |       |-- 0
        |       |   |-- _state
        |       |   |   `-- state-0.st
        |       |   |-- index
        |       |   |   |-- segments_1
        |       |   |   `-- write.lock
        |       |   `-- translog
        |       |       |-- translog-1.tlog
        |       |       `-- translog.ckp
        |       `-- _state
        |           `-- state-2.st
        `-- node.lock

我們看到，ES進(jìn)程會(huì)把Meta和Data都寫入這個(gè)目錄中，其中目錄名為_state的代表該目錄存儲(chǔ)的是meta文件，根據(jù)文件層級(jí)的不同，共有3種meta的存儲(chǔ)：

nodes/0/_state/:

這層目錄在節(jié)點(diǎn)級(jí)別，該目錄下的global-1.st文件存儲(chǔ)的是上文介紹的MetaData中除去IndexMetaData的部分，即一些集群級(jí)別的配置和templates。node-0.st中存儲(chǔ)的是NodeId。

nodes/0/indices/2Scrm6nuQOOxUN2ewtrNJw/_state/:

這層目錄在index級(jí)別，2Scrm6nuQOOxUN2ewtrNJw是IndexId，該目錄下的state-2.st文件存儲(chǔ)的是上文介紹的IndexMetaData。

nodes/0/indices/2Scrm6nuQOOxUN2ewtrNJw/0/_state/:

這層目錄在shard級(jí)別，該目錄下的state-0.st存儲(chǔ)的是ShardStateMetaData，包含是否是primary和allocationId等信息。ShardStateMetaData是在IndexShard模塊中管理，與其他Meta關(guān)聯(lián)不大，本文不做過多介紹。

可以看到，集群相關(guān)的MetaData和Index的MetaData是在不同的目錄中存儲(chǔ)的。另外，集群相關(guān)的Meta會(huì)在所有的MasterNode和DataNode上存儲(chǔ)，而Index的Meta會(huì)在所有的MasterNode和存儲(chǔ)了該Index數(shù)據(jù)的DataNode上存儲(chǔ)。

這里有個(gè)問題是，MetaData是由Master管理的，為什么DataNode上也要保存MetaData呢？主要原因是考慮到數(shù)據(jù)的安全性，很多用戶沒有考慮Master節(jié)點(diǎn)的高可用和數(shù)據(jù)高可靠，在部署ES集群時(shí)只配置了一個(gè)MasterNode，如果這個(gè)節(jié)點(diǎn)不可用，就會(huì)出現(xiàn)Meta丟失，后果非常嚴(yán)重。

3. Meta的恢復(fù)

假設(shè)ES集群重啟了，那么所有進(jìn)程都沒有了之前的Meta信息，需要有一個(gè)角色來恢復(fù)Meta，這個(gè)角色就是Master。所以ES集群需要先進(jìn)行Master選舉，選出Master后，才會(huì)進(jìn)行故障恢復(fù)。

當(dāng)Master選舉出來后，Master進(jìn)程還會(huì)等待一些條件，比如集群當(dāng)前的節(jié)點(diǎn)數(shù)大于某個(gè)數(shù)目等，這是避免有些DataNode還沒有連上來，造成不必要的數(shù)據(jù)恢復(fù)等。

當(dāng)Master進(jìn)程決定進(jìn)行恢復(fù)Meta時(shí)，它會(huì)向集群中的MasterNode和DataNode請(qǐng)求其機(jī)器上的MetaData。對(duì)于集群的Meta，選擇其中version最大的版本。對(duì)于每個(gè)Index的Meta，也選擇其中最大的版本。然后將集群的Meta和每個(gè)Index的Meta再組合起來，構(gòu)成當(dāng)前的最新Meta。

現(xiàn)在我們開始分析ClusterState的更新流程，并通過這個(gè)流程來看ES如何保證Meta更新的一致性。

1. master進(jìn)程內(nèi)不同線程更改ClusterState時(shí)的原子性保證

首先，master進(jìn)程內(nèi)不同線程更改ClusterState時(shí)要保證是原子的。試想一下這個(gè)場(chǎng)景，有兩個(gè)線程都在修改ClusterState，各自更改其中的一部分。假如沒有任何并發(fā)的保護(hù)，那么最后提交的線程可能就會(huì)覆蓋掉前一個(gè)線程的修改，或者產(chǎn)生不符合條件的狀態(tài)變更的發(fā)生。

ES解決這個(gè)問題的方式是，每次需要更新ClusterState時(shí)提交一個(gè)Task給MasterService，MasterService中只使用一個(gè)線程來串行處理這些Task，每次處理時(shí)把當(dāng)前的ClusterState作為Task中execute函數(shù)的參數(shù)。即保證了所有的Task都是在currentClusterState的基礎(chǔ)上進(jìn)行更改，然后不同的Task是串行執(zhí)行的。

2. ClusterState更改如何保證一旦commit，后續(xù)就一定會(huì)在此基礎(chǔ)上commit，不會(huì)回退

這里是為了解決這樣一個(gè)問題，我們知道，新的Meta一旦在某個(gè)節(jié)點(diǎn)上commit，那么這個(gè)節(jié)點(diǎn)就會(huì)執(zhí)行相應(yīng)的操作，比如刪除某個(gè)Shard等，這樣的操作是不可回退的。而假如此時(shí)Master節(jié)點(diǎn)掛掉了，新產(chǎn)生的Master一定要在新的Meta上進(jìn)行更改，不能出現(xiàn)回退，否則就會(huì)出現(xiàn)Meta回退了但是操作無法回退的情況。本質(zhì)上就是Meta更新沒有保證一致性。

早期的ES版本沒有解決這個(gè)問題，后來引入了兩階段提交的方式(Add two phased commit to Cluster State publishing)。所謂的兩階段提交，是把Master發(fā)布ClusterState分成兩步，第一步是向所有節(jié)點(diǎn)send最新的ClusterState，當(dāng)有超過半數(shù)的master節(jié)點(diǎn)返回ack時(shí)，再發(fā)送commit請(qǐng)求，要求節(jié)點(diǎn)commit接收到的ClusterState。如果沒有超過半數(shù)的節(jié)點(diǎn)返回ack，那么認(rèn)為本次發(fā)布失敗，同時(shí)退出master狀態(tài)，執(zhí)行rejoin重新加入集群。

兩階段提交可以解決部分一致性問題，比如以下這種場(chǎng)景：

NodeA本來是Master節(jié)點(diǎn)，但由于某些原因NodeB成了新的Master節(jié)點(diǎn)，而NodeA由于探測(cè)不及時(shí)還未發(fā)現(xiàn)。

NodeA認(rèn)為自己仍然是Master，于是照常發(fā)布新的ClusterState。

由于此時(shí)NodeB是Master，說明超過半數(shù)的Master節(jié)點(diǎn)認(rèn)為NodeB才是新的Master，于是超過半數(shù)的Master節(jié)點(diǎn)不會(huì)返回ack給NodeA。

NodeA收集不到足夠的ack，于是本次發(fā)布失敗，同時(shí)退出master狀態(tài)。

新的ClusterState不會(huì)在任何節(jié)點(diǎn)上commit，于是沒有不一致發(fā)生。

但是這種方式也存在很多一致性的問題，我們下一節(jié)來具體分析。

3. 一致性問題分析

ES中，Master發(fā)送commit的原則是只要有超過半數(shù)MasterNode(master-eligible node)接收了新的ClusterState就發(fā)送commit。那么實(shí)際上就是認(rèn)為只要超過半數(shù)節(jié)點(diǎn)接收了新的ClusterState，這個(gè)ClusterState就一定可以被commit，不會(huì)在各種場(chǎng)景下回退。

問題1

第一階段master節(jié)點(diǎn)send新的ClusterState，接收到的節(jié)點(diǎn)只是把新的ClusterState放入內(nèi)存一個(gè)隊(duì)列中，就會(huì)返回ack。這個(gè)過程沒有持久化，所以當(dāng)master接收到超過半數(shù)的ack后，也不能認(rèn)為這些節(jié)點(diǎn)上都有新的ClusterState了。

問題2

如果master在commit階段，只commit了少數(shù)幾個(gè)節(jié)點(diǎn)就出現(xiàn)了網(wǎng)絡(luò)分區(qū)，將master與這幾個(gè)少數(shù)節(jié)點(diǎn)分在了一起，其他節(jié)點(diǎn)可以互相訪問。此時(shí)其他節(jié)點(diǎn)構(gòu)成多數(shù)派，會(huì)選舉出新的master，由于這部分節(jié)點(diǎn)中沒有任何節(jié)點(diǎn)commit了新的ClusterState，所以新的master仍會(huì)使用更新前的ClusterState，造成Meta不一致。

ES官方仍在追蹤這個(gè)bug：

https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html

Repeated network partitions can cause cluster state updates to be lost (STATUS: ONGOING)
...This problem is mostly fixed by #20384 (v5.0.0), which takes committed cluster state updates into account during master election. This considerably reduces the chance of this rare problem occurring but does not fully mitigate it. If the second partition happens concurrently with a cluster state update and blocks the cluster state commit message from reaching a majority of nodes, it may be that the in flight update will be lost. If the now-isolated master can still acknowledge the cluster state update to the client this will amount to the loss of an acknowledged change. Fixing that last scenario needs considerable work. We are currently working on it but have no ETA yet.

什么情況下會(huì)有問題
在兩階段提交中，很重要的一個(gè)條件是，“超過半數(shù)節(jié)點(diǎn)返回ack，表示接收了這個(gè)ClusterState”，這個(gè)條件并不能帶來任何保證。一方面接收ClusterState并不會(huì)持久化，另一方面接收了ClusterState也不會(huì)對(duì)未來選舉新Master產(chǎn)生任何干擾，因?yàn)檫x舉時(shí)只考慮已經(jīng)commit的ClusterState。

在兩階段過程中，只到Master在超過半數(shù)MasterNode(master-eligible node)上commit了新的ClusterState，并且這些節(jié)點(diǎn)都完成了新ClusterState的持久化時(shí)，才到達(dá)一個(gè)安全的狀態(tài)。在開始commit到達(dá)到這個(gè)狀態(tài)之間，如果Master發(fā)送故障，就可能導(dǎo)致Meta發(fā)生不一致。

既然ES目前Meta更新存在一些一致性問題，那么我們來腦洞一下，如何解決這些一致性問題呢？

1. 實(shí)現(xiàn)一個(gè)標(biāo)準(zhǔn)的一致性算法，比如raft
第一種方式是實(shí)現(xiàn)一個(gè)標(biāo)準(zhǔn)的一致性算法，比如raft。在上一篇中，我們也比較了ES的選舉算法與raft算法的異同，下面我們繼續(xù)比較一下ES的meta更新流程與raft的日志復(fù)制流程。

相同點(diǎn)：

都是在得到超過半數(shù)節(jié)點(diǎn)應(yīng)答之后，執(zhí)行commit。
不同點(diǎn)：

raft算法中，follower接收到日志后就會(huì)進(jìn)行持久化，寫到磁盤上。ES中，節(jié)點(diǎn)接收到ClusterState只是放到內(nèi)存中的一個(gè)隊(duì)列中即返回，并不持久化。

raft算法可以保證在超過半數(shù)節(jié)點(diǎn)應(yīng)答之后，這條日志一定可以被commit，而ES中沒有保證這一點(diǎn)，目前還存在一致性問題。

通過上面的比較，我們?cè)俅慰吹?，ES中meta更新的算法與raft相比很相似，raft使用了更多的機(jī)制來保證一致性，而ES還存在一些問題。用ES官方的話來說，fix這些問題還需要大量的工作(considerable work)。

2. 借助額外的組件保證meta一致性
比如使用Zookeeper來保存Meta，用Zookeeper來保證Meta的一致性。這樣可以解決一致性的問題，但是性能的問題還需要再評(píng)估一下，比如Meta是否會(huì)過大而導(dǎo)致不保存在Zookeeper中，每次請(qǐng)求全量Meta還是Diff等。

3. 使用共享存儲(chǔ)來保存Meta
首先保證不會(huì)出現(xiàn)腦裂，然后可以使用共享存儲(chǔ)來保存Meta，解決Meta一致性的問題。這種方式會(huì)引入一個(gè)共享存儲(chǔ)，這個(gè)存儲(chǔ)系統(tǒng)需要具備高可靠、高可用特征。

作為Elasticsearch分布式一致性原理系列的第二篇，本文主要介紹了ES集群中Master節(jié)點(diǎn)發(fā)布Meta更新的流程，分析了其中的一致性問題。此外還介紹了Meta數(shù)據(jù)的組成和存儲(chǔ)方式等。下一篇文章會(huì)分析ES中如何保證數(shù)據(jù)的一致性，介紹其寫入流程和算法模型等。

詳情請(qǐng)閱讀原文