一、Elasticsearch寫人數據的過程
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都搞定之后，就返回響應結果給客戶端
二、Elasticsearch讀取數據的過程
1）客戶端發送請求到任意一個node，成為coordinate node
2）coordinate node對document進行路由，將請求轉發到對應的node，此時會使用round-robin隨機輪詢算法，在primary shard以及其所有replica中隨機選擇一個，讓讀請求負載均衡
3）接收請求的node返回document給coordinate node
4）coordinate node返回document給客戶端
1.寫入document時，每個document會自動分配一個全局唯一的id即doc id，同時也是根據doc id進行hash路由到對應的primary shard上。也可以手動指定doc id，比如用訂單id，用戶id。
2.讀取document時，你可以通過doc id來查詢，然后會根據doc id進行hash，判斷出來當時把doc id分配到了哪個shard上面去，從那個shard去查詢
三、Elasticsearch搜索數據過程
es最強大的是做全文檢索
1）客戶端發送請求到一個coordinate node
2）協調節點將搜索請求轉發到所有的shard對應的primary shard或replica shard也可以
3）query phase：每個shard將自己的搜索結果（其實就是一些doc id），返回給協調節點，由協調節點進行數據的合並、排序、分頁等操作，產出最終結果
4）fetch phase：接着由協調節點，根據doc id去各個節點上拉取實際的document數據，最終返回給客戶端
搜索的底層原理：倒排索引
四、Elasticsearch寫數據的底層原理
1）先寫入buffer，在buffer里的時候數據是搜索不到的；同時將數據寫入translog日志文件。
2）如果buffer快滿了，或者到一定時間，就會將buffer數據refresh到一個新的segment file中，但是此時數據不是直接進入segment file的磁盤文件的，而是先進入os cache的。這個過程就是refresh。
每隔1秒鍾，es將buffer中的數據寫入一個新的segment file，每秒鍾會產生一個新的磁盤文件，segment file，這個segment file中就存儲最近1秒內buffer中寫入的數據。
但是如果buffer里面此時沒有數據，那當然不會執行refresh操作咯，每秒創建換一個空的segment file，如果buffer里面有數據，默認1秒鍾執行一次refresh操作，刷入一個新的segment file中。
操作系統里面，磁盤文件其實都有一個東西，叫做os cache，操作系統緩存，就是說數據寫入磁盤文件之前，會先進入os cache，先進入操作系統級別的一個內存緩存中去。
只要buffer中的數據被refresh操作，刷入os cache中，就代表這個數據就可以被搜索到了。
為什么叫es是准實時的？NRT，near real-time，准實時。默認是每隔1秒refresh一次的，所以es是准實時的，因為寫入的數據1秒之后才能被看到。
可以通過es的restful api或者java api，手動執行一次refresh操作，就是手動將buffer中的數據刷入os cache中，讓數據立馬就可以被搜索到。
只要數據被輸入os cache中，buffer就會被清空了，因為不需要保留buffer了，數據在translog里面已經持久化到磁盤去一份了。
