滴滴ElasticSearch千万级TPS写入性能翻倍技术剖析.docxVIP

滴滴ElasticSearch千万级TPS写入功能翻倍技术剖析 2021-06-02 以下文章来源于滴滴技术 ，作者魏子珺 HYPERLINK 滴滴技术 . 滴滴出行官方技术号 桔妹导读：滴滴ElasticSearch平台承接了公司内部全部使用ElasticSearch的业务，包括核心搜索、RDS从库、日志检索、平安数据分析、目标数据分析等等。平台规模达到了3000+节点，5PB 的数据存储，超过万亿条数据。平台写入的峰值写入TPS达到了2000w/s，每天近 10 亿次检索查询。为了承接这么大的体量和丰富的使用场景，滴滴ElasticSearch需要处理稳定性、易用性、功能、成本等诸多问题。我们在4年多的时间里，做了大量优化，积累了格外丰富的阅历。通过建设滴滴搜索平台，打造滴滴ES引擎，全方位提升用户使用ElasticSearch体验。这次给大家共享的是滴滴在写入功能优化的实践，优化后，我们将ES索引的写入功能翻倍，结合数据冷热分别场景，支持大规格存储的物理机，给公司每年节省千万左右的服务器成本。 1.? 背景 前段时间，为了降低用户使用ElasticSearch的存储成本，我们做了数据的冷热分别。为了保持集群磁盘利用率不变，我们削减了热节点数量。ElasticSearch集群开头消灭写入瓶颈，节点产生大量的写入rejected，大量从kafka同步的数据消灭写入延迟。我们深化分析写入瓶颈，找到了突破点，最终将Elasticsearch的写入功能提升一倍以上，处理了ElasticSearch瓶颈导致的写入延迟。这篇文章引见了我们是如何发觉写入瓶颈，并对瓶颈进行深化分析，最终进行了创新性优化，极大的提升了写入功能。 2.? 写入瓶颈分析 ▍2.1 发觉瓶颈 我们去分析这些延迟问题的时候，发觉了一些不太好解释的现象。之前做功能测试时，ES节点cpu利用率能超过80%，而生产环境延迟索引所在的节点cpu资源只使用了不到50%，集群平均cpu利用率不到40%，这时候IO和网络带宽也没有压力。通过提升写入资源，写入速度基本没添加。于是我们开头一探到底，我们选取了一个索引进行验证，该索引使用10个ES节点。从下图看到，写入速度不到20w/s，10个ES节点的cpu，峰值在40-50%之间。 为了确认客户端资源是足够的，在客户端不做任何调整的情况下，将索引从10个节点，扩容到16个节点，从下图看到，写入速度来到了30w/s左右。 这证明白瓶颈出在服务端，ES节点扩容后，功能提升，说明10个节点写入已经达到瓶颈。但是上图可以看到，CPU最多只到了50%，而且此时IO也没达到瓶颈。 ▍2.2?ES写入模型说明 这里要先对ES写入模型进行说明，下面分析缘由会跟写入模型有关。 客户端一般是预备好一批数据写入ES，这样能极大削减写入恳求的网络交互，使用的是ES的BULK接口，恳求名为BulkRequest。这样一批数据写入ES的ClientNode。ClientNode对这一批数据按数据中的routing值进行分发，组装成一批BulkShardRequest恳求，发送给每个shard所在的DataNode。发送BulkShardRequest恳求是异步的，但是BulkRequest恳求需要等待全部BulkShardRequest响应后，再前往客户端。 ▍2.3?查找缘由 我们在ES ClientNode上有记录BulkRequest写入slowlog。 `items`是一个BulkRequest的发送恳求数 `totalMills `是BulkRequest恳求的耗时 `max`记录的是耗时最长的BulkShardRequest恳求 `avg`记录的是全部BulkShardRequest恳求的平均耗时。 我这里截取了部分示例。 [xxx][INFO ][o.e.m.r.RequestTracker ? ] [log6-clientnode-sf-5aaae-10] bulkDetail||requestId=null||size|items=7014||totalMills=2206||max=2203||avg=37 [xxx][INFO ][o.e.m.r.RequestTracker ? ] [log6-clientnode-sf-5aaae-10] bulkDetail||requestId=null||size=210506||items=137||totalMills=2655||max=2655||avg=218 从示例中可以看到，2条记录的avg相比max都小了很多。一个BulkRequest恳求的耗时，取决于最终一个BulkShardRequest恳求的前往。这就很简约联想到分布式系统的长尾效