1.elasticsearch 如何實現Master 選舉
elasticsearch 選主是zenDiscovery模塊負責，主要通過ping(節點之間的RPC來發現彼此)和Unicast(單播模塊包含一個主機列表來控制那些節點需要ping通)；對所有可以成爲master的節點（node.master:true）根據nodeId字典排序，每次選舉都把自己所知道的節點排一次序，然後選出第一個（第0位）節點，暫認爲它是master 節點。如果對某個節點投票數達到一定的值（可以成爲master節點數n/2+1）並且該節點自己也選自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
2.es寫數據過程
- 客戶端選擇一個node 發送過去，這個node就是coordinating node(協調節點)。
- coordinating node 對document 進行路由，將請求轉發給對應的node(primary shard)。路由算法 hashcode(document_id) % shards
- 實際的node 上的parimary shard 處理請求，然後將數據同步到replica node。
- coordinating node 如果發現primary shard 處理請求，然後將數據同步到replica node
- coordinating node 如果發現primary node 和所有replica node 都搞定之後，就返回響應結果給客戶端。
3.es 讀取數據過程
可以通過doc id 來查詢，會根據doc id 進行hash ,判斷出來當時doc id 分配到那個shard 上面去，從那個shard查詢
- 客戶端發送一個請求到任意一個node,成爲coordinate node。
- coordinate node 對doc id 進行hash 路由，將請求轉發到對應的node, 此時會使用round-robin 輪詢算法在primary shard 以及其所有replica 中隨機選擇一個，讓讀請求負載均衡。
- 接收請求的node 返回document 給coordinate node。
- 給coordinate node 返回document 給客戶端。
4.es 寫數據的底層原理
1). document 先寫入到內存buffer 中，同時寫translog 日誌
2). refresh 操作之所以是近實時搜索：寫入和打開一個新段（一個追加的倒排索引）的輕量過程叫refresh。每隔一秒把buffer 中的數據創建一個新的segement。這裏新段會被先寫入文件系統緩存（代價相對比較低），稍後再被刷入到磁盤（代價高）。不過只要文件在緩存中，就可以像其他文件一樣可以被打開和讀取了。內存buffer 被清空。此時新segment中的文件就可以被搜索了，這就意味着document 可以寫入到被搜索需要一秒鐘，如果要更改這個屬性，可以執行以下操作
put /index_test
{
"settings":
{
"refresh_interval":"30s"
}
}
3). flush 操作導致持久化變更：執行一個提交併且截斷translog 的行爲在Elasticsearch 被稱作一次flush。 刷新（refresh）完成後，緩存被清空但是translog 日誌不會。translog 日誌也會越來越多，當translog 日誌大於一個閾值時候或30分鐘，會發出flush 操作。
- 所有內存緩存區的文檔都會被寫入一個新的segement。
- 緩存區被清空
- 一個提交點被寫入磁盤
- 文件系統通過fsync 到磁盤
- 老的translog 被刪除
分片每30分鐘自動（flush）,或着translog 太大的時候也會被刷新。也可以用flush命令手動執行。
translog 每5秒會被寫入磁盤（所以如果這5s,數據在cache 而且log 沒持久化會丟失）。在一次增刪改操作後translog 只有在replica 和 primary shard 都成功纔會成功，如果需提高操作速度，可以設置成異步的
PUT /index_test
{
"settings": {
"index.translog.durability": "async" ,
"index.translog.sync_interval":"5s"
}
}
所以總結是有三個批次操作，一秒一次refresh 保證近實時，5秒做已給translog 持久化保證數據未持久化前留底，30分鐘做一次持久化。
4.es搜索數據過程
客戶端發送到一個coordinate node。
協調節點將搜索請求轉發到所有的shard對應的primary shard 或replica shard,都可以
query phase:每個shard 將自己的搜索結果（doc id）返回給協調節點，由協調節點進行數據合併，排序，分頁等操作，產出最終結果。
fetch phase: 接着由協調節點根據doc id 去哥哥節點拉取實際的document 數據，最終返回給客戶端。
5.translog 和commit point 的數據恢復
在磁盤上會有一個上次持久話的commit point,translog 上有一個commit point ,根據這倆個commit point ,會把translog 中的變更記錄進行回訪，重新執行之前的操作。
6.刪除和更新原理
一個document被刪除，它實際只是在.del 文件中被標記刪除。一個標記刪除的文檔然可以被查詢匹配到，但它最終結果被返回前從結果中移除。
文檔更新也是類似的操作方式：當一個文檔被更新時，舊版本文檔被標記刪除，文檔的新版本被索引到一個新的段中。 可能兩個版本的文檔都會被一個查詢匹配到，但被刪除的那個舊版本文檔在結果集返回前就已經被移除。
segment合併的時候那些被刪除的document 會被清除。被刪除的文檔（或被更新文檔的舊版本）不會拷貝到新的大segement。
7.segment合併
由於buffer 數據會被刷新到segment中，所以segment會很多，爲了防止這種情況，es 會把一些小segment合併。並執行物理刪除小segement。
手動執行段合併命令
POST /index_test/_forcemerge?max_num_segements=1