344
《深入理解Elasticsearch（原書第2版）》一1.2.3 Elasticsearch的工作流程
本節書摘來華章計算機《深入理解Elasticsearch（原書第2版）》一書中的第1章 ，第1.2.3節，[美]拉斐爾·酷奇（Rafal Ku） 馬雷克·羅戈任斯基（Marek Rogoziski）著 張世武 餘洪淼 商旦 譯 更多章節內容可以訪問雲棲社區“華章計算機”公眾號查看。
1.2.3 Elasticsearch的工作流程
本節我們將探索一些關鍵的Elasticsearch特性，如啟動、故障檢測、數據索引和查詢等。
1. 啟動過程
當Elasticsearch節點啟動時，它使用發現（discovery）模塊來發現同一個集群中的其他節點（這裏的關鍵是配置文件中的集群名稱）並與它們連接。默認情況下，Elasticsearch節點會向網絡中發送廣播請求，以找到擁有相同集群名稱的其他節點。讀者可以通過下圖的描述來了解相關的處理。
集群中有一個節點被選為主（master）節點。該節點負責集群的狀態管理以及在集群拓撲變化時做出反應，分發索引分片至集群的相應節點上去。
請記住，從用戶的角度來看，Elasticsearch中的管理節點並不比其他節點重要，這與其他的某些分布式係統不同（例如數據庫）。在實踐中，你不需要知道哪個節點是管理節點，所有操作可以發送至任意節點，Elasticsearch內部會自行處理這些不可思議的事情。如果有需要，任意節點可以並行發送子查詢給其他節點，並合並搜索結果，然後返回給用戶。所有這些操作並不需要經過管理節點處理（請記住，Elasticsearch是基於對等架構的）。
管理節點讀取集群的狀態信息，如果有必要，它會進行恢複（recovery）處理。在該階段，管理節點會檢查有哪些索引分片，並決定哪些分片將用作主分片。此後，整個集群進入黃色狀態。
這意味著集群可以執行查詢，但是係統的吞吐量以及各種可能的狀況是未知的（這種狀況可以簡單理解為所有的主分片已經被分配了，但是副本沒有被分配）。下麵的事情就是尋找到冗餘的分片用作副本。如果某個主分片的副本數過少，管理節點將決定基於某個主分片創建分片和副本。如果一切順利，集群將進入綠色狀態（這意味著所有主分片以及副本均已分配好）。
2. 故障檢測
集群正常工作時，管理節點會監控所有可用節點，檢查它們是否正在工作。如果任何節點在預定義的超時時間內不響應，則認為該節點已經斷開，然後錯誤處理過程開始啟動。這意味著可能要在集群–分片之間重新做平衡，選擇新的主節點等。對每個丟失的主分片，一個新的主分片將會從原來的主分片的副本中選出來。新分片和副本的放置策略是可配置的，用戶可以根據具體需求進行配置。更多的信息可以在第7章了解到。
為了描述故障檢測(failure detection)是如何工作的，我們用一個隻有3個節點的集群作為例子，將會有一個管理節點，兩個數據節點。管理節點會發送ping請求至其他節點，然後等待響應。如果沒有響應（實際上多少次ping請求無響應可以確認節點失敗取決於配置），則該節點會被從集群中移除出去。相反地，所有節點也會向主節點發送ping請求來檢查主節點是否在正常工作。節點之間的相互探測如下圖所示。
3. 與Elasticsearch通信
前麵已經討論過Elasticsearch是如何構建的了，然而，對普通用戶來說，最重要的部分是如何向Elasticsearch推送數據以及構建查詢。為了提供這些功能，Elasticsearch對外公開了一個設計精巧的API。如果我們說，基本上每個Elasticsearch功能模塊都有一個API，這將是令人鼓舞的。這個主API是基於REST的（REST細節請參考https://en.wikipedia.org/wiki/Representational_state_transfer），並且在實踐中能輕鬆整合到任意支持HTTP協議的係統中去。
Elasticsearch假設數據由URL攜帶或者以JSON（JSON細節請參考(https://en.wikipedia.org/wiki/JSON）文檔的形式由HTTP消息體攜帶。使用Java或者基於JVM語言的用戶，應該了解一下Java API，它除了REST API提供的所有功能以外還有內置的集群發現功能。
值得一提的是，Elasticsearch在內部也使用Java API進行節點間通信。因此，Java API提供了所有可被REST API調用的功能。
（1）索引數據
Elasticsearch提供了多種索引數據的方式。最簡單的方式是使用索引API，它允許用戶發送一個文檔至特定的索引。例如，使用curl工具（curl細節請參考https://curl.haxx.se/），可以使用如下命令創建一個文檔:
第2種方式允許用戶通過bulk API或UDP bulk API一次發送多個文檔至集群。兩者的區別在於網絡連接方式，前者使用HTTP協議，後者使用UDP協議。後者速度快，但是不可靠。還有一種方式使用被叫作河流（river）的插件來發送數據。不過在這裏我們不需要了解這種河流插件，因為它們將在Elasticsearch未來版本中被移除。
有一件事情需要記住，建索引操作隻會發生在主分片上，而不是副本上。當一個索引請求被發送至一個節點上時，如果該節點沒有對應的主分片或者隻有副本，那麼這個請求會被轉發到擁有正確的主分片的節點。然後，該節點將會把索引請求群發給所有副本，等待它們的響應（這一點可以由用戶控製），最後，當特定條件具備時（比如說達到規定數目的副本都完成了更新時）結束索引過程。
下圖展示了我們剛剛探討的索引處理過程。
（2）查詢數據
查詢API占據了Elasticsearch API的大部分。使用查詢DSL（基於JSON的可用於構建複雜查詢的語言），我們可以做下麵這些事情：
- 使用各種查詢類型，包括，簡單的詞項查詢，短語查詢，範圍查詢，布爾查詢，模煳查詢，區間查詢，通配符查詢，空間查詢，以及具備人類可讀的打分控製功能的函數查詢，等等。
- 組合簡單查詢構建複雜查詢。
- 文檔過濾，在不影響評分的前提下拋棄那些不滿足特定查詢條件的文檔。- 這一點可以提升性能。
- 查找與特定文檔相似的文檔。
- 查找特定短語的查詢建議和拚寫檢查。
- 使用切麵構建動態導航和計算各種統計量。
使用預搜索（prospective search）和查找與指定文檔匹配的query集合。
談到查詢操作，讀者應該了解一個很重要的事實：查詢並不是一個簡單的、單步驟的操作。一般來說，查詢分為兩個階段：分散階段（scatter phase）和合並階段（gather phase）。在分散階段將查詢分發到包含相關文檔的多個分片中去執行查詢，而在合並階段則從眾多分片中收集返回結果，然後對它們進行合並、排序，進行後續處理，然後返回給客戶端。該機製可以由下圖描述。
Elasticsearch對外提供了6個係統參數，通過使用其中之一來定製分散/合並機製。在本書的姐妹版《Elasticsearch Server, Second Edition》（Packt出版社）中已經討論過這個問題了。
最後更新：2017-06-23 23:34:21