es 的集群搭建不需要依賴第三方協調管理元件，自身內部就實現了集群的管理功能。
es 集群由乙個或多個 elasticsearch 節點組成，每個節點配置相同的 cluster.name 即可加入集群，預設值為 「elasticsearch」。
確保不同的環境中使用不同的集群名稱，否則最終會導致節點加入錯誤的集群。
乙個 elasticsearch 服務啟動例項就是乙個節點（node）。節點通過 node.name 來設定節點名稱，如果不設定則在啟動時給節點分配乙個隨機通用唯一識別符號作為名稱。
①發現機制
那麼有乙個問題，es 內部是如何通過乙個相同的設定 cluster.name 就能將不同的節點連線到同乙個集群的？答案是 zen discovery。
zen discovery 是 elasticsearch 的內建預設發現模組（發現模組的職責是發現集群中的節點以及選舉 master 節點）。
它提供單播和基於檔案的發現，並且可以擴充套件為通過外掛程式支援雲環境和其他形式的發現。
zen discovery 與其他模組整合，例如，節點之間的所有通訊都使用 transport 模組完成。節點使用發現機制通過 ping 的方式查詢其他節點。
elasticsearch 預設被配置為使用單播發現，以防止節點無意中加入集群。只有在同一臺機器上執行的節點才會自動組成集群。
如果集群的節點執行在不同的機器上，使用單播，你可以為 elasticsearch 提供一些它應該去嘗試連線的節點列表。
當乙個節點聯絡到單播列表中的成員時，它就會得到整個集群所有節點的狀態，然後它會聯絡 master 節點，並加入集群。
這意味著單播列表不需要包含集群中的所有節點， 它只是需要足夠的節點，當乙個新節點聯絡上其中乙個並且說上話就可以了。
如果你使用 master 候選節點作為單播列表，你只要列出三個就可以了。這個配置在 elasticsearch.yml 檔案中：
節點啟動後先 ping ，如果 discovery.zen.ping.unicast.hosts 有設定，則 ping 設定中的 host ，否則嘗試 ping localhost 的幾個埠。
elasticsearch 支援同乙個主機啟動多個節點，ping 的 response 會包含該節點的基本資訊以及該節點認為的 master 節點。
選舉開始，先從各節點認為的 master 中選，規則很簡單，按照 id 的字典序排序，取第乙個。如果各節點都沒有認為的 master ，則從所有節點中選擇，規則同上。
這裡有個限制條件就是 discovery.zen.minimum_master_nodes ，如果節點數達不到最小值的限制，則迴圈上述過程，直到節點數足夠可以開始選舉。
最後選舉結果是肯定能選舉出乙個 master ，如果只有乙個 local 節點那就選出的是自己。
如果當前節點是 master ，則開始等待節點數達到 discovery.zen.minimum_master_nodes，然後提供服務。
如果當前節點不是 master ，則嘗試加入 master 。elasticsearch 將以上服務發現以及選主的流程叫做 zen discovery 。
由於它支援任意數目的集群（ 1- n ），所以不能像 zookeeper 那樣限制節點必須是奇數，也就無法用投票的機制來選主，而是通過乙個規則。
只要所有的節點都遵循同樣的規則，得到的資訊都是對等的，選出來的主節點肯定是一致的。
但分布式系統的問題就出在資訊不對等的情況，這時候很容易出現腦裂（split-brain）的問題。
大多數解決方案就是設定乙個 quorum 值，要求可用節點必須大於 quorum（一般是超過半數節點），才能對外提供服務。
而 elasticsearch 中，這個 quorum 的配置就是 discovery.zen.minimum_master_nodes 。
②節點的角色
每個節點既可以是候選主節點也可以是資料節點，通過在配置檔案 …/config/elasticsearch.yml 中設定即可，預設都為 true。
node.master: true //是否候選主節點
node.data: true //是否資料節點
資料節點負責資料的儲存和相關的操作，例如對資料進行增、刪、改、查和聚合等操作，所以資料節點（data 節點）對機器配置要求比較高，對 cpu、記憶體和 i/o 的消耗很大。
通常隨著集群的擴大，需要增加更多的資料節點來提高效能和可用性。
候選主節點可以被選舉為主節點（master 節點），集群中只有候選主節點才有選舉權和被選舉權，其他節點不參與選舉的工作。
主節點負責建立索引、刪除索引、跟蹤哪些節點是群集的一部分，並決定哪些分片分配給相關的節點、追蹤集群中節點的狀態等，穩定的主節點對集群的健康是非常重要的。
乙個節點既可以是候選主節點也可以是資料節點，但是由於資料節點對 cpu、記憶體核 i/o 消耗都很大。
所以如果某個節點既是資料節點又是主節點，那麼可能會對主節點產生影響從而對整個集群的狀態產生影響。
因此為了提高集群的健康性，我們應該對 elasticsearch 集群中的節點做好角色上的劃分和隔離。可以使用幾個配置較低的機器群作為候選主節點群。
主節點和其他節點之間通過 ping 的方式互檢查，主節點負責 ping 所有其他節點，判斷是否有節點已經掛掉。其他節點也通過 ping 的方式判斷主節點是否處於可用狀態。
雖然對節點做了角色區分，但是使用者的請求可以發往任何乙個節點，並由該節點負責分發請求、收集結果等操作，而不需要主節點**。
這種節點可稱之為協調節點，協調節點是不需要指定和配置的，集群中的任何節點都可以充當協調節點的角色。
③腦裂現象
同時如果由於網路或其他原因導致集群中選舉出多個 master 節點，使得資料更新時出現不一致，這種現象稱之為腦裂，即集群中不同的節點對於 master 的選擇出現了分歧，出現了多個 master 競爭。
「腦裂」問題可能有以下幾個原因造成：
網路問題：集群間的網路延遲導致一些節點訪問不到 master，認為 master 掛掉了從而選舉出新的 master，並對 master 上的分片和副本標紅，分配新的主分片。
節點負載：主節點的角色既為 master 又為 data，訪問量較大時可能會導致 es 停止響應（假死狀態）造成大面積延遲，此時其他節點得不到主節點的響應認為主節點掛掉了，會重新選取主節點。
記憶體**：主節點的角色既為 master 又為 data，當 data 節點上的 es 程序占用的記憶體較大，引發 jvm 的大規模記憶體**，造成 es 程序失去響應。
為了避免腦裂現象的發生，我們可以從原因著手通過以下幾個方面來做出優化措施：
適當調大響應時間，減少誤判。通過引數 discovery.zen.ping_timeout 設定節點狀態的響應時間，預設為 3s，可以適當調大。
如果 master 在該響應時間的範圍內沒有做出響應應答，判斷該節點已經掛掉了。調大引數（如 6s，discovery.zen.ping_timeout:6），可適當減少誤判。
選舉觸發。我們需要在候選集群中的節點的配置檔案中設定引數 discovery.zen.munimum_master_nodes 的值。
這個引數表示在選舉主節點時需要參與選舉的候選主節點的節點數，預設值是 1，官方建議取值(master_eligibel_nodes/2)+1，其中 master_eligibel_nodes 為候選主節點的個數。
這樣做既能防止腦裂現象的發生，也能最大限度地提公升集群的高可用性，因為只要不少於 discovery.zen.munimum_master_nodes 個候選節點存活，選舉工作就能正常進行。
當小於這個值的時候，無法觸發選舉行為，集群無法使用，不會造成分片混亂的情況。
角色分離。即是上面我們提到的候選主節點和資料節點進行角色分離，這樣可以減輕主節點的負擔，防止主節點的假死狀態發生，減少對主節點「已死」的誤判。
08 es 進一步了解 b ES 核心概念
副本就是對分片的 copy，每個主分片都有乙個或多個副本分片，當主分片異常時，副本可以提供資料的查詢等操作。主分片和對應的副本分片是不會在同乙個節點上的，所以副本分片數的最大值是 n 1 其中 n 為節點數 對文件的新建 索引和刪除請求都是寫操作，必須在主分片上面完成之後才能被複製到相關的副本分片。...
08 es 進一步了解 b ES 核心概念
副本就是對分片的 copy，每個主分片都有乙個或多個副本分片，當主分片異常時，副本可以提供資料的查詢等操作。主分片和對應的副本分片是不會在同乙個節點上的，所以副本分片數的最大值是 n 1 其中 n 為節點數 對文件的新建 索引和刪除請求都是寫操作，必須在主分片上面完成之後才能被複製到相關的副本分片。...
進一步了解Makefile
mkdir p add src 一層一層建立目錄。touch add makefile 建立 makefile include 目錄中存放標頭檔案。scripts 存放指令碼檔案。存放方式 按照核心管理原始碼來管理。為什麼學習makefile？編譯大型專案 讀懂別人的開源 找到程式入口 看專案的順序...