一、寫入資料
1、ES 的任意節點都可以作為協調（Coordinating）節點接受請求（包括新建、索引或者刪除請求），每個節點都知道叢集中任一文件位置；
2、協調節點會通過 routing 欄位計算出一個主分片（primary shard），並把請求路由到主分片所在節點（routing 是一個可變值，預設是文件的 _id） ；
shard = hash(routing) % number_of_primary_shards
tips：這就解釋了為什麼我們要在建立索引的時候就確定好主分片的數量，並且永遠不會改變這個數量：因為如果數量變化了，那麼所有之前路由的值都會無效，文件也再也找不到了。
3、在主分片節點上，資料會先被寫入（index buffer）中，同時寫入 translog，這個時候資料還不能被搜尋到（這個也是 es 是近實時搜尋的原因）；
tips：整個過程大部分在記憶體中，如果斷電就會導致資料丟失。因此，ES 引入了 translog，資料寫入記憶體時，會同時寫入 translog（會立即落盤），來保證資料不丟失。
4、經過一段時間（預設 1s）或者 index buffer 滿了（預設 jvm 的 10%），會將 index buffer 中的文件 refresh 到系統檔案快取（os cache），然後再刷入到 lucene 的底層檔案 segment 中，同時建立倒排索引，這個時候文件是可以被搜尋到的；
5、 由於 segment 的不可變性，隨著 segment 越來越多，每開啟一個 segment 就會消耗一個檔案控制程式碼，導致查詢效能越來越差。這時，ES 後臺會有一個單獨執行緒專門合併 segment，將零碎的小的 segment 合併成一個大的 segment；
6、經過一段時間（預設30 min）或者 tanslog 滿了（預設512M），會將檔案系統快取的 segment 落盤；
7、如果主分片所在的節點請求執行成功，它會將請求同步轉發到副本分片所在節點，做到主副資料的一致性，一旦所有的副本分片都報告成功，主分片節點將向協調節點報告成功，協調節點向客戶端報告成功。因此，資料寫入，主副本之間採用的是同步寫入過程。
tips：寫一致性預設的策略是 —— Quorum ，即大多數的分片副本狀態沒問題才允許執行寫操作。
8、當叢集中某個節點當機，該節點上所有分片中的資料全部丟失（既有主分片，又有副分片）；丟失的副分片對資料的完整性沒有影響，丟失的主分片在其他節點上的副分片會被選舉成主分片；所以整個索引的資料完整性沒有被破壞。
9、如果是刪除操作，refresh 的時候就會生成一個 .del 檔案，邏輯刪除，將這個 document 標識為 deleted 狀態，在搜尋的搜尋的時候就不會被搜尋到了。
10、如果是更新操作，就是將原來的 document 標識為 deleted 狀態，然後新寫入一條資料。
二、查詢資料
GET my-index/_doc/0
1、ES 的任意節點都可以作為協調（Coordinating）節點接受請求，每個節點都知道叢集中任一文件位置；
2、協調節點對 id 進行路由，從而判斷該資料在哪個 shard，然後將請求轉發給對應的節點，此時會使用隨機輪詢演算法，在 primary shard 和 replica shard 中隨機選擇一個，讓讀取請求負載均衡，
3、處理請求的節點返回 document 給協調節點。
4、協調節點，返回 document 給客戶端。
三、檢索資料
GET /my-index/_search
{
"query": {
"match_all": {}
}
}
1、ES 的任意節點都可以作為協調（Coordinating）節點接受請求，每個節點都知道叢集中任一文件位置；
2、協調節點進行分詞等操作後，去查詢所有的 shard 節點。
3、所有 shard 將滿足條件的資料（id、排序欄位等）資訊返回給協調節點。
4、協調節點將資料重新進行排序，獲取到真正需要返回的資料的 id。
5、協調節點再次請求對應的 shard （此時有 id 了，可以直接定位到對應shard）。
6、獲取到全量資料，返回給客戶端。
tips： ES 要儘量避免深度分頁查詢，因為每個 shard 都會返回 from+size 的資料。比如我們要每頁顯示 10 條，查詢第 10000 頁資料，那麼每個分片就要返回10010 條資料，協調節點要處理更多的資料，這會嚴重的影響效能。
參考博文：