腾讯万亿级Elasticsearch技术解密( 二 ) _Elasticsearch

文章插图
另一类我们称之为时序类业务挑战，包含日志、Metrics、APM 等场景。相比于搜索类业务重点关注高可用、高性能，时序类业务会更注重成本、性能。比如时序场景用户通常要求高写入吞吐，部分场景可达 1000w/swps;在这样写入吞吐下，保留 30 天的数据，通常可达到 PB 级的存储量。而现实是日志、监控等场景的收益相对较低，很可能用户用于线上实际业务的机器数量才是 100 台，而监控、日志等需要 50 台，这对多数用户来说，基本是不可接受的。所以在时序类业务中，主要的挑战在于存储成本、计算成本等方面。
前面我们介绍了在搜索类、时序类业务场景下遇到的高可用、低成本、高性能等挑战，下面针对这些挑战，我们重点分享腾讯在 ES 内核方面的深入实践。
三、ES 优化实践

文章插图
首先，我们来看看高可用优化，我们把高可用划分为三个维度：

系统健壮性：是指 ES 内核自身的健壮性，也是分布式系统面临的共性难题。例如，在异常查询、压力过载下集群的容错能力;在高压力场景下，集群的可扩展性;在集群扩容、节点异常场景下，节点、多硬盘之间的数据均衡能力。
容灾方案：如果通过管控系统建设，保障机房网络故障时快速恢复服务，自然灾害下防止数据丢失，误操作后快速恢复等。
系统缺陷：这在任何系统发展过程中都会持续产生，比如说 Master 节点堵塞、分布式死锁、滚动重启缓慢等。

文章插图
针对上述问题，下面来介绍我们在高可用方面的解决方案：
系统健壮性方面，我们通过服务限流，容忍机器网络故障、异常查询等导致的服务不稳定，后面展开介绍。通过优化集群元数据管控逻辑，提升集群扩展能力一个数量级，支持千级节点集群、百万分片，解决集群可扩展性问题;集群均衡方面，通过优化节点、多硬盘间的分片均衡，保证大规模集群的压力均衡。
容灾方案方面，我们通过扩展 ES 的插件机制支持备份回档，把 ES 的数据备份回档到廉价存储，保证数据的可恢复;支持跨可用区容灾，用户可以按需部署多个可用区，以容忍单机房故障。垃圾桶机制，保证用户在欠费、误操作等场景下，集群可快速恢复。
系统缺陷方面，我们修复了滚动重启、Master 阻塞、分布式死锁等一系列 Bug 。其中滚动重启优化，可加速节点重启速度 5+倍，具体可参考 PR ES-46520;Master 堵塞问题，我们在 ES 6.x 版本和官方一起做了优化。

文章插图
这里我们展开介绍下服务限流部分。我们做了 4 个层级的限流工作：权限层级，我们支持 XPack 和自研权限来防止攻击、误操作;队列层级，通过优化任务执行速度、重复、优先级等问题，解决用户常遇到的 Master 任务队列堆积、任务饿死等问题;内存层级，我们从 ES 6.x 开始，支持在 HTTP 入口、协调节点、数据节点等全链路上进行内存限流，同时使用 JVM 内存、梯度统计等方式精准控制;多租户层级，我们使用 CVM/Cgroups 方案保证多租户间的资源隔离。
这里详细介绍下聚合场景限流问题，用户在使用 ES 进行聚合分析时，经常遇到因聚合分桶过多打爆内存的问题。官方在 ES 6.8 中提供 max_buckets 参数控制聚合的最大分桶数，但这个方式局限性非常强。在某些场景下，用户设置 20 万个分桶可以正常工作，但在另一些场景下，可能 10 万个分桶内存就已经打爆，这主要取决于单分桶的大小，用户并不能准确把握该参数设置为多少比较合适。我们在聚合分析的过程中，采用梯度算法进行优化，每分配 1000 个分桶检查一次 JVM 内存，当内存不足时及时中断请求，保证 ES 集群的高可用。具体可参考 PR ES-46751 /47806 。