京东千万级秒杀架构升级,半年上线性能还提升90%

平台研发洪超 2021-12-30 10:16:25

京东秒杀是京东最大的营销频道,近年来随着业务的高速发展,频道商品数量和用户流量都呈现出迅猛增长的态势。同时业务方规划未来频道商品数量会增加5至10倍,对商品池扩容诉求较为强烈,这对我们现有的系统架构提出了挑战。

 

为了应对商品数量激增引起的风险,秒杀后台组在年初成立了秒杀商品池扩容技术优化专项,在618前按计划完成了千万级商品池扩容的架构升级。本文主要介绍秒杀商品池扩容专项的优化经验。

 

一、背景

 

京东秒杀频道业务主要包括两部分,一部分是频道核心服务,即直接面向终端用户提供频道服务;另一部分是维护秒杀商品池数据,为商详、购物车等多端提供秒杀商品读服务,以展示“京东秒杀”的促销氛围标签,我们称为秒杀商品打标服务。

 

图片

图1. 京东秒杀频道业务

 

秒杀系统是一个高并发大流量系统,使用缓存技术来提高系统性能。在频道核心服务的历史业务迭代过程中,采用了在内存中全量缓存商品池数据的缓存方案,这是因为频道业务中存在全量商品按照多维度排序的诉求,同时在频道发展初期商品数量不多,采用全量缓存的方式内存压力不大,开发成本较低。由于秒杀商品存在时促销、库存有限的特点,对数据更新的实时性要求较高,我们通过ZK通知的方式实现商品数据更新。

 

原系统架构如图2所示,秒杀CMS系统在商品录入或更新时,以活动的维度将商品数据推动到JIMDB(京东内部分布式缓存与高速键值存储服务,类似于Redis)中,同时通过ZooKeeper发送通知。秒杀SOA系统监听通知后从JIMDB中获取最新的数据,更新本地缓存,以提供频道核心服务和商品打标服务。

 

图片

图2. 京东秒杀原系统架构图

 

二、问题分析

 

在以往大促期间,当商品池数量激增时,观察到系统的堆内存消耗过快,同时Minor GC垃圾回收效果有限,Minor GC回收后堆内存低点不断抬高,堆内存呈持续增长的态势,并且会规律性地定期猛增。Full GC较为频繁,对CPU利用率的影响较大,接口性能毛刺现象严重。

 

图片

图3. 系统异常监控

 

通过JVM堆内存变化图可以看到:

 

  • 堆空间增长很快,且Minor GC无法回收新增的堆空间。

 

  • 堆空间呈现有规律的上升,且会定期猛增,推测和定时任务有关。

 

  • Full GC后,内存回收率高,排除内存泄漏。

 

  • Full GC对CPU利用率影响较大。

 

频繁GC对系统的稳定性和接口的性能造成严重的影响分析堆对象增长情况,通过 jmap -histo 指令在发生Full GC 前后打印JVM堆中的对象,如图4、图5所示:

 

图片

图4. 发生Full GC前堆内存对象

 

图片

图5. 发生Full GC后堆内存对象

 

从Full GC前后堆中对象分布情况分析,以品类秒杀为例,在Full GC 后堆中不到100万商品对象,占内存125M左右,和品类秒杀实际有效商品数量大致相当, String对象共占约385M左右。而在发生Full GC前,堆中品类秒杀商品数量达到了接近500万,占用内存达到了700M, 另外String对象占用内存达到1.2G。

 

结合系统架构分析,可以确定是在商品的覆盖更新过程中,旧对象未被回收而不断进入老年代,老年代内存占用越来越高,最终导致堆内存不足而产生Full GC。堆对象中的String对象也是这种更新方式的副产品,这是因为商品数据在JIMDB中以String方式存储,在更新时会从JIMDB中拉取到本地反序列化后得到对象列表,可以从图6所示问题代码中看到产生大String对象的原因。

 

图片

图6. 问题代码

 

