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算法是治本方案。在此我们两步走,先满足大促峰值性能,再进行提升优化。

2.实时推荐系统性能优化-系统性能瓶颈分析

很多人拿到系统的第一步,估计就是直接看代码,找瓶颈点了。其实这样的效率并不高。很多系统结构复杂,直接修改代码很有可能结果时改了一片代码,最后进行性能测试发现几乎没用提升。这里我们使用jProfiler进行代码性能分析。

继续阅读2.实时推荐系统性能优化-系统性能瓶颈分析

1.实时推荐系统性能优化-背景

18年底时,接手了实时推荐系统。系统设计之初为了进行千人千面,精准营销活动。对用户实时推送广告等消息。由于在经历了18年双11时,系统性能瓶颈,无法满足实时运算需求,导致整体实时推荐服务被降级。所以在接手系统后,必须对系统进行性能优化改造。

此次优化使得系统单机性能由qps30提升至qps300,使得300台服务器集群下可以在大促期间满足qps6万的预期目标。

继续阅读1.实时推荐系统性能优化-背景