分佈式
1、對複雜分佈式機制的透明隱藏特性
Elasticsearch是一套分佈式的系統，分佈式是爲了應對大數據量隱藏了複雜的分佈式機制
分片機制（我們之前隨隨便便就將一些document插入到es集羣中去了，我們有沒有care過數據怎麼進行分片的，數據到哪個shard中去）
cluster discovery（集羣發現機制，我們之前在做那個集羣status從yellow轉green的實驗裏，直接啓動了第二個es進程，那個進程作爲一個node自動就發現了集羣，並且加入了進去，還接受了部分數據，replica shard）
shard負載均衡（舉例，假設現在有3個節點，總共有25個shard要分配到3個節點上去，es會自動進行均勻分配，以保持每個節點的均衡的讀寫負載請求）
shard副本，請求路由，集羣擴容，shard重分配
shard&replica機制梳理
讀請求：primary/replica
（1）index包含多個shard
（2）每個shard都是一個最小工作單元，承載部分數據，lucene實例，完整的建立索引和處理請求的能力
（3）增減節點時，shard會自動在nodes中負載均衡
（4）primary shard和replica shard，每個document肯定只存在於某一個primary shard以及其對應的replica shard中，不可能存在於多個primary shard
（5）replica shard是primary shard的副本，負責容錯，以及承擔讀請求負載
（6）primary shard的數量在創建索引的時候就固定了，replica shard的數量可以隨時修改
（7）primary shard的默認數量是5，replica默認是1，默認有10個shard，5個primary shard，5個replica shard
（8）primary shard不能和自己的replica shard放在同一個節點上（否則節點宕機，primary shard和副本都丟失，起不到容錯的作用），但是可以和其他primary shard的replica shard放在同一個節點上
primary ---> replica同步
擴容機制：的垂直擴容與水平擴容
垂直擴容：採購更強大的服務器，成本非常高昂，而且會有瓶頸，假設世界上最強大的服務器容量就是10T，但是當你的總數據量達到5000T的時候，要採購多少臺最強大的服務器（不划算）
水平擴容：業界經常採用的方案，採購越來越多的普通服務器，性能比較一般，但是很多普通服務器組織在一起，就能構成強大的計算和存儲能力
擴容對應用程序的透明性
橫向擴容過程，如何超出擴容極限，以及如何提升容錯性：
（1）primary&replica自動負載均衡，6個shard，3 primary，3 replica
（2）每個node有更少的shard，IO/CPU/Memory資源給每個shard分配更多，每個shard性能更好
（3）擴容的極限，6個shard（3 primary，3 replica），最多擴容到6臺機器，每個shard可以佔用單臺服務器的所有資源，性能最好
（4）超出擴容極限，動態修改replica數量，9個shard（3primary，6 replica），擴容到9臺機器，比3臺機器時，擁有3倍的讀吞吐量
（5）3臺機器下，9個shard（3 primary，6 replica），資源更少，但是容錯性更好，最多容納2臺機器宕機，6個shard只能容納0臺機器宕機
（6）這裏的這些知識點，你綜合起來看，就是說，一方面告訴你擴容的原理，怎麼擴容，怎麼提升系統整體吞吐量；另一方面要考慮到系統的容錯性，怎麼保證提高容錯性，讓儘可能多的服務器宕機，保證數據不丟失
3、增減或減少節點時的數據rebalance
保持負載均衡
4、master節點
（1）創建或刪除索引
（2）增加或刪除節點
容錯機制：master選舉，replica容錯，數據恢復
（1）9 shard，3 node
（2）master node宕機，自動master選舉，red（短時）
（3）replica容錯：新master將replica提升爲primary shard，yellow
（4）重啓宕機node，master copy replica到該node，使用原有的shard並同步宕機後的修改，green
5、節點平等的分佈式架構
（1）節點對等，每個節點都能接收所有的請求
（2）自動請求路由
（3）響應收集
客戶請求與node
（1）客戶端選擇一個node發送請求過去，這個node就是coordinating node（協調節點）
（2）coordinating node，對document進行路由，將請求轉發給對應的node（有primary shard）
（3）實際的node上的primary shard處理請求，然後將數據同步到replica node
（4）coordinating node，如果發現primary node和所有replica node都搞定之後，就返回響應結果給客戶端
consistency參數與讀寫一致性：
（1）consistency，one（primary shard），all（all shard），quorum（default）
我們在發送任何一個增刪改操作的時候，比如說put /index/type/id，都可以帶上一個consistency參數，指明我們想要的寫一致性是什麼？
put /index/type/id?consistency=quorum
one：要求我們這個寫操作，只要有一個primary shard是active活躍可用的，就可以執行
all：要求我們這個寫操作，必須所有的primary shard和replica shard都是活躍的，纔可以執行這個寫操作
quorum：默認的值，要求所有的shard中，必須是大部分的shard都是活躍的，可用的，纔可以執行這個寫操作
（2）quorum機制，寫之前必須確保大多數shard都可用，int( (primary + number_of_replicas) / 2 ) + 1，當number_of_replicas>1時才生效
quroum = int( (primary + number_of_replicas) / 2 ) + 1
舉個例子，3個primary shard，number_of_replicas=1，總共有3 + 3 * 1 = 6個shard
quorum = int( (3 + 1) / 2 ) + 1 = 3
所以，要求6個shard中至少有3個shard是active狀態的，纔可以執行這個寫操作
（3）如果節點數少於quorum數量，可能導致quorum不齊全，進而導致無法執行任何寫操作
3個primary shard，replica=1，要求至少3個shard是active，3個shard按照之前學習的shard&replica機制，必須在不同的節點上，如果說只有2臺機器的話，是不是有可能出現說，3個shard都沒法分配齊全，此時就可能會出現寫操作無法執行的情況
es提供了一種特殊的處理場景，就是說當number_of_replicas>1時才生效，因爲假如說，你就一個primary shard，replica=1，此時就2個shard
(1 + 1 / 2) + 1 = 2，要求必須有2個shard是活躍的，但是可能就1個node，此時就1個shard是活躍的，如果你不特殊處理的話，導致我們的單節點集羣就無法工作
（4）quorum不齊全時，wait，默認1分鐘，timeout，100，30s
等待期間，期望活躍的shard數量可以增加，最後實在不行，就會timeout
我們其實可以在寫操作的時候，加一個timeout參數，比如說put /index/type/id?timeout=30，這個就是說自己去設定quorum不齊全的時候，es的timeout時長，可以縮短，也可以增長