对于上述的全量更新场景,旧对象和临时产生的String对象满足垃圾回收的条件,为什么没有在Minor GC阶段被回收?我们知道大多数情况下,对象在新生代Eden区中分配,对象进入老年代有以下几种情况:

 

  • 大对象直接进入年老代:大对象即需要大量连续内存空间的Java对象,如长字符串及数组。大对象会导致内存剩余空间足够时,就提前触发垃圾收集以获取足够的连续空间来安置,同时大对象的频繁复制也会影响性能。虚拟机提供了一个-XX:PretenureSizeThreshold参数,使大于该阈值的对象直接在老年代分配。为避免临时String对象直接进入老年代的情况,我们显式关闭了该功能。

 

  • 长期存活的对象将进入年老代:虚拟机给每个对象定义了一个对象年龄计数器,在对象在Eden创建并经过第一次Minor GC后仍然存活,并能被Suivivor容纳的话,将会被移动到Survivor空间,并对象年龄设置为1。每经历一次Minor GC,年龄增加1岁,当到达阈值时(可以通过参数-XX: MaxTenuringThreshold设置,CMS垃圾回收器默认值为6),将会晋升老年代。上述分析情况,临时String对象不会存活过6次Minor GC。

 

  • 动态对象年龄判定:为了更好地适应不同程序内存状况,虚拟机并不硬性要求对象年龄达到MaxTenuringThreshold才能晋升老年代,如果在Survivor空间中小于等于某个年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入年老代。

 

通过上述分析,我们发现临时String对象最有可能触发了动态对象年龄判定机制而进入老年代。打印虚拟机GC信息,并添加-XX: +PrintTenuringDistribution 参数来打印发生GC时新生代的对象年龄信息,得到图7所示GC日志信息:

 

图片

图7. GC日志

 

从GC日志可以看到,Survivor空间大小为358M , Survivor区的目标使用率默认是50%,Desired Survivor size 是179M,age <= 2的对象大小总和为269M,因此虽然设定的晋升阈值是6,虚拟机动态计算晋升阈值为2,最终导致age大于等于2的对象都进入老年代。

 

我们尝试从优化JVM参数的方式解决问题,效果并不理想。做过的尝试有:

 

  • 增大年轻代的空间来减少对象进入老年代,结果适得其反,STW更加频繁,CPU利用率波动也更大。

 

  • 改用G1垃圾收集器,效果不明显,CPU利用率波动也更大。

 

  • 显式设置晋升老年代的阈值(MaxTenuringThreshold),试图推迟对象进入老年代的速度,无任何效果。

 

上述问题分析的结论对我们的启示是:如果在新生代中频繁产生朝生夕死的大对象,会触发虚拟机的动态对象年龄判定机制,降低对象进入老年代的门槛,导致堆内存增长过快。

 

三、优化方案

 

 
1、双缓存区定时散列更新

 

通过上面的分析可以发现,为了防止堆内存增长过快,需要控制商品数据更新的粒度和频次。原有的商品更新方案是商品数据按照活动的维度全量覆盖更新,每个商品的状态变化都会触发更新操作。我们希望数据更新能控制在更小的范围,同时能够控制数据更新的频率,最终设计出双缓存区定时散列更新方案,如图8所示。

 

图片

图8. 双缓存区定时散列更新示意图

 

该方案的实现是将活动下的商品以SKU维度散列到不同的桶中,更新的操作以桶的粒度进行。同时为了控制数据更新的频率,我们在SOA端设计了双缓存区定时切量的方式。在CMS商品数据更新时,会映射到需要更新的桶,并实时通知SOA端;在SOA端收到ZK通知后,会在读缓存区标记需要更新的桶,但不会实时的更新数据。在达到定时时间后,会自动切换读写缓存区,此时会读取读缓存区中标记的待更新桶,从JIMDB中获取桶对应的商品列表,完成数据的细粒度分段更新。

 

该方案散列份数和定时时间可以根据具体业务情况进行调整,在性能和实时性上取得平衡,在上线后取得了较好的优化效果。

 

 
2、引入本地LRU缓存

 

双缓存区定时散列更新的方案虽然在系统性能上得到了提升,但依然无法支持千万级商品的扩容。为了彻底摆脱机器内存对商品池容量的限制,我们启动了秒杀架构的全面升级,核心思路是引入本地LRU缓存组件,实现冷数据淘汰,以控制内存中缓存商品的总数量在安全区间。

 

1)系统拆分

 

原系统存在的问题是,频道核心服务和商品打标服务共用相同的基础数据,存在系统耦合的问题。从商品池角度分析,频道核心服务商品池是秒杀商品池的子集。从业务角度分析,频道核心服务业务逻辑复杂,调用链路长,响应时间长,商品打标服务逻辑简单,调用链路短,响应时间短。将频道核心服务和商品打标服务进行拆分,独立部署,实现资源隔离,这样可以根据业务特点做针对性优化。频道核心服务可以减少内存中商品缓存的数量,商品打标服务可以升级商品缓存方案,另外也可以规避架构升级过程中对频道核心服务的影响。

 

图片

