Debug说明
- 记录ES数据搜索的整个debug流程，具体细节没有作过多的解释说明
- Debug的索引，设置2shard、0replicas，便于理解每个分片的执行主线
- ES version：5.6.16
- 一个ES节点（master and data）
Debug记录
接着往下Step Over，则可完成主体的执行流程。到这里，整个Search的执行流程主线梳理完成，简单小记下其中比较核心的知识点：
- 从代码中可明显的看出，ES的Search分为query和fetch两个阶段；query阶段从查询涉及的每个分片中获取满足条件的docIdsList，然后对此进行合并且排序筛选出需要的docIdsToLoad，最后fetch阶段根据docIdsToLoad去查询涉及的每个分片，获取最终的结果
- ES的搜索类型包括QUERY_THEN_FETCH、QUERY_AND_FETCH、DFS_QUERY_THEN_FETCH三种；其中QUERY_THEN_FETCH是ES默认的查询方式；如果想要获取更准确的评分则可以使用DFS_QUERY_THEN_FETCH的查询方式，但同样伴随着更多的资源消耗；QUERY_AND_FETCH适用场景更少，即当此次request设计的分片数为1时，在执行完query后紧接着执行fetch；QUERY_AND_FETCH已经被标记为deprecated状态
- performPhaseOnShard函数对request中涉及到的每个shard，均会封装成一个线程，然后通过ES的search线程池的方式执行并管理具体的任务
- 每个分片的执行结果是以channel send response的方式发送到协调节点参与汇总的工作，协调节点对各分片结果的处理入口是在InitialSearchPhase类的onShardResult方法中；query阶段处理完成，会紧接着由协调节点发起，进入fetch阶段
- ES中通过implements Runnable，实现了自己的AbstractRunnable，并override run函数，对其中的执行顺序进行了规约，比如定义执行体为doRun，发生异常了会执行onFailure，结束后会执行onAfter；熟悉了这个，有助于理解其中的一些函数调用逻辑
- ES会把最初的Rest请求给转换成内部统一的Transport的方式处理，比如TransportAction，search逻辑对应的TransportSearchAction类等
小结
与Elasticsearch Write Debug 详细记录这篇文档形成呼应，本篇文档详细的记录了ES整个search主线逻辑，也是希望帮助那些刚刚接触ES源码的同学快速上车，早点理清代码主线，然后再针对某个具体的模块做深入的研究。文档中并没有涉及到多少硬核知识，主要的重心还是放在了执行主线上；ES的源码比较复杂，需要日拱一卒坚持不断的研究，与大家一起学习，一起进步
