探索ElasticSearch-ElasticSearch集羣的工做原理（七）

前言

ElasticSearch爲咱們提供了開箱即用的特性。咱們不用去關心底層的細節也可以正常使用ElasticSearch來爲咱們服務。可是，若是要深刻理解ElasticSearch僅僅在淺層次的使用層面確定是遠遠不夠的。若是，你不單單知足於簡單使用ElasticSearch，那麼推薦你繼續往下面閱讀。

經過本文，你將會解答下面這幾個問題。

• 新的ElasticSearch是如何加入集羣的？
• ElasticSearch集羣是如何判斷節點是否存活的？
• 文檔是如何分發到某一個分片上面的？

ElasticSearch集羣工做原理

節點的發現

當網絡中已經存在了一個ElaticSearch的集羣時，啓動了一個新的ElasticSearch的節點，那麼此節點會自動加入到該ElasticSearch的集羣中。那麼，到底這個節點是怎麼加入到集羣的呢？

舉個例子。如今網絡中存在一個master節點和一個data節點的集羣，那麼當網絡中再次啓動一個ElasticSearch的節點時，會發生什麼呢？以下圖所示。

新啓動的ElasticSearch會進行一個多播的操做。該節點會向全部在網絡中的機器都發送一個ping的請求。可能大部分狀況下，該機器都不是ElasticSearch的機器，此時沒有相應返回。可是，當發送請求到ElasticSearch的master節點上面時，會返回相關的響應。一但判斷新的ElasticSearch的集羣名稱是相同的時候，master節點會記錄該節點所在的機器，執行相關的數據轉移。以後該節點將成爲了ElasticSearch集羣的一個新的節點。

節點的探活

上面探討的是新的ElasticSearch節點加入時，集羣工做的原理。那麼若是正常工做的集羣中，有節點出現宕機行爲呢？ElasticSearch的集羣是怎麼感知到有節點宕機，剔除損壞的節點，並且進行數據的轉移的呢？

仍是上面這個例子，這個時候已經有三個ElasticSearch的節點了。以下圖所示。

由於要保證集羣的正常工做，因此master節點會按期進行探活工做。具體爲每隔一段時間就去ping其餘已知的ElaticSearch的節點。

若是這個時候，有一個節點宕機了，那麼master節點將沒有辦法收到響應。此時，master節點將會將原來的副本分片提高爲主分片。將整個集羣設置爲Yellow狀態。表示已經有部分數據丟失，可是當前集羣仍是存在所有的數據，繼續提供搜索服務，可是不保證集羣的性能等指標。

文檔的分發

那麼當索引一個新的文檔時，ElasticSearch是怎麼將該文檔分發的呢？

仍是上面那個例子。集羣中有三個節點，並且一個索引的三個分片均勻分佈在三個節點上面。此時要索引一個id爲2的新文檔，那麼會被路由分發到那個節點上面呢？

其實文檔的分佈遵循這下面這個公式。

shard_num = hash(_routing) % num_primary_shards
複製代碼

那咱們假設上面新文檔進行hash以後，仍然是2，那麼最後會落到shard爲2的分片上面，以下圖所示。

小結

節點的發現上面討論是默認的狀況下，其實ElasticSearch中能夠配置不少其餘的發現策略。文檔的分發也能夠經過_routing字段來制定使用哪個值來做爲hash函數的入參。這些，下次講解下。

關於寫做

之後這裏天天都會寫一篇文章，題材不限，內容不限，字數不限。儘可能把本身天天的思考都放入其中。

若是這篇文章給你帶來了一些幫助，能夠動動手指點個贊，順便關注一波就更好了。

若是上面都沒有，那麼寫下讀完以後最想說的話？有效的反饋和你的鼓勵是對我最大的幫助。

另外打算把博客給從新撿起來了。歡迎你們來訪問吃西瓜。

我是shane。今天是2019年9月8日。百天寫做計劃的第四十六天，46/100。