图9. 系统拆分

 

2)缓存方案优化

 

频道核心服务历史逻辑复杂,且直接面向终端用户,升级难度大。在扩容专项一期中的主要优化点是拆分出频道核心服务商品池,去除非频道展示商品,以减少商品缓存数量。一期优化主要聚焦于秒杀打标服务的缓存方案升级。在原有的系统架构中秒杀商品池全量缓存在内存中,这会导致商品数量激增时,JVM堆内存资源紧张,商品池的容量受到限制,且无法水平扩容。商品以活动的维度进行存储和更新,会导致大key的问题,在进行覆盖更新时会在内存中产生临时的大对象,不利于JVM垃圾回收表现。

 

图片

图10. 缓存方案升级

 

对于拆封后的商品打标服务,缓存方案优化的总体思路是实现冷热数据的拆分。升级后的商品打标服务不再使用本地全量缓存,而是使用JIMDB全量缓存+本地LRU缓存组件的方式。对缓存组件的要求是在缓存数据达到预设商品数量上限时,实现冷数据的清退,同时具有较高的缓存命中率和读写性能。在对比常用的缓存框架Caffeine和 Guava Cache后最终采用Caffeine缓存,其优势有:

 

  • 性能更优。Caffeine的读写性能显著优于Guava, 这是由于Guava 中读写操作夹杂着过期时间的处理,一次 put 操作中有可能会触发淘汰操作,所以其读写性能会受到一定影响,而 Caffeine 对这些事件的操作是异步的,将事件提交至队列,通过默认的 ForkJoinPool.commonPool()或自己配置的线程池,进行取队列操作,再进行异步淘汰、过期操作。

 

  • 高命中率,低内存占用。Guava 使用分段LRU算法,而Caffeine 使用了一种结合 LRU、LFU 优点的算法:W-TinyLFU,可以使用较少的资源来记录访问频次,同时能够解决稀疏突发访问元素的问题。

 

升级后的架构图如图11所示:

 

图片

图11. 升级后架构图

 

频道核心服务和商品打标服务独立部署,资源隔离。秒杀CMS 在商品录入和更新时,以SKU维度写入JIMDB中组成全量秒杀商品池。商品打标服务通过Caffeine 缓存的方式,设置写入写入30s过期,最大缓存200w商品数据,实现热数据缓存,过期数据和冷数据的淘汰。

 

 
3、引入布隆过滤器

 

在非秒杀SKU查询处理上,为了避免缓存穿透问题(即单个无效商品的高频次查询,如果本地缓存中没有则每次请求都会访问到JIMDB),我们对于非秒杀商品的查询结果,在本地缓存中存储一个空值标识,避免无效SKU请求每次都访问到JIMDB。商详、购物车等渠道商品池数量比秒杀商品池高几个数量级,秒杀查询服务请求SKU中存在大量的非秒杀商品,这会导致本地缓存的命中率降低,同时带来缓存雪崩的风险。

 

为了拦截大量非秒杀SKU的请求,我们引入过滤器机制。在本地过滤器的选择上,我们尝试使用所有有效商品SkuId组成的Set集合来生成本地过滤器,上线后观察到本地过滤器数据更新时会产生性能波动。分析发现这种方式空间复杂度高,内存占用比较高。过滤器优化为布隆过滤器后,内存占用降低,性能得到进一步提升。

 

四、优化效果

 

在完成架构升级后,经过单机压测、灰度验证、灰度上线、全量压测等过程严格验证了新系统的性能和结果准确性,在618大促前新系统全量平稳上线。从近年来大促期间系统表现来看,优化效果显著,如图12、图13所示,主要体现在以下几个方面。

 

图片

图12. 大促性能表现对比

 

  • 业务支撑:秒杀商品池数量持续增长,由于架构的调整全量商品缓存在JIMDB,新系统支持水平扩容,后续可支持更高数量级的商品,满足业务的长期规划。

 

  • 性能优化:大促期间打标服务的接口tp999持续下降,618大促接口性能提升90%,同时从接口性能对比上看,接口性能的毛刺现象得到解决。

 

  •  稳定性提升GC频率持续下降,系统稳定性得到提高。

 

图片

图13. 接口性能监控对比

 

五、总结

 

本次秒杀商品池扩容优化专项通过优化商品更新方式、系统拆分、优化缓存方案等方式,实现了系统架构升级,提升了频道的商品容量和性能,达到了预设目标。

 

作者丨平台研发洪超
来源丨公众号:京东零售技术(ID:jd-sys)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

活动预告