在现代体系中，缓存可以极大地提升性能，减少数据库的压力。
然而，一旦缓存和数据库的数据不一致，就会引发各种诡异的问题。
我们来看看几种常见的解决缓存与数据库不一致的方案，每种方案都有各自的优缺点
先更新缓存，再更新数据库
这种方案看似简单，现实上很少被推荐。
缘故起因在于假如在更新数据库之前发生了错误，缓存中的数据将和数据库中的数据不一致，最终导致更大的问题。
先更新数据库，再更新缓存
这种方法解决了更新缓存失败的问题，但大概引发别的一个问题：
在高并发场景下，数据库已经更新，但缓存还没有更新时，其他哀求大概会读到旧的缓存数据。
先删除缓存，后更新数据库
这种方案在高并发下容易产生问题：
在缓存删除和数据库更新之间的时间窗口内，其他哀求大概会读取到旧的数据，导致短时间内的数据不一致
先更新数据库，后删除缓存
这是较为推荐的一种方法，但在高并发场景下也有一定的局限性：
假如数据库更新成功但缓存删除失败，大概导致短时间内的数据不一致。
强一致性与最终一致性
在讨论一致性的时候，我们经常会提到强一致性和最终一致性。
根据业务需求衡量这两者，是缓存策略筹划中的告急一步。
后面我会给出一个弱一致性的推荐方案，供大家参考。
SpringCache是一个非常实用的缓存管理框架，能资助我们简化缓存操纵。
以下是一个简单的SpringCache配置示例：
缓存预热策略
缓存预热的告急性不问可知，上线后瞬时大流量大概导致缓存击穿。
以下是几种常见的缓存预热方案：
- 启动时加载：体系启动时加载常用数据到缓存。
- 定时加载：定时任务定期加载数据。
- 手动加载：手动实行预热脚本。
推荐方案
综合考虑各种方案的优缺点，我给大家一种工作中真正常用的方案，也是我待过的互联网公司中实践过的方案。
这是一种非常简单且本钱很低的操纵，但能解断交大多数的缓存与数据库不一致问题。
原理很好理解，就是更新数据库之后设置公道的休眠时间，然后再次删除掉其他线程哀求进来导致的旧缓存，最终达到缓存和数据库都是最新数据的目的。
此中休眠时间要根据自身业务的平均耗时来决定，而耽误双删着实就够了，耽误三删只是为了开阔大家的思绪，因为真有些公司删除三次来包管一些极端环境的不一致，但我觉得没必要，太极端就不是弱一致性了。
假如是比力复杂的项目，乃至能再进一步的优化，也就是借用定时任务和MQ来替代休眠线程，实现异步删除缓存，达到弱一致性的结果。
最后说一句(求关注!别白嫖！)
假如这篇文章对您有所资助，或者有所开导的话，求一键三连：点赞、转发、在看。
关注公众号：woniuxgg，在公众号中复兴：笔记 就可以获得蜗牛为你经心准备的java实战语雀笔记，复兴口试、开发手册、有超赞的粉丝福利！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
