一、ElasticSearch的容錯機制
以9個shard，3個節點為例：
1.如果master node 當機，此時不是所有的primary shard都是Active status，是以此時的叢集狀态是red。
容錯處理的第一步:是選舉一台伺服器作為master
容錯處理的第二步:新選舉出的master會把挂掉的primary shard的某個replica shard 提升為primary shard,此時叢集的狀态為yellow，因為少了一個replica shard，并不是所有的replica shard都是active status
容錯處理的第三步：重新開機故障機，新master會把所有的副本都複制一份到該節點上，（同步一下當機後發生的修改），此時叢集的狀态為green，因為所有的primary shard和replica shard都是Active status
二、改變文檔内容原了解析（Put是全部替換 post是部分替換）
三、文檔增删改内部原理
1:發送增删改請求時，可以選擇任意一個節點，該節點就成了協調節點(coordinating node)
2.協調節點使用路由算法進行路由，然後将請求轉到primary shard所在節點，該節點處理請求，并把資料同步到它的replica shard
3.協調節點對用戶端做出響應
四、文檔查詢内部原理
第一步：查詢請求發給任意一個節點，該節點就成了coordinating node，該節點使用路由算法算出文檔所在的primary shard
第二步：協調節點把請求轉發給primary shard也可以轉發給replica shard(使用輪詢排程算法(Round-Robin Scheduling，把請求平均配置設定至primary shard 和replica shard)
第三步：處理請求的節點把結果傳回給協調節點，協調節點再傳回給應用程式
特殊情況：請求的文檔還在建立索引的過程中，primary shard上存在，但replica shar上不存在，但是請求被轉發到了replica shard上，這時就會提示找不到文檔