3.实时推荐系统性能优化-匹配优化

(1)流程优化

上节说到在实时匹配中,map.putAll被丢入了大量数据导致。由于HashMap这里我们无法得到实质的性能优化,所以只能从业务流程上来进行优化。

我们先来看一下原匹配流程

优化后匹配流程

这里将map.putAll对于结果处理进行前置,通过配置后台更新过配置后,系统先将所有结果集处理完成后,丢入内存。这里对于系统有两点显著提升。

1.系统在匹配时无需对map进行重复计算。节约系统性能开销。

2.系统匹配时无需创建大量map对象,系统young gc次数显著降低。

(2)业务分组

上述优化中,虽然解决了系统中map对象重复多次操作问题。但是对于系统中大量配置的奖品,O(n)复杂度是避免不了的。以此带来的问题是系统使用越久、奖品越多,运算性能将逐渐降低。

解决此问题有两种方式

1.采用rate算法,涉及到系统匹配逻辑重构。

2.奖品分组,降低O(n)中n值得取值范围。

由于时间有限,需赶在618大促前达到预期性能。在刚接手系统随即对系统进行重构难度大、风险高。而且人手有限,整个项目只有我一个人,即要跟进业务需求上线,又需进行系统性能优化。所以这里采用第二种方案,对奖品根据发奖通道进行分组。

尽力保证单一场景下奖品数量在50个左右。相较于无分组时在数千奖品中进行匹配,此优化可以对系统性能带来大幅提升。复杂度问题得解决,使用rate算法是治本方案。在此我们两步走,先满足大促峰值性能,再进行提升优化。

发表评论

电子邮件地址不会被公开。 必填项已用*标注