本文共 825 字，大约阅读时间需要 2 分钟。
| 方案名称 | 技术特点 | 优点 | 缺点 | 适用 | 场景说明 |
| 数据实时同步更新 | 强一致性,更新数据库同时更新缓存，使用缓存工具和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, 但是存在缓存雪崩(缓存穿透到数据库)
请参考“缓存雪崩和缓存击穿”。
转载地址：http://jccpi.baihongyu.com/