es 寫入數據的工作原理是什麽啊？es 查詢數據的工作原理是什麽啊？底層的 lucene 介紹一下唄？倒排索引了解嗎?

es 寫數據過程

• 客戶端選擇一個 node 發送請求過去，這個 node 就是 coordinating node（協調節點）。
• coordinating node 對 document 進行路由，將請求轉發給對應的 node（有 primary shard）。
• 實際的 node 上的 primary shard 處理請求，然後將數據同步到 replica node。
• coordinating node 如果發現 primary node 和所有 replica node
  都搞定之後，就返回響應結果給客戶端。

如圖:

es 讀數據過程

可以通過 doc id 來查詢，會根據 doc id 進行 hash，判斷出來當時把 doc id 分配到了哪個 shard 上面去，從那個 shard 去查詢。

• 客戶端發送請求到任意一個 node，成為 coordinate node。
• coordinate node 對 doc id 進行哈希路由，將請求轉發到對應的 node，此時會使用 round-robin隨機輪詢算法，在 primary shard 以及其所有 replica 中隨機選擇一個，讓讀請求負載均衡。
• 接收請求的 node 返回 document 給 coordinate node
  。
• coordinate node 返回 document 給客戶端。

es 搜索數據過程

es 最強大的是做全文檢索，就是比如你有三條數據：

java真好玩兒啊
java好難學啊
j2ee特別牛

你根據 java 關鍵詞來搜索，將包含 java的 document 給搜索出來。es 就會給你返回：java真好玩兒啊，java好難學啊。

• 客戶端發送請求到一個 coordinate node。
• 協調節點將搜索請求轉發到所有的 shard 對應的 primary shard 或 replica shard，都可以。
• query phase：每個 shard 將自己的搜索結果（其實就是一些 doc id
  ）返回給協調節點，由協調節點進行數據的合並、排序、分頁等操作，產出最終結果。
• fetch phase：接著由協調節點根據 doc id 去各個節點上拉取實際的 document 數據，最終返回給客戶端。

寫請求是寫入 primary shard，然後同步給所有的 replica shard；讀請求可以從 primary shard 或 replica shard 讀取，采用的是隨機輪詢算法。

寫數據底層原理

大致如圖:

1. 數據先寫入內存 buffer，在 buffer 裏的時候數據是搜索不到的；同時將數據寫入 translog 日誌文件。如果 buffer 快滿了，或者到一定時間，就會將內存 buffer 數據 refresh 到一個新的 segment file 中，但是此時數據不是直接進入 segment file 磁盤文件，而是先進入 os cache 。這個過程就是 refresh。

2. 每隔 1 秒鐘，es 將 buffer 中的數據寫入一個新的 segment file，每秒鐘會產生一個新的磁盤文件 segment file，這個 segment file 中就存儲最近 1 秒內 buffer 中寫入的數據。但是如果 buffer 裏面此時沒有數據，那當然不會執行 refresh 操作，如果 buffer 裏面有數據，默認 1 秒鐘執行一次 refresh 操作，刷入一個新的 segment file 中。

3.操作系統裏面，磁盤文件其實都有一個東西，叫做 os cache，即操作系統緩存，就是說數據寫入磁盤文件之前，會先進入 os cache，先進入操作系統級別的一個內存緩存中去。只要 buffer中的數據被 refresh 操作刷入 os cache中，這個數據就可以被搜索到了。

4.為什麽叫 es 是準實時的？ NRT，全稱 near real-time。默認是每隔 1 秒 refresh 一次的，所以 es 是準實時的，因為寫入的數據 1 秒之後才能被看到。可以通過 es 的 restful api 或者 java api，手動執行一次 refresh 操作，就是手動將 buffer 中的數據刷入 os cache中，讓數據立馬就可以被搜索到。只要數據被輸入 os cache 中，buffer 就會被清空了，因為不需要保留 buffer 了，數據在 translog 裏面已經持久化到磁盤去一份了。重復上面的步驟，新的數據不斷進入 buffer 和 translog，不斷將 buffer 數據寫入一個又一個新的 segment file 中去，每次 refresh 完 buffer 清空，translog 保留。隨著這個過程推進，translog 會變得越來越大。當 translog 達到一定長度的時候，就會觸發 commit 操作。

