1、Elasticsearch寫人數據的過程java
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都搞定以後，就返回響應結果給客戶端node
2、Elasticsearch讀取數據的過程算法
1）客戶端發送請求到任意一個node，成爲coordinate node
2）coordinate node對document進行路由，將請求轉發到對應的node，此時會使用round-robin隨機輪詢算法，在primary shard以及其全部replica中隨機選擇一個，讓讀請求負載均衡
3）接收請求的node返回document給coordinate node
4）coordinate node返回document給客戶端api
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去查詢
3、Elasticsearch搜索數據過程緩存
es最強大的是作全文檢索restful
1）客戶端發送請求到一個coordinate node
2）協調節點將搜索請求轉發到全部的shard對應的primary shard或replica shard也能夠
3）query phase：每一個shard將本身的搜索結果（其實就是一些doc id），返回給協調節點，由協調節點進行數據的合併、排序、分頁等操做，產出最終結果
4）fetch phase：接着由協調節點，根據doc id去各個節點上拉取實際的document數據，最終返回給客戶端負載均衡
搜索的底層原理：倒排索引
4、Elasticsearch寫數據的底層原理fetch
1）先寫入buffer，在buffer裏的時候數據是搜索不到的；同時將數據寫入translog日誌文件。spa
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裏面已經持久化到磁盤去一份了。
