分布式搜索分析引擎Elasticsearch实现亿万级搜索的秘密

容灾方案方面，我们通过扩展 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。

我们当前的限流方案，能够大幅提升在异常查询、压力过载、单节点故障、网络分区等场景下，ES 服务的稳定性问题。但还有少量场景没有覆盖完全，所以我们目前也在引入混沌测试，依赖混沌测试来覆盖更多异常场景。

前面我们介绍了高可用解决方案，下面我们来介绍成本方面的优化实践。成本方面的挑战，主要体现在以日志、监控为代表的时序场景对机器资源的消耗，我们对线上典型的日志、时序业务进行分析，总体来看，硬盘、内存、计算资源的成本比例接近 8:4:1，硬盘、内存是主要矛盾，其次是计算成本。

而对时序类场景进行分析，可以发现时序数据有很明显的访问特性。一是冷热特性，时序数据访问具有近多远少的特点，最近 7 天数据的访问量占比可达到 95%以上；历史数据访问较少，且通常都是访问统计类信息。

基于这些瓶颈分析和数据访问特性，我们来介绍成本优化的解决方案。

硬盘成本方面，由于数据具有明显的冷热特性，首先我们采用冷热分离架构，使用混合存储的方案来平衡成本、性能；其次，既然对历史数据通常都是访问统计信息，那么以通过预计算来换取存储和性能，后面会展开介绍；如果历史数据完全不使用，也可以备份到更廉价的存储系统；其他一些优化方式包含存储裁剪、生命周期管理等。

内存成本方面，很多用户在使用大存储机型时会发现，存储资源才用了百分之二十，内存已经不足。其实基于时序数据的访问特性，我们可以利用 Cache 进行优化，后面会展开介绍。

我们展开介绍下 Rollup 部分。官方从 ES 6.x 开始推出 Rollup，实际上腾讯在 5.x 已经开始这部分的实践。Rollup 类似于大数据场景下的 Cube、物化视图，它的核心思想是通过预计算提前生成统计信息，释放掉原始粒度数据，从而降低存储成本、提高查询性能，通常会有数据级的收益。这里举个简单的例子，比如在机器监控场景下，原始粒度的监控数据是 10 秒级的，而一个月之前的监控数据，一般只需要查看小时粒度，这即是一个 Rollup 应用场景。

在大数据领域，传统的方案是依赖外部离线计算系统，周期性的读取全量数据进行计算，这种方式计算开销、维护成本高。谷歌的广告指标系统 Mesa 采用持续生成方案，数据写入时系统给每个 Rollup 产生一份输入数据，并对数据进行排序，底层在 Compact/Merge 过程中通过多路归并完成 Rollup，这种方式的计算、维护成本相对较低。ES 从 6.x 开始支持数据排序，我们通过流式查询进行多路归并生成 Rollup，最终计算开销小于全量数据写入时 CPU 开销的 10%，内存使用小于 10MB。我们已反馈内核优化至开源社区，解决开源 Rollup 的计算、内存瓶颈，具体可参考 PR ES-48399。

接下来，我们展开介绍内存优化部分。前面提到很多用户在使用大存储机型时，内存优先成为瓶颈、硬盘不能充分利用的问题，主要瓶颈在于索引占用大量内存。但是我们知道时序类场景对历史数据访问很少，部分场景下某些字段基本不使用，所我们可以通过引入 Cache 来提高内存利用效率。

在内存优化方面，业界的方案是什么样的呢？ES 社区从 7.x 后支持索引放于堆外，和 DocValue 一样按需加载。但这种方式不好的地方在于索引和数据的重要性完全不同，一个大查询很容易导致索引被淘汰，后续查询性能倍数级的衰减。Hbase 通过缓存 Cache 缓存索引、数据块，提升热数据访问性能，并且从 HBase 2.0 开始，重点介绍其 Off Heap 技术，重点在于堆外内存的访问性能可接近堆内。我们基于社区经验进行迭代，在 ES 中引入 LFU Cache 以提高内存的利用效率，把 Cache 放置在堆外以降低堆内存压力，同时通过 Weak Reference、减少堆内外拷贝等技术降低损耗。最终效果是内存利用率提升 80%，可以充分利用大存储机型，查询性能损耗不超过 2%，GC 开销降低 30%。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!