本節書摘來華章計算機《深入了解elasticsearch（原書第2版）》一書中的第1章 ，第1.2.3節，[美]拉斐爾·酷奇（rafal ku） 馬雷克·羅戈任斯基（marek rogoziski）著 張世武 餘洪淼 商旦 譯 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
本節我們将探索一些關鍵的elasticsearch特性，如啟動、故障檢測、資料索引和查詢等。
1. 啟動過程
當elasticsearch節點啟動時，它使用發現（discovery）子產品來發現同一個叢集中的其他節點（這裡的關鍵是配置檔案中的叢集名稱）并與它們連接配接。預設情況下，elasticsearch節點會向網絡中發送廣播請求，以找到擁有相同叢集名稱的其他節點。讀者可以通過下圖的描述來了解相關的處理。
叢集中有一個節點被選為主（master）節點。該節點負責叢集的狀态管理以及在叢集拓撲變化時做出反應，分發索引分片至叢集的相應節點上去。
請記住，從使用者的角度來看，elasticsearch中的管理節點并不比其他節點重要，這與其他的某些分布式系統不同（例如資料庫）。在實踐中，你不需要知道哪個節點是管理節點，所有操作可以發送至任意節點，elasticsearch内部會自行處理這些不可思議的事情。如果有需要，任意節點可以并行發送子查詢給其他節點，并合并搜尋結果，然後傳回給使用者。所有這些操作并不需要經過管理節點處理（請記住，elasticsearch是基于對等架構的）。
管理節點讀取叢集的狀态資訊，如果有必要，它會進行恢複（recovery）處理。在該階段，管理節點會檢查有哪些索引分片，并決定哪些分片将用作主分片。此後，整個叢集進入黃色狀态。
這意味着叢集可以執行查詢，但是系統的吞吐量以及各種可能的狀況是未知的（這種狀況可以簡單了解為所有的主分片已經被配置設定了，但是副本沒有被配置設定）。下面的事情就是尋找到備援的分片用作副本。如果某個主分片的副本數過少，管理節點将決定基于某個主分片建立分片和副本。如果一切順利，叢集将進入綠色狀态（這意味着所有主分片以及副本均已配置設定好）。
2. 故障檢測
叢集正常工作時，管理節點會監控所有可用節點，檢查它們是否正在工作。如果任何節點在預定義的逾時時間内不響應，則認為該節點已經斷開，然後錯誤處理過程開始啟動。這意味着可能要在叢集–分片之間重新做平衡，選擇新的主節點等。對每個丢失的主分片，一個新的主分片将會從原來的主分片的副本中選出來。新分片和副本的放置政策是可配置的，使用者可以根據具體需求進行配置。更多的資訊可以在第7章了解到。
為了描述故障檢測(failure detection)是如何工作的，我們用一個隻有3個節點的叢集作為例子，将會有一個管理節點，兩個資料節點。管理節點會發送ping請求至其他節點，然後等待響應。如果沒有響應（實際上多少次ping請求無響應可以确認節點失敗取決于配置），則該節點會被從叢集中移除出去。相反地，所有節點也會向主節點發送ping請求來檢查主節點是否在正常工作。節點之間的互相探測如下圖所示。
3. 與elasticsearch通信
值得一提的是，elasticsearch在内部也使用java api進行節點間通信。是以，java api提供了所有可被rest api調用的功能。
（1）索引資料
第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出版社）中已經讨論過這個問題了。