（一）通過HTTP請求調用搜索服務
示例：

GET http://localhost:9200/index_test/_search
{
   "query": {
       "query_string": {
          "default_field": "title",
          "query": "this is title field"
       }
   }
}

（二）相關說明
1、搜尋型別
query_then_fetch/dfs_query_then_fetch：預設是query_then_fetch搜尋，現在5.3.1版本只有這兩種搜尋型別（SearchType列舉類）
query_and_fetch/dfs_query_and_fetch：內部搜尋優化，不支援REST呼叫，現已移除
2、主要協議
indices:admin/shards/search_shards
indices:data/read/search
indices:data/read/search[phase/query]：query階段
indices:data/read/search[phase/fetch/id]：fetch階段
3、主要服務類
TransportSearchAction
SearchQueryThenFetchAsyncAction
SearchDfsQueryThenFetchAsyncAction
SearchTransportService
SearchPhaseController
SearchService
QueryPhase
FetchPhase
OperationRouting
（三）具體搜尋的過程
  1、HTTP到TCP的呼叫鏈：
RestController -> RestSearchAction -> TransportClient -> TransportSearchAction.doExecute(task,request,listener)；
  searchRequestBuilder.execute()呼叫鏈:
TransportClient -> TransportSearchAction.doExecute(task,request,listener)
  2、 如果有跨叢集搜尋，按照不同的叢集將請求中的索引分組，然後通過RemoteClusterService的collectSearchShards方法針對每個叢集將搜尋請求傳送出去，目標叢集TransportSearchAction收到請求呼叫doExecute方法處理。本示例只搜尋一個叢集中的一個索引，沒有分組，呼叫executeSearch方法直接處理
  3、解析索引別名關聯的過濾器；獲取請求中的routing路由引數資訊；
  4、OperationRouting計算目標Shard列表
   4.1、首先從ClusterState叢集路由表IndexRoutingTable中獲取所有IndexShardRoutingTable，每個IndexShardRoutingTable存有一個分片所有相關資訊，包括其主分片和副本的，執行中的和未分配的等等（本示例是1個主分片4個副本，所以只有一個IndexShardRoutingTable）
   4.2、遍歷IndexShardRoutingTable列表，計算IndexShardRoutingTable中該次請求應該訪問的具體Shard
    4.3、檢視本次請求是否有preference引數，可根據使用者引數請求只搜尋主分片、只搜尋副本、搜尋特定Shard、搜尋指定Node等，有的話根據preference引數選擇特定的節點和分片：
    4.4、沒有指定preference引數，根據IndexShardRoutingTable路由表處理：優先選擇執行中的Shard，其次是遷移中的Shard，通過AtomicInteger維護一個計數器，每次加1，對Shard列表取餘，本質是一個輪詢的演算法，需要查詢特定的Shard列表封裝到GroupShardsIterator迭代器中，後面會檢查查詢的Shard數量是否超過限制，過多的Shard查詢非常影響效能，所以預設上限1000個
  5、解析索引的boost加權引數；如果只查詢一個Shard或者只進行搜尋建議查詢，將搜尋型別置為query_then_fetch，因為一個Shard沒有必要再走dfs_query_then_fetch
  6、根據搜尋型別的不同構造不同的action例項，query_then_fetch為SearchQueryThenFetchAsyncAction，dfs_query_then_fetch為SearchDfsQueryThenFetchAsyncAction，處於效率效能等方面的考慮，一般用query_then_fetch查詢
  7、SearchQueryThenFetchAsyncAction呼叫start方法處理，迭代GroupShardsIterator，針對每個Shard，呼叫performInitialPhase方法開始第一階段的搜尋處理，與目標Shard的Node建立連線，通過SearchTransportService的sendExecuteQuery將請求（indices:data/read/search[phase/query]）傳送出去，如果請求的Shard只有一個，該階段就獲取Document文件，通過QueryFetchSearchResult儲存搜尋結果，其他情況不會自動獲取Document，通過QuerySearchResult儲存搜尋結果；請求處理類在SearchTransportService類中註冊，為TaskAwareTransportRequestHandler類，TaskAwareTransportRequestHandler收到請求後呼叫SearchService的executeQueryPhase方法處理第一階段的query
  8、為ShardSearchTransportRequest請求建立DefaultSearchContext上下文物件，DefaultSearchContext存有請求引數、搜尋結果、Shard資訊、統計等等跟本次搜尋相關的所有資訊；SearchService呼叫loadOrExecuteQueryPhase方法，首先判斷該次請求是否可被快取（根據請求引數、es配置、query_then_fetch搜尋型別、size是否為0等判斷），可以的話就從快取中載入資料，呼叫IndicesService的loadIntoContext方法將資料載入到context上下文物件中，沒有快取資料呼叫QueryPhase的execute(searchContext)方法走正常搜尋流程；主要分為查詢、重新打分、搜尋提示、聚合四個子流程
   8.1、查詢
  確定獲取的文件數，為總文件數和from+size的較小值，例如每頁10條，檢索第2頁的資料，需要查詢出20條，排序將10-19編號返回
  確定Lucene Collector文件收集器物件，Collector負責收集命中的TopDocs文件，可以定製不同的Collector進行個性化的排序、過濾等，根據請求的不同使用不同的Collector型別，比如TopDocsCollector（ TopDocs文件收集器的基類，通過PriorityQueue優先順序佇列儲存top n資料）、TopScoreDocCollector（ScoreDoc文件收集器的基類，ScoreDoc是TopDocs中的一條資料，預設按score降序排列，score相同則按id升序排列）、TotalHitCountCollector（只獲取相關文件數時用）、ProfileCollector（統計時間開銷，類似Java的IO流類，可以裝飾別的Collector）、TimeLimitingCollector（根據設定的閾值及時停止耗時的操作，預設配置search.default_search_timeout為-1，即不超時，同樣可裝飾別的Collector），CancellableCollector（elasticsearch定製，可取消查詢）等，本示例是SimpleTopScoreDocCollector（TopScoreDocCollector的例項）；如果需要獲取執行時間統計資訊，用InternalProfileCollector包裝SimpleTopScoreDocCollector；讓查詢可被取消用CancellableCollector進行包裝
  在構造Collector的過程中，主要涉及scroll滾動、collapse欄位摺疊、post filter過濾器、超時collector等邏輯處理