5. commit 操作發生第一步，就是將 buffer 中現有數據 refresh 到 os cache 中去，清空 buffer。然後，將一個 commit point寫入磁盤文件，裏面標識著這個 commit point 對應的所有 segment file，同時強行將 os cache 中目前所有的數據都 fsync 到磁盤文件中去。最後清空 現有 translog 日誌文件，重啟一個 translog，此時 commit 操作完成。

6.這個 commit 操作叫做 flush。默認 30 分鐘自動執行一次 flush，但如果 translog 過大，也會觸發 flush。flush 操作就對應著 commit 的全過程，我們可以通過 es api，手動執行 flush 操作，手動將 os cache 中的數據 fsync 強刷到磁盤上去。

7.translog 日誌文件的作用是什麽？你執行 commit 操作之前，數據要麽是停留在 buffer 中，要麽是停留在 os cache 中，無論是 buffer 還是 os cache 都是內存，一旦這臺機器死了，內存中的數據就全丟了。所以需要將數據對應的操作寫入一個專門的日誌文件 translog 中，一旦此時機器宕機，再次重啟的時候，es 會自動讀取 translog 日誌文件中的數據，恢復到內存 buffer 和 os cache 中去。

8. translog 其實也是先寫入 os cache 的，默認每隔 5 秒刷一次到磁盤中去，所以默認情況下，可能有 5 秒的數據會僅僅停留在 buffer 或者 translog 文件的 os cache 中，如果此時機器掛了，會丟失 5 秒鐘的數據。但是這樣性能比較好，最多丟 5 秒的數據。也可以將 translog 設置成每次寫操作必須是直接 fsync 到磁盤，但是性能會差很多。

其實 es 第一是準實時的，數據寫入 1 秒後可以搜索到；可能會丟失數據的。有 5 秒的數據，停留在 buffer、translog os cache、segment file os cache 中，而不在磁盤上，此時如果宕機，會導致 5 秒的數據丟失。

總結一下，數據先寫入內存 buffer，然後每隔 1s，將數據 refresh 到 os cache，到了 os cache 數據就能被搜索到（所以我們才說 es 從寫入到能被搜索到，中間有 1s 的延遲）。每隔 5s，將數據寫入 translog 文件（這樣如果機器宕機，內存數據全沒，最多會有 5s 的數據丟失），translog 大到一定程度，或者默認每隔 30mins，會觸發 commit 操作，將緩沖區的數據都 flush 到 segment file 磁盤文件中。

數據寫入 segment file 之後，同時就建立好了倒排索引。

刪除/更新數據底層原理

1. 如果是刪除操作，commit 的時候會生成一個 .del 文件，裏面將某個 doc 標識為 deleted 狀態，那麽搜索的時候根據 .del 文件就知道這個 doc 是否被刪除了。

2. 如果是更新操作，就是將原來的 doc 標識為 deleted 狀態，然後新寫入一條數據。

3. buffer 每 refresh 一次，就會產生一個 segment file，所以默認情況下是 1 秒鐘一個 segment file，這樣下來 segment file 會越來越多，此時會定期執行 merge。每次 merge 的時候，會將多個 segment file 合並成一個，同時這裏會將標識為 deleted 的 doc 給物理刪除掉，然後將新的 segment file 寫入磁盤，這裏會寫一個 commit point，標識所有新的 segment file，然後打開 segment file 供搜索使用，同時刪除舊的 segment file。

文章轉載來自https://www.cnblogs.com/yuxiang1/p/10601253.html

ElasticSearch讀寫原理