一起来学ES —— Bulk剖析

时间:2024-05-19 14:46:30

背景

  • Bulk请求是ES常用的一种multi-document请求,其处理比较复杂,之前一直搞不清请求的处理逻辑,今天就从源码入手,仔细剖析一下其执行逻辑。

时序分析

  • 简单而言,Bulk的时序如下图所示,Http节点只将包转为TCP,ingest节点进行些预设的前置处理,然后按shard拆分,再把按shard拆开的bulk再发到真实的data节点上,最后由data节点进行主副本同步写入。
    一起来学ES —— Bulk剖析

具体流程

  1. RestControllor 接收请求,dispatch到对应的handler上
    一起来学ES —— Bulk剖析
  2. BaseRestHandler 调用 RestBulkAction 进行前置处理,请求转为 BulkRequest
    一起来学ES —— Bulk剖析
  3. NodeClient根据 ActionModule 注册的映射关系,找到TransportBulkAction作为tcp的处理逻辑
  4. TransportBulkAction 检查自己是不是 ingest node,如果不是就转发
    一起来学ES —— Bulk剖析
  5. Ingest Node接收到请求,执行pipeline
    一起来学ES —— Bulk剖析
  6. TransportBulkAction调用BulkOperationBulkRequest拆为BulkShardRequest,转发到DataNode
    一起来学ES —— Bulk剖析
  7. Primary Data Node收到请求,转为ReplicationOperation操作,调用TransportShardBulkAction进行主副本的依次执行
    一起来学ES —— Bulk剖析
  8. TransportShardBulkAction的具体执行过程为shardOperationOnPrimaryshardOperationOnReplica,执行时直接调用了Engine进行执行。具体代码就不贴了,比较长

线程池分析

  • 在日常中,我们经常遇到由于线程池占满的es_rejected_execution_exception
  • 通过源码可以看到,bulk的线程池为ThreadPool.Names.BULK,全局查找后发现只有TransportShardBulkActionPipelineExecutionService有用。
  • Rest和TransportBulk居然没有用Bulk线程池,很是惊讶。不知道是不是没找到。。。

让搜索更简单


  • ZSearch2.0 服务申请入口:http://search.alipay.com/看我们这二级的域名就知道重要性了吧。
  • 蚂蚁中间件的ZSearch2.0,核心采用了ElasticSearch,原生支持所有的ElasticSearch的操作,具备强大的数据检索和分析能力,自5月份投入试运行以来,已线上服务16个业务方,数据规模在130TB,近2K亿的文档数,QPS稳定在30W左右。 通过数月不断的观察、调优、测试,如今已达到正式上线的标准,欢迎同学们踊跃使用,提出宝贵意见。
  • 后续我们会对Elasticsearch和Lucene做持续优化,欢迎大家来使用,并提出你的需求。
  • 有任何问题可以联系我们(@善仁(xinyu.jxy),@丰坚(yinghao.wyh),@十倍(lvliang.ll),@城破(huabiao.mahb) )
  • 详细介绍请参阅ZSearch2.0 夏日来袭