elasticsearch用於構建高可用和可擴展的系統。擴展的方式可以是購買更好的服務器(縱向擴展)或者購買更多的服務器（橫向擴展）,Elasticsearch能從更強大的硬件中獲得更好的性能，但是縱向擴展也有一定的侷限性。真正的擴展應該是橫向的，它通過增加節點來傳播負載和增加可靠性。對於大多數數據庫而言，橫向擴展意味着你的程序將做非常大的改動來利用這些新添加的設備。對比來說，Elasticsearch天生是分佈式的：它知道如何管理節點來提供高擴展和高可用。這意味着你的程序不需要關心這些。對於大多數數據庫而言，橫向擴展意味着你的程序將做非常大的改動來利用這些新添加的設備。對比來說，Elasticsearch天生是分佈式的：它知道如何管理節點來提供高擴展和高可用。這意味着你的程序不需要關心這些。
集羣和節點
節點(node)是你運行的Elasticsearch實例。一個集羣(cluster)是一組具有相同cluster.name的節點集合，他們協同工作，共享數據並提供故障轉移和擴展功能，當有新的節點加入或者刪除節點，集羣就會感知到並平衡數據。集羣中一個節點會被選舉爲主節點(master),它用來管理集羣中的一些變更，例如新建或刪除索引、增加或移除節點等;當然一個節點也可以組成一個集羣。
節點通信:
我們能夠與集羣中的任何節點通信，包括主節點。任何一個節點互相知道文檔存在於哪個節點上，它們可以轉發請求到我們需要數據所在的節點上。我們通信的節點負責收集各節點返回的數據，最後一起返回給客戶端。這一切都由Elasticsearch透明的管理。
分片與副本分片
分片用於Elasticsearch在你的集羣中分配數據。想象把分片當作數據的容器。文檔存儲在分片中，然後分片分配給你集羣中的節點上。
當你的集羣擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集羣保持平衡。
一個分片(shard)是一個最小級別的“工作單元(worker unit)”,它只是保存索引中所有數據的一小片.我們的文檔存儲和被索引在分片中，但是我們的程序不知道如何直接與它們通信。取而代之的是，他們直接與索引通信.Elasticsearch中的分片分爲主分片和副本分片,複製分片只是主分片的一個副本，它用於提供數據的冗餘副本，在硬件故障之後提供數據保護，同時服務於像搜索和檢索等只讀請求，主分片的數量和複製分片的數量都可以通過配置文件配置。但是主切片的數量只能在創建索引時定義且不能修改.相同的分片不會放在同一個節點上。
1)分片算法:
shard = hash(routing) % number_of_primary_shards
routing值是一個任意字符串，它默認是_id但也可以自定義，這個routing字符串通過哈希函數生成一個數字，然後除以主切片的數量得到一個餘數(remainder)，餘數的範圍永遠是0到number_of_primary_shards - 1，這個數字就是特定文檔所在的分片。
這也解釋了爲什麼主切片的數量只能在創建索引時定義且不能修改：如果主切片的數量在未來改變了，所有先前的路由值就失效了，文檔也就永遠找不到了。
所有的文檔API（get、index、delete、bulk、update、mget）都接收一個routing參數，它用來自定義文檔到分片的映射。自定義路由值可以確保所有相關文檔.比如用戶的文章,按照用戶賬號路由,就可以實現屬於同一用戶的文檔被保存在同一分片上。
2)分片和副本交互：
新建、索引和刪除請求都是寫(write)操作，它們必須在主分片上成功完成才能複製到相關的複製分片上,下面我們羅列在主分片和複製分片上成功新建、索引或刪除一個文檔必要的順序步驟：
1、客戶端給Node 1發送新建、索引或刪除請求。
2、節點使用文檔的_id確定文檔屬於分片0。它轉發請求到Node 3，分片0位於這個節點上。
3、Node 3在主分片上執行請求，如果成功，它轉發請求到相應的位於Node 1和Node 2的複製節點上。當所有的複製節點報告成功，Node 3報告成功到請求的節點，請求的節點再報告給客戶端。
客戶端接收到成功響應的時候，文檔的修改已經被應用於主分片和所有的複製分片。你的修改生效了。
3)副本分片複製時的相關的參數說明:
replication:
複製默認的值是sync。這將導致主分片得到複製分片的成功響應後才返回，如果你設置replication爲async，請求在主分片上被執行後就會返回給客戶端。它依舊會轉發請求給複製節點，但你將不知道複製節點成功與否。
默認的sync複製允許Elasticsearch強制反饋傳輸。async複製可能會因爲在不等待其它分片就緒的情況下發送過多的請求而使Elasticsearch過載。
consistency:
默認主分片在嘗試寫入時需要**規定數量(quorum)**或過半的分片（可以是主節點或複製節點）可用。這是防止數據被寫入到錯的網絡分區。規定的數量計算公式如下：
int( (primary + number_of_replicas) / 2 ) + 1
consistency允許的值爲one（只有一個主分片），all（所有主分片和複製分片）或者默認的quorum或過半分片。
注意number_of_replicas是在索引中的的設置，用來定義複製分片的數量，而不是現在活動的複製節點的數量。如果你定義了索引有3個複製節點，那規定數量是：int( (primary + 3 replicas) / 2 ) + 1 = 3
但如果你只有2個節點，那你的活動分片不夠規定數量，也就不能索引或刪除任何文檔。
注意: 新索引默認有1個複製分片，這意味着爲了滿足quorum的要求**需要**兩個活動的分片。當然，這個默認設置將阻止我們在單一節點集羣中進行操作。爲了避開這個問題，規定數量只有在number_of_replicas大於一時才生效。
timeout：
當分片副本不足時Elasticsearch會等待更多的分片出現。默認等待一分鐘。如果需要，你可以設置timeout參數讓它終止的更早：100表示100毫秒，30s表示30秒。
集羣生態:
1.同集羣中節點之間可以擴容縮容,
2.主分片的數量會在其索引創建完成後修正，但是副本分片的數量會隨時變化。
3.相同的分片不會放在同一個節點上.
集羣健康:
在Elasticsearch集羣中可以監控統計很多信息，但是隻有一個是最重要的時集羣健康(cluster health)。Es中用三種顏色狀態表示:green，yellow，red.
Green：所有主分片和副本分片都可用
Yellow：所有主分片可用，但不是所有副本分片都可用
Red：不是所有的主分片都可用；
1、創建單集羣節點
如圖我們的單點集羣:
實例中我們創建一個索引dobbyindex.一個索引默認指派5個主分片,實例中我們設定4個主分片和2個複製分片（每個主分片有2個複製分片對應）：
PUT /dobbyindex
{
"settings": {
"number_of_shards": 4,
"number_of_replicas": 2
}
}
創建後索引如圖:
在節點es-node1中片的存放如下:
我們的主分片都被分配到了es-node1.但是我們的8個複製分片還沒有被分配到節點上, 此時的集羣健康狀況如下:
cluster health: yellow (4 of 12)
對應的詳細信息爲:
View
Code意味着所有的主分片(primary shards)啓動並且運行了,集羣已經可以成功的接受任意請求,但是副本分片(replica shards)還沒有全部可用。
事實上所有的8個副本分片現在是unassigned（未分配）狀態,即它們還未被分配給節點,在同一個節點上保存相同的數據副本是沒有必要的，如果這個節點故障了，那所有的數據副本也會丟失。現在我們的集羣已經功能完備，但是依舊存在因硬件故障而導致的數據丟失的風險。
2.增加故障轉移
上面實例中的集羣有單點故障的風險,沒有數據冗餘備份。我們可以擴展節點來保護數據不被丟失.只要第二個節點與第一個節點有相同的cluster.name(實例中爲elasticsearch-cluster-centos)，它就能自動發現並加入第一個節點的集羣。
如果沒有，檢查日誌找出哪裏出了問題。這可能是網絡廣播被禁用，或者防火牆阻止了節點通信。
當我們啓動第二個節點之後:集羣中的分片結構圖如下:
雖然,已經有4個副本分片被分陪到es-node2節點上來了，但是按照我們定義的副本分片的值爲2, 還有4個分片處於未分片狀態,此時對於我們設定的參數來說,集羣的健康值還是所有主分片可用，但不是所有複製分片都可用. 對應的集羣健康狀況:
cluster health: yellow (8 of 12)
對應的詳細信息爲:
View
Code
所以我們還需要一個節點來分片這些副本分片,使集羣達到高可用,再增加集羣節點:
當我們啓動第三個節點之後,整個集羣上的分片都進行了有效分配,從圖中可以看出.es-node1爲這個集羣生態中選舉出來的主(master),es-node2和es-node3爲集羣生態中的slave(從). 這樣,一些新的被索引的文檔將首先被存儲在主分片中，然後平行復制到關聯的複製節點上。這可以確保我們的數據在主節點和複製節點上都可以被檢索。
此時集羣的健康狀態如下：
cluster health: green (12 of 12)
對應的詳細信息爲：
View
Code下圖爲,節點es-node3加入時,分片分配過程中截取的臨時圖.
3.模擬節點宕機,集羣主從重新選舉
上圖中我們的主節點爲es-node1,如果主節點宕掉後,會怎樣呢.
如圖:主節點對應的進程號7421,幹掉它，此時es集羣生態發生瞭如下變化,如圖:
es-node3被選舉爲主節點,es-node2爲從節點,主分片與副本分片也變化了,主分片放置在了es-node2上,副本分片放置到了es-node3上,因爲分片沒有完全被分配,所以集羣的健康狀態變爲yellow(所有主分片可用，但不是所有複製分片都可用),然後我們重啓es-node1節點.
如圖,重啓後健康狀態恢復到green,但是集羣主從變化了,且主分片的位置也變化了.
4.模擬擴展節點
實例2中我們的集羣已經達到高可用狀態,對應的索引分片如圖.此時我們想要擴展集羣繼續增加節點時,我們的分片會怎樣呢,接下來我們再增加一個擴展節點es-node4.
如圖:擴容後,可以看到片進行了重新分片,節點es-node1和es-node3上分別持有主分片。es-node2,es-node3,es-node4持有副本分片，由於筆者模擬過程中有主節點宕機操作,
所以從圖中可以看出,新的生態集羣中es-node4爲主節點.對應的各個集羣存儲中包含的片分佈信息如下:
這種狀態下的片也是完全分配，green(所有主要和複製的分片都可用).
5.動態縮小或者擴容副本片數量
副本節點的數量可以在運行中的集羣中動態的變更，這允許我們可以根據需求擴大或者縮小規模。
比如我們執行一次縮小規模操作:
PUT /dobbyindex/_settings
{
"number_of_replicas" : 1
}
執行結果返回:
{
"acknowledged": true
}
這時,我們看到片的信息分又重新做了調整: 主分片分佈在節點es-node1,es-node3,es-node4上.從分片分佈在es-node2,es-node3,es-node4上.
轉載 :[http://www.cnblogs.com/dennisit/p/4133131.html]
