ES讀數據的過程:
1.ES客戶端選擇一個node發送請求，該請求作為協調節點(coordinating node)；
2.corrdinating node 對 doc id 對哈希,找出該文檔對應所在的shards，將請求轉發到對應的node，
此時會使用round-robin 隨機輪詢算法，在primary shard 和 replica shard 之中選擇一個 ，實現讀請求的負載均衡；
3.接受請求的node 返回給document 給coordinate node；
4.coordinate node 返回document 給客戶端；
ES寫數據的過程:
1.ES客戶端選擇一個node發送請求，該請求作為協調節點(coordinating node)；
2.協調節點 對 doc id 對哈希,找出該文檔存放的primary shard，將請求轉發到該shard對應的節點；
3.節點收到請求，primary shard處理寫入，然后將數據同步到對應的replica shard 所在的節點；
4.協調節點 發現 主分片和副分片都寫入完成后 返回響應結果給 ES 客戶端；
ES搜索數據的過程:
1..ES客戶端選擇一個node發送請求，該請求作為協調節點(coordinating node)；
2. 協調節點將請求發送到所有的shard ，包括primary shard 或者是 replica shard
3. shard 將搜索到的數據 也就是doc id 返回給協調節點
4. 協調節點根據doc id ，將請求分發到doc id 對應的shard 去獲取完整的document ，然后將數據返回給ES 客戶端
ES寫數據的底層原理:
1.shard 收到寫入請求后，寫到內存buffer，同時寫入到translog((每個shard都對應一個translog文件)，注意內存buffer里面的數據是搜索不到的
2.shard 會每隔1秒執行refresh操作，將buffer內的數據刷到os cache級別的緩存中去(這里是文件系統緩存)，生成新的segement，buffer內的數據被刷到os cache中，
buffer被清空，此時，這個數據也能被搜索到了
3.重復1，2兩個步驟，數據會被寫入到一個一個的os cache 的 segment file 中去，並刷到磁盤中去，但是每次寫入，translog 會越來越大，到達一定長度將會觸發 commit 操作
commit 操作
將buffer內的現有數據refresh 到os cache中，清空buffer，然后將一個commit point 寫入到磁盤中，里面標識這個commit point對應的所有segment file
同時強行將os cache 里面的數據fsync到磁盤文件中去，最后清空現有的translog文件，重啟一個新的translog文件；
fsync+清空translog， 操作就是 flush，默認30分鍾執行一次flush，如果translog 文件過大(默認512M)也會觸發flush操作，flush
注意：os 文件系統中的translog的數據寫到磁盤中 translog文件中 fsync的操作默認每5s 執行一次；
參考:
https://blog.csdn.net/wang7075202/article/details/111308905
https://blog.csdn.net/lsgqjh/article/details/83022206
https://www.jianshu.com/p/15837be98ffd
https://blog.csdn.net/wx1528159409/article/details/105973336/
https://blog.csdn.net/u013129944/article/details/93720081
https://developer.51cto.com/art/202009/625293.htm