引言
缓存与数据库的一致性即更新数据库中的记录后，缓存的数据也可要同步更新，不然会读到脏数据。事实上我们是无法保证缓存与数据库中的强一致性的，一定会有延迟，我们只能保证其最终一致性。
首先要明确的是，我们不更新缓存的数据，而是删除缓存，然后由下个请求去去缓存，发现不存在后再读取数据库，写入缓存。因为操作简单，带来的副作用也只是一次cache miss而已，删除缓存可能会因为线程安全的原因导致脏数据，比如线程a，b先后更新数据库，但是由于网络阻塞等原因，更新缓存的顺序是b，a，从而导致脏数据。
明确了删除缓存而非更新缓存的原则后，实现一致性无外乎就两种思路：
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
下面我们深入剖析这两种思路，看看谁优谁劣？
先缓存后数据库
考虑这种情况：
（1）请求 A 进行写操作，删除缓存
（2）请求 B 查询发现缓存不存在
（3）请求 B 去数据库查询得到旧值
（4）请求 B 将旧值写入缓存
（5）请求 A 将新值写入数据库
上述情况下，即使A删除了缓存，缓存中依然存在脏数据，如果没有设置过期时间，这个脏数据永远不会被清除。
这么看来这种思路并非最优解，但是上有政策下有对策，聪明的程序员们想到了使用“延迟双删”来解决这个问题。还是这个问题，使用延迟双删是这样执行的：
（1）请求 A 进行写操作，删除缓存
（2）请求 B 查询发现缓存不存在
（3）请求 B 去数据库查询得到旧值
（4）请求 B 将旧值写入缓存
（5）请求 A 将新值写入数据库
（6）请求A休眠一秒，再次删除缓存
延迟双删策略下每次更新数据库都会二次删除缓存，确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
先数据库再缓存
这种方式同样会有问题，考虑这种情况：
（1）缓存刚好失效
（2）请求 A 查询数据库，得一个旧值
（3）请求 B 将新值写入数据库
（4）请求 B 删除缓存
（5）请求 A 将查到的旧值写入缓存
但是实际上很难发生这种情况，因为请求A查询完数据库一般很快就会写入缓存，很难等到 请求B更新完数据库再删除删除 还没写入缓存。如果真发生这种情况，同样可以使用延迟双删解决。
因此，保证缓存与数据库一致性一般情况下应先更新数据库，再删除缓存。
重试机制
看似问题都解决了，其实还有一个因素没有考虑到，那就是缓存删除失败怎么办？无论是第一次还是第二次，只要缓存删除失败都有可能会造成脏数据未被清空，所以我们需要重试机制保证删除缓存成功
方案一：异步重试
把需要删除的key发送至消息队列，自己消费信息，获取需要删除的key进行重试删除操作，直至成功
这种方案的缺点是需要维护消息队列，还会对业务代码造成侵入
方案二：订阅bin log
更新数据库数据时，数据库会将操作信息写入 binlog 日志当中，订阅程序提取出所需要的数据以及 key，另起一段非业务代码，获得该信息，尝试删除缓存操作。发现删除失败将这些信息发送至消息队列 重新从消息队列中获得该数据，重试操作。
总结
如果我们要保证缓存与数据库的一致性，一般情况下选择先更新数据库再删除缓存，配合消息队列或者订阅binlog的方式防止删除缓存失败。此外，如果对缓存中数据的实时性要求不高，可以等待key过期，这样也能保证一致性。
标签：缓存,请求,删除,数据库,写入,更新,并发,一致性 来源： https://blog.csdn.net/qq_46388795/article/details/120470864
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。