本周工作小结

     本周做了一个项目,竞价公式优化:CTR预估优化,逻辑其实不太复杂,就是把原来固定值的CTR用一系列的公式计算出来,但整个过程却进行得一波三折。
     自助广告分为merchant-backend和ad-bidding两个工程。merchant-backend主要用来做广告后台的配置以及相关定时任务,ad-bidding则用来实现从APP过来的请求做广告竞价排序,承担高并发的请求。
     1.第一版:merchant定时任务把计算出来的CTR写到redis缓存,用的是hset方法,bidding读取,直接hget。当时这么写是直接参照自助全量定时任务,结果代码review的时候,直接被老大打回了。因为在高并发的情况下,频繁hget会对性能产生很大的影响。有可能导致redis集群挂掉。
     2.第二版:merchant定时任务把计算出来的CTR写到redis缓存,用的是set方法。(其实最开始没必要用hset,因为数据结构比较简单,所以这里改成了set)。bidding读取的时候,使用了redisProxy.getWithLocalCache方法,这是common包自定义方法,作用是先从本地缓存取数据,如果本地缓存取不到,就从redis读取数据再存入到本地缓存,下次直接从本地缓存读取,这样就提高了性能。
     3.第三版:merchant定时任务写到redis缓存set,并持久化到数据库表,方便查看ctr
     本来想这第三版改了没问题,结果晚上上线的时候,发现响应时间持续飙升,最后分析可能是存在缓存穿透的情况。从redis上获取到的对象为null,但是并没有保存到本地缓存。所以下次读取的时候,还是会跳过本地缓存,去请求redis。


image.png

这里有两种解法:1.修改redisProxy.getWithLocalCache这个公共方法,从redis上获取到的对象为null时,也去写本地缓存,但是这样会影响到其他代码;2.以下第四版的方法
     4.第四版:merchant定时任务只写表,不写缓存。bidding实现一个自刷新类 RefreshableLocalCache,启动时会从持久化的表中读取数据,并写入本地缓存,并且实现每隔30分钟刷新缓存。由于每天更新的数据量小,目前大概1400多条,不会占用太多内存,所有暂时采用这个方案。
     5.第五版: 分页读表优化,如果一次性读的表数据过多,会导致慢sql,所以采用分页分批读取
     看起来一个不大的需求,最后却陆陆续续做了一个星期,这说明了完成基本功能很容易,但想要提升性能,必须要下大功夫才行!

你可能感兴趣的:(本周工作小结)