现在比较常见的缓存读写策略是这样的
写模式
在数据库层前置一道缓存，是为了减轻数据库层面的访问压力。但是同一份数据落在两个系统中，势必会造成数据一致性问题。
比如说：
有多个操作t1、t2执行同时对一份数据进行update，如果t1更新完DB以后，因为某些原因造成一瞬间的延迟，使t2更新完DB以后，先把缓存给改了，这时候t1再执行更新缓存，缓存是t1=a，数据库存的是t2=b，就引发了DB和缓存双写不一致。
无论是先更新DB，再删除缓存，或者是先删除缓存，再更新DB，都无法从根本上解决问题。在同一条时间线上的并发场景下，总会有这样那样的意外。
数据一致性是CAP理论的三大基石之一，强一致性又很难保障，追求强一致性就一定会牺牲部分可用性，所以应当考虑的是在可以容忍的范围内达到数据最终一致性
通过加分布式锁来获得强一致性的做法通常是不受人待见的。
市场上比较主流的方案：
1、延迟双删
在一个线程更新了DB，再删除缓存以后，sleep一小段时间以后再删一次。
2、读写锁。
针对读多写少的场景，读写互斥，写入的时候排队，读取的时候可以并发。这个可以考虑。
3、还有一个离谱的，监听mysql的binlog日志，投递到消息队列中，发出去再更新到缓存中。
4、定时任务，定时同步，
标签：缓存,t2,DB,更新,t1,一致性,双写 来源： https://www.cnblogs.com/hunger-c/p/15208622.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。