【开发】项目发布引起的思考与总结

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/zhuqiuhui/article/details/83478708

场景

营销系统中经常会有重构一个活动的需求，有时需要推翻原来的方案重新制定新的策略，就需要考虑新旧数据的兼容，若存在缓存的话，也需要考虑缓存的更新，尤其是对于用户流量比较大的活动，下面是一个细化的场景：

旧活动A有着很大的用户流量，QPS经常轻易达到900，新的需求是把旧活动A重构成活动B，同时新增了一部分功能，下面是技术方案的简化点：

• 旧表tab需要新加一个字段field来适应新的活动B，同时要做到旧活动A对field字段的兼容
• 业务中需要增加新的缓存替代已有缓存内容
• 为了保证旧请求能在部署过程中正常请求，所以需要对所有接口增加V2版本接口

思考与方案

先说一下发布流程，便很容易发现具体的问题

上面的技术方案本质上考虑了以下三点：

1. 新业务需要兼容旧数据，同时发布过程中旧的请求可以兼容新的数据

2. DB与缓存的一致性保证

   • 缓存更新

     由于新业务与旧业务逻辑相差较大，所以在原有缓存的基础上新增加了缓存，但由于老活动在缓存中，而新的pc端进行修改，只会清新的缓存不会清老的缓存，这样会导致老缓存信息不对，所以必须在清新的缓存之前清除老的缓存内容

   • 缓存击穿与缓存雪崩

     代码业务中需要考虑缓存击穿，为了克服缓存雪崩，本项目选择时间窗口在凌晨进行发布就有了一定的过渡，不会对DB产生较大的压力

   • 并发可能导致的DB与缓存不一致性

     本项目采用的是先删缓存，再更更新数据库的方式，这样就会有线程安全问题，如：

     （1）请求A进⾏行行写操作，删除缓存

     （2）请求B查询发现缓存不存在

     （3）请求B去数据库查询得到旧值

     （4）请求B将旧值写入缓存

     （5）请求A将新值写入数据库

     解决方式是延时双删

3. 索引与并发的考虑