php旅游类网站开发,品牌网站建设方,让互联网之光点亮生活,微信小程序一站式开发继上文在完成了第一阶段 ES 搜索引擎的搭建后#xff0c;已经能够实现对千万级别的商品索引的读写请求的支持。目前#xff0c;单机房读流量在 500#xff5e;1000 QPS 之间#xff0c;写流量在 500 QPS 左右。
但随着业务的发展#xff0c;问题也逐渐开始暴露#xff0…继上文在完成了第一阶段 ES 搜索引擎的搭建后已经能够实现对千万级别的商品索引的读写请求的支持。目前单机房读流量在 5001000 QPS 之间写流量在 500 QPS 左右。
但随着业务的发展问题也逐渐开始暴露起源是在某次活动下线的时候ES 集群某个机房 CPU 迅速被打满读延迟上升而其他机房却是正常的之后仍然出现了多次 CPU 暴涨多个机房的其中一个机房被打满或者同时打满的情形然而读写流量波动却不大或者根本不及日常峰值。我们意识到此时出现的就是 ES 集群的性能问题在第一阶段当系统依赖组件不可用时为此系统拥有一定的容灾能力暂时没有考虑业务使用姿势带来的风险而这种风险是更可怕的源于它随机毫无规律不可控制。
在此情况下也许大家会考虑通过扩容来解决问题但当前情况已经是在我们扩容后发生的问题了所以很明显此时扩容已经解决不了问题了。程序员经常说的几句表达风险等级的话 阶段一不知道自己不知道(Unconscious incompetence) 阶段二知道自己不知道Conscious incompetence 阶段三知道自己知道Conscious competence 阶段四不知道自己知道Unconscious competence
用在此时就是阶段一和阶段二不知道自己不知道所以也就无法在业务风险控制这里发力当问题出现后知道了自己不知道但不知道发生了什么不知道为什么会发生不知道还会发生什么。看似充满随机性但实际上却是一个很严肃的问题招商平台对大促活动非常重要由此也引发了我们新的思考我们做 ES 稳定性的全局视角是什么该怎么定义和归类这些思考也为后续的治理提供了更好的解决思路和发现问题的角度。
治理思路 ES集群读写链路图
在治理思路中我们仍然从系统读写两个入口入手分别细化读和写链路应该考虑的问题和风险以及需要达到的业务目标下文将从具体的实施步骤进行介绍。
治理的目标是什么
治理目标有两个分别是系统的可用性、稳定性和数据质量系统可用性指的是稳定提供读写能力数据质量即保证 ES 的数据和源数据完全一致并且延迟符合业务预期达到不仅有数据而且是有质量的数据标准。
如何量化目标
在量化目标中系统可用性沿用了 ES 集群 SLA 进行衡量可用性。数据质量可以理解为数据最终一致性和数据延迟目前我们核心的数据包含准实时数据流报名记录 DB-ES商品比价通过文档数据库-ES并需要定时更新指标。DB-ES 设定的目标是 30s 内的一致率在 99.9% 以上通过准实时对账进行监控报警监测。
随着商品控价越来越重要比价的数据筛选和查询也尤为重要文档数据库-ES 设定的是不存在超时小时级别的同步延迟且将定时更新指标定为 T1。
如何达成目标
原则自上而下逐层拆解彼此独立互为补充。 优化措施
此时回顾一下上节我们提到的 ES CPU 暴涨问题最后是如何解决的实际上我们并没有走捷径而是将 ES 读链路全部梳理了一遍分析每次 CPU 暴涨的流量差异点。之前的分析仅仅是从 ES 集群监控上分析不同索引的流量趋势由于差异点太小无法进行有效分析。因此我们仍然需要先完善监控报警机制将 ES 上层的云引擎服务的接口流量监控全部聚合在一个监控看板上并加入了 API /中间 RPC 层-- 数据中心 RPC 服务-- ES从而找到了问题的突破口。我们发现CPU 上涨的点 Scroll 流量偏高因为 Scroll 流量比 Search 流量更耗 CPU因此 Scroll 流量会被打满。在明确原因之后我们也就开启了 ES 性能的优化之路。
为什么 ES Scroll 流量比 Search 流量更耗 CPU Search 查询有数据缓存而 Scroll 没有在Search API 中ES 会执行查询并返回匹配的结果集。这些结果通常是直接从索引中检索的并且在查询时可能会使用缓存来提高性能。一旦查询完成ES 会将结果缓存在内存中以便稍后进行排序、分页等操作。这样在后续的请求中如果只需要访问缓存中的数据可以避免重新计算和访问磁盘从而减少了 CPU 的消耗。相比之下Scroll API 在处理流量时不会使用缓存。它的工作方式是创建一个游标Cursor并在服务器端维护一个快照以便在后续的请求中能够继续从上一个请求的位置继续返回结果。这意味着每次请求都需要重新计算和访问磁盘上的数据并且不能利用缓存。这会导致更多的 CPU 计算和磁盘访问从而增加了 CPU 的消耗。 Search 是无状态查询Scroll 需要上下文维护Scroll API 需要维护上下文信息以便在后续的请求中能够正确地返回结果。这个上下文信息可能包括游标位置、排序信息、过滤条件等。为了保持这些上下文的一致性和完整性ES 需要在服务器端维护和更新相关的状态。 这不意味着 Scroll API 一定比 Search API 更耗 CPU。实际的 CPU 消耗还受到多个因素的影响包括查询的复杂性、数据量的大小、硬件配置等需要结合实际情况观测。
ES 查询链路治理
将 ES 不合规的 Scroll 流量全部迁走
在某次大促活动之前招商平台提供的某个活动下报名记录的全量获取接口走的全是 ES Scroll 流量基本维持在 100 QPS 水平大多场景用于离线对账和首次数据拉取我们通过跟业务沟通改离线对账或者走 DB 查询等方式把不合理的 Scroll 查询迁移走。迁移了 Scroll 请求约 30 业务方 QPS 从 100 降到个位数基本解决了 Scroll 场景的性能隐患。
ES 慢查询治理
慢查询是一个相对的概念不是一个绝对的概念不是说某种查询一定是慢查询或者某种查询一定不是慢查询他和数据规模等因素相关性很大。大多都是因为实现方式的原因他的慢会随着数据规模增长而逐渐明显所以支持亿级数据量和万级、百万级完全不是一回事不到一定数据量同样的实现可能也并不会产生问题。
在大规模数据场景下慢查询的慢会越发明显往往慢查询几十的 QPS 就能占用正常查询上千 QPS 所需要的资源。在其它流量突然增加的情况下一般慢查询的耗时会成倍增加也意味着它占用的资源一直得不到释放给系统带来巨大的性能隐患。下面举例说明一些观察到的 ES 慢查询 Terms 查询在每次查询的数量过大时都会导致慢查询系统当时存在每次 Terms 查询 万个商品的场景耗时在 1s商品写流量进来后查询耗时翻好几倍CPU 被打满。 对 Double 类型字段做 Term 查询因为检索方式和数据结构不匹配同样还是因为数据量过大导致慢查询。 高区分度字段 Terms 聚合。
慢查询的规避手段也已经相对比较成熟。可以完善慢查询的监控报警机制在 CPU 使用率是偏高时制定合理的报警阈值。借此我们也梳理了 ES 查询可能存在的慢查询 Case排查其他业务隐患由此慢查询带来的 CPU 上涨问题也已经被排查解决。
Range 查询优化
缓存是提升 ES 查询性能的重要手段如果查询缓存命中率低则可以定向优化。ES Filter 查询的时候会缓存查询频次较高的请求结果然而 Range 查询的特殊点在于如果每次查询的时间区间不一样会导致一直缓存然而命中率极低引发系统频繁 GC从而造成稳定性问题。 优化方法 Range 查询走普通查询不通过 Filter 过滤器缓存。 优化 Range 查询比如指定时间区间查询提高分片维度请求缓存命中率并降低缓存频繁构建和垃圾回收频率。仅查询需要的字段
在我们的系统中就曾出现过获取活动列表活动的配置非常大流量变高时迅速把 CPU 打满的问题。主要因为 ES 查询默认是 query_then_fetch 模式如果业务的索引文档比较大每次查询都返回整个索引文档的话那么 Fetch 的耗时就会变高造成慢查询或者内存被打爆的情况所以仅查询需要的字段可以节省带宽和磁盘访问耗时从而提升查询效率。
ES 写入链路治理
仅写入需要索引的字段
ES 的定位是搜索和统计所以我们在后面的治理中也是非常谨慎对待需要写入 ES 的字段仅写入索引和统计字段其它数据则可以回表查询该方式可以避免索引膨胀速度过快影响查询和索引重建效率也是更多资源的浪费。
Nested 索引优化
索引通常会面临父子文档关联文档这样的查询场景有的还要求子文档能够独立搜索Nested 类型就是 ES 帮甲方解决此类问题的。Nested 其实是非常好的一个设计性能也很优越但它的前提是子文档不能太大子文档深度不能太深文档膨胀相对可控查询方式友好总之大数据规模使用 Nested需要多加前提能不用就不用小数据规模就不用太有负担。
Nested 的查询和索引性能都稍逊于普通索引类型通常是普通索引好几倍的资源消耗我们为了解决商品索引 SPU-SKU Nested 慢查询问题以及降低索引膨胀速度通过将 ES 的 SKU Nested 索引设置为 Object 类型并且把 SKU 维度的信息计算结果作为 SPU 字段共同提供简单查询满足业务查询需要这样我们既做到了业务无损也降低了系统压力。通过以上优化我们的写入膨胀系数降低了 20 倍左右文档数从 40 亿缩减到了 2 亿并通过压测佐证写入性能提升了 20%也不会再高频出现该类慢查询的情况。
消息乱序问题
RocketMQ 乱序问题 通过 Client SDK 发送数据时如果发送失败则会快速重试发送到其它 Queue此时同一个 Key 的消息在不同的 Queue 中造成消息乱序到达 ES RocketMQ 如果出现发生 Rebalance可能会导致同一组消息同时给多个消费者消费从而发生 ABA 覆盖写问题。
以上都会造成丢失更新的问题所以需要利用 RocketMQ 来保证有序性但也并不能达到 100% 的效果。我们在比价消费场景中就曾遇到问题一个报名商品有 N 个 SKU会分别进行站内外比价以及自身比价结果计算基本上都是并发进行的这就导致多个比价结果在同一时刻到达其中一个消息在写入时发生失败自动重试写入到其它 Queue即发生了比价消息更新覆盖的问题。在具体的解决过程中我们设计了如下三个方案 采用比价的 Version 乐观锁控制采用 ScriptVerison 写但是由于 Script 的写入性能不高而且比价目前的写入流量最高 2k未来随着商品量级增加会更多所以未采用。 采用 ES 的 Version 版本号控制写入时带上 Version 版本号但是因为前面介绍过我们的一条报名记录会有多个写入入口全局 Version 版本号的形式成本太高也未采用。 ✅ 采用批量聚合消费的方式。即 FaaS 单条消费改为批量消费按照最大消息数或者聚合时间消费聚合这样可以处理单条消息并发更新的 Case。采用该方式首先因为改动成本低本身的 SDK 也能够支持可以聚焦解决问题少量 Case 依然使用对账 T1 补偿的方式。
ES 资源隔离
目前我们的 ES 集群承载着所有招商需要的 ES 索引的流量包括活动、企划、报名实体索引等目前的稳定性保障预期总读流量可以支持 2000 QPS写流量 6000 QPS。然而在压测时使用线上真实流量压测我们在分别压读、压写同时压读和写通过控制变量的方式压测时发现读流量的资源倾斜非常严重部分节点的 CPU 使用率很高整体压不上去。通过分析后发现是因为不同索引的分片分布不一样导致的所以读写流量分布不均并且不同索引的重保等级是不一样的介于此原因我们认为资源隔离可以更好的规避风险提高系统可用性根据不同的分片分布特性分配不同的 ES 集群规格也有利于资源使用率最大化。
治理效果 ES 集群资源使用情况符合预期不再出现 CPU 暴涨、CPU 被打满、持续慢查询情况基本解决了非预期的 CPU 增长问题系统性能保持稳定。 ES 索引文档数从 40 亿缩减到 2 亿ES 写性能提升 20%写入 QPS 最高可支持 1w性能上可以超出业务需求满足业务使用。
当然在每次活动之前我们也都会结合稳定性的治理 House 来分析容量变化、流量变化、监控报警并根据需求定向优化以上几个方面保证每一次的系统变化都在预期范围内把一切不确定因素变得确定。当然在未来的实践中仍需不断探索挖掘 ES 在实践能力上的更多可能性。
