分布式缓存一致性问题方案

方案名称	技术特点	优点	缺点	适用	场景说明
数据实时同步更新	强一致性,更新数据库同时更新缓存，使用缓存工具和AOP实现	数据一致性强，不会出现缓存雪崩问题	代码耦合，运行期耦合 ，影响正常业务 ，增加一致网络开销	银行	适合写操作频繁的细粒度缓存数据，数据一致性要求比较高场景，如:银行业务，证券交易；不适合写操作较少粗粒度数据；
数据准实时更新	准一致性，更新数据库后，异步更新缓存，使用AOP进行封装基于多线程或者MQ实现	数据同步有较短延迟，与业务解耦，不影响正常业务，不会出现缓存雪崩问题	有较短延迟，无法保证最终一致性，需要补偿机制	比较优雅	不适合写操作平凡并且数据一致性实时性要求严格的场景(较短不一致，写频繁导致mq消息剧增)
缓存失效机制	弱一致性，基于缓存本身失效机制	实现简单，与业务完美结合，不影响正常业务	有一定延迟，存在缓存雪崩问题	互联网大量使用	不适合写操作平凡并且数据一致性实时性要求严格的场景，适合读多写少的互联网婵娟，能接受一定数据延时；如：电商业务,理财金融(收益第二天更新),社交类业务(点赞)等
任务调度更新	最终一致性，采用任务调度框架，按照一定频率更新	不影响正常业务	不保证一致性，代码复杂度增大(么个value都要维护异步更新代码)，容易堆积垃圾数据	统计类	适合复杂统计类数据缓存更新，对数据一致性实时性要求低的场景，如统计类数据，BI分析等

 

方案1：

 productDao.insert(product);

 redis.delete(productId);

方案2：

productDao.insert(product);

mq.sender(productId);

mq接收客户端收到消息后，从redis获取数据更新；

方案3：

redis.set(productId, expireTime); //例如过期3s, 但是存在缓存雪崩(缓存穿透到数据库)

请参考“缓存雪崩和缓存击穿”。