呼叫IndexSearcher.search(query, collector)交給Lucene進行查詢，隨後從collector中得到TopDocs資料，放到QuerySearchResult或QueryFetchSearchResult中
接下來如果需要還要進行重新打分，搜尋提示和聚合操作的處理
   8.2、重新打分
   8.3、搜尋提示
   8.4、聚合
  9、每次查詢執行成功後，AtomicInteger計數器加1，所有Shard查詢請求處理完成之後：如果只牽扯到單個Shard，直接呼叫SearchService的executeFetchPhase進行處理，首先確定需要載入文件資料的doc id，區間為[from，from+size)，放到context中；
其它情況Listener回撥觸發SearchQueryThenFetchAsyncAction內部類FetchPhase的run方法：
  SearchPhaseController對獲取到的ScoreDoc陣列進行排序，取得特定區間的ScoreDoc（[from，from+size)）
  對ScoreDoc按Shard分組，hppc類庫IntArrayList[]儲存結構，IntArrayList存有一個Shard到一個或多個docId的對映
  針對每個Shard傳送fetch請求，每次返回結果收集到CountedCollector中，全部結果返回後呼叫sendResponseAsync方法非同步執行合併操作得到InternalSearchResponse並給使用者返回結果
  合併多個fetch資料主要是SearchPhaseController的merge方法，主要合併搜尋提示、聚合、統計等資訊
  10、fetch階段主處理流程為FetchPhase的execute(context)方法
檢查context中的StoredFieldsContext（存有配置store=yes的field欄位資訊）、ScriptFieldsContext（利用painless，groovy等指令碼處理的script_fields欄位）、FetchSourceContext（如果沒有前兩個context，預設載入source欄位資料），FieldsVisitor存有需要載入的store欄位資訊，內建的預設載入欄位主要有_routing、_ttl、_parent、_timestamp、_source、_uid
  確定需要載入的欄位後，對於每一個docId，載入位元組資料到FieldVisitor中，context的SearchLookup解析得到所有欄位的資料，得到了InternalSearchHit物件，但是現在很多欄位資料都沒有填充，只有id，type等資訊
  接下來是9個子階段的處理，下面都是FetchSubPhase介面的實現類，每個InternalSearchHit都會被這些FetchSubPhase處理一遍，每個實現類負責不同的資料組裝

ExplainFetchSubPhase ：打分解釋說明
DocValueFieldsFetchSubPhase ：doc value欄位的資料，比如 "docvalue_fields": ["field1", "field2"]
ScriptFieldsFetchSubPhase ：script欄位資料
FetchSourceSubPhase ：從上述SourceLookup中獲取source欄位資料填充到hit中
VersionFetchSubPhase ：文件的version資訊
InnerHitsFetchSubPhase：inner hits 資料填充
HighlightPhase ：高亮資訊
PercolatorHighlightSubFetchPhase：繼承HighlightPhase ，根據文件得到符合要求的查詢為Percolator查詢（正常查詢的逆過程），高亮單獨處理
ParentFieldSubFetchPhase ：父子文件中父文件資訊
 

  最後InternalSearchHit[]陣列物件還有2個子階段的處理

PercolatorHighlightSubFetchPhase ：為每個InternalSearchHit填充高亮資訊MatchedQueriesFetchSubPhase ：為每個InternalSearchHit獲取匹配到的查詢名稱

  11、query和fetch處理完成，返回相關文件資料

  12、文件資料