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