分布式搜索分析引擎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%以上；历史数据访问较少，且通常都是访问统计类信息。

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

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

（编辑：PHP编程网 - 湛江站长网）

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