版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zhuqiuhui/article/details/83478708
场景
营销系统中经常会有重构一个活动的需求,有时需要推翻原来的方案重新制定新的策略,就需要考虑新旧数据的兼容,若存在缓存的话,也需要考虑缓存的更新,尤其是对于用户流量比较大的活动,下面是一个细化的场景:
旧活动A有着很大的用户流量,QPS经常轻易达到900,新的需求是把旧活动A重构成活动B,同时新增了一部分功能,下面是技术方案的简化点:
- 旧表tab需要新加一个字段field来适应新的活动B,同时要做到旧活动A对field字段的兼容
- 业务中需要增加新的缓存替代已有缓存内容
- 为了保证旧请求能在部署过程中正常请求,所以需要对所有接口增加V2版本接口
思考与方案
先说一下发布流程,便很容易发现具体的问题
上面的技术方案本质上考虑了以下三点:
-
新业务需要兼容旧数据,同时发布过程中旧的请求可以兼容新的数据
-
DB与缓存的一致性保证
-
缓存更新
由于新业务与旧业务逻辑相差较大,所以在原有缓存的基础上新增加了缓存,但由于老活动在缓存中,而新的pc端进行修改,只会清新的缓存不会清老的缓存,这样会导致老缓存信息不对,所以必须在清新的缓存之前清除老的缓存内容
-
缓存击穿与缓存雪崩
代码业务中需要考虑缓存击穿,为了克服缓存雪崩,本项目选择时间窗口在凌晨进行发布就有了一定的过渡,不会对DB产生较大的压力
-
并发可能导致的DB与缓存不一致性
本项目采用的是先删缓存,再更更新数据库的方式,这样就会有线程安全问题,如:
(1)请求A进⾏行行写操作,删除缓存
(2)请求B查询发现缓存不存在
(3)请求B去数据库查询得到旧值
(4)请求B将旧值写入缓存
(5)请求A将新值写入数据库
解决方式是延时双删
-
-
索引与并发的考虑