集羣擴容
Elasticsearch 可以隨時按需擴容。擴容的方式有水平擴容、垂直擴容。
- 水平擴容：添加更多的服務器，使集羣的負載能力更強
- 垂直擴容：替換性能更強的機器，使集羣的負載能力更強
顯然垂直擴容需要大量資金，並且有瓶頸。水平擴容更合適用來提升集羣的負載能力。
橫向擴容則需要分佈式技術來支持，對於大多數的數據庫而言，通常需要對應用程序進行非常大的改動，才能利用上橫向擴容的新增資源。而ElastiSearch天生就是 分佈式的 ，它知道如何通過管理多節點來提高集羣負載能力。
集羣通信
- Elasticsearch 中的集羣，無非就是一個或多個
cluster.name相同的節點，它們共同承擔數據和負載的壓力。當有節點加入集羣中或者從集羣中移除節點時，集羣將會重新平均分佈所有的數據。 - Elasticsearch 的集羣也有master節點，但是它只負責管理集羣範圍內的所有變更，例如增加、刪除索引，或者增加、刪除節點等。 而主節點並不需要涉及到文檔級別的變更和搜索等操作，所以當集羣只擁有一個主節點的情況下，即使流量的增加它也不會成爲瓶頸。
- 用戶的請求可以發送到集羣的任意節點中，每個節點都知道任意文檔所處的位置，通過文檔進行routing，能夠將我們的請求直接轉發到存儲我們所需文檔的節點。 無論我們將請求發送到哪個節點，它都能負責從這些節點收集回數據，並將最終結果返回給客戶端。
集羣狀態
可以通過GET /_cluster/healthAPI查看集羣的狀態：
{
"cluster_name" : "docker-cluster",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 4,
"active_shards" : 6,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
這裏主要關注status的值：
- green:所有的主分片和副本分片都正常運行。
- yellow:所有的主分片都正常運行，但不是所有的副本分片都正常運行。
- red:有主分片沒能正常運行。
shard 詳解
- 從客戶端看來，數據插入、查詢等操作都是基於 index 而言，index實際上是由一個或多個 shard 組成，而我們在查詢的時候並沒有關注數據應該去哪個 shard 查詢，這是因爲ES屏蔽掉了細節，這也是ES深受廣大程序員青睞的原因之一，簡單、易用。
- 而這一個個 shard 其實就是一個個Lucene實例。而我們在做數據插入時，存儲document數據的具體容器也是 shard。ES會將shards儘可能的均勻分配到集羣中的每個節點上。並且在集羣節點的動態增減後也同樣有效。
- shard 又分爲 primary shard 和 replace shard，前面所說的基本是 primary shard 的功能，也就是說某一個document 數據其實是放在某一個 primary shard 中的，而一個 primary shard 是有存儲上限（Integer.MAX_VALUE - 128）的，由此可以知道primary shard 數量能夠大致決定 index 的數據存儲上限。
- replace shard 的功能除了對其 primary shard 做數據備份以外，還能爲搜索API提供服務。
- primary shard 只能在新建 index 時設置，且不允許對已經存在的 index 做修改。
- replace shard 可以隨時修改。
- replace shard 不能和其備份的 primary shard 處於同一個節點，所以如果設置了 replace shard 數量，則集羣中至少需要倆個節點，否則replace shard 會分配失敗，ES存在數據丟失的風險。