缓存和数据库一致性问题.docx

《缓存和数据库一致性问题.docx》由会员分享，可在线阅读，更多相关《缓存和数据库一致性问题.docx（22页珍藏版）》请在第一文库网上搜索。

1、缓存和数据库一致性问题，看这篇就够了如何保证缓存和数据库一致性，这是一个老生常谈的话题了。但很多人对这个问题，依旧有很多疑惑：到底是更新缓存还是删缓存？到底选择先更新数据库，再删除缓存，还是先删除缓存，再更新数据库？为什么要引入消息队列保证一致性？延迟双删会有什么问题？到底要不要用？ 这篇文章，我们就来把这些问题讲清楚。这篇文章干货很多，希望你可以耐心读完。引入缓存提高性能缓存利用率和一致性问题并发引发的一致性问题本文大纲删除缓存可以保证一致性吗?如何保证两步都执行成功？主从库延迟和延迟双删问题可以做到强一致吗？引入缓存提高性能我们从最简单的场景开始讲起。如果你的业务处于起步阶段，流量非常小，

2、那无论是读请求还是写请求，直接操作数据库即可，这时你的架构模型是这样的：但随着业务量的增长，你的项目请求量越来越大，这时如果每次都从数据库中读数据，那肯定会有性能问题。这个阶段通常的做法是，引入缓存来提高读性能，架构模型就变成了这样：当下优秀的缓存中间件，当属Redis莫属，它不仅性能非常高，还提供了很多友好的数据类型，可以很好地满足我们的业务需求。但引入缓存之后，你就会面临一个问题：之前数据只存在数据库中，现在要放到缓存中读取，具体要怎么存呢？最简单直接的方案是I全量数据刷到缓存中：数据库的数据，全量刷入缓存（不设置失效时间）写请求只更新数据库，不更新缓存启动一个定时任务，定时把数据库的数据

3、，更新到缓存中这个方案的优点是，所有读请求都可以直接命中缓存，不需要再查数据库，性能非常高。但缺点也很明显，有2个问题：1.缓存利用率低：不经常访问的数据，还一直留在缓存中2. 数据不一致：因为是定时刷新缓存，缓存和数据库存在不一致（取决于定时任务的执行频率）所以，这种方案一般更适合业务体量小，且对数据一致性要求不高的业务场景。那如果我们的业务体量很大，怎么解决这2个问题呢？缓存利用率和一致性问题先来看第一个问题，如何提高缓存利用率？想要缓存利用率最大化，我们很容易想到的方案是，缓存中只保留最近访问的热数据。但具体要怎么做呢？我们可以这样优化：写请求依旧只写数据库读请求先读缓存，如果缓存不存在

4、，则从数据库读取，并重建缓存同时，写入缓存中的数据，都设置失效时间这样一来，缓存中不经常访问的数据，随着时间的推移，都会逐渐过期淘汰掉,最终缓存中保留的，都是经常被访问的热数据，缓存利用率得以最大化。再来看数据一致性问题。要想保证缓存和数据库实时一致，那就不能再用定时任务刷新缓存了。所以，当数据发生更新时，我们不仅要操作数据库，还要一并操作缓存。具体操作就是，修改一条数据时，不仅要更新数据库，也要连带缓存一起更新。但数据库和缓存都更新，又存在先后问题，那对应的方案就有2个：1. 先更新缓存，后更新数据库2. 先更新数据库，后更新缓存哪个方案更好呢？先不考虑并发问题，正常情况下，无论谁先谁后，都

5、可以让两者保持一致，但现在我们需要重点考虑异常情况。因为操作分为两步，那么就很有可能存在第一步成功、第二步失败的情况发生。这2种方案我们一个个来分析。1）先更新缓存，后更新数据库如果缓存更新成功了，但数据库更新失败，那么此时缓存中是最新值，但数据库中是旧值。虽然此时读请求可以命中缓存，拿到正确的值，但是，一旦缓存失效，就会从数据库中读取到旧值，重建缓存也是这个旧值。这时用户会发现自己之前修改的数据又变回去了，对业务造成影响。2）先更新数据库，后更新缓存如果数据库更新成功了，但缓存更新失败，那么此时数据库中是最新值，缓存中是旧值。之后的读请求读到的都是旧数据，只有当缓存失效后，才能从数据库中得到

6、正确的值。这时用户会发现，自己刚刚修改了数据，但却看不到变更，一段时间过后，数据才变更过来，对业务也会有影响。可见，无论谁先谁后，但凡后者发生异常，就会对业务造成影响。那怎么解决这个问题呢？别急，后面我会详细给出对应的解决方案。我们继续分析，除了操作失败问题，还有什么场景会影响数据一致性？这里我们还需要重点关注：并发问题。并发引发的一致性问题假设我们采用先更新数据库，再更新缓存的方案，并且两步都可以成功执行的前提下，如果存在并发，情况会是怎样的呢？有线程A和线程B两个线程，需要更新同一条数据，会发生这样的场景：1. 线程A更新数据库(X = 1)2. 线程B更新数据库(X = 2)3. 线程B

7、更新缓存(X = 2)4. 线程A更新缓存(X = 1)最终X的值在缓存中是1,在数据库中是2,发生不一致。也就是说，A虽然先于B发生，但B操作数据库和缓存的时间，却要比A的时间短，执行时序发生错乱，最终这条数据结果是不符合预期的。同样地，采用先更新缓存，再更新数据库的方案，也会有类似问题，这里不再详述。除此之外，我们从缓存利用率的角度来评估这个方案，也是不太推荐的。这是因为每次数据发生变更，都无脑更新缓存，但是缓存中的数据不一定会被而且很多情况下，写到缓存中的值，并不是与数据库中的值一一对应的，很有可能是先查询数据库，再经过一系列计算得出一个值，才把这个值才写到缓存中。由此可见，这种更新数据

8、库+更新缓存的方案，不仅缓存利用率不高，还会造成机器性能的浪费。所以此时我们需要考虑另外一种方案：删除缓存。删除缓存可以保证一致性吗？删除缓存对应的方案也有2种：1. 先删除缓存，后更新数据库2. 先更新数据库，后删除缓存经过前面的分析我们已经得知，但凡第二步操作失败，都会导致数据不一致。这里我不再详述具体场景，你可以按照前面的思路推演一下，就可以看到依旧存在数据不一致的情况。这里我们重点来看并发问题。1）先删除缓存，后更新数据库如果有2个线程耍并发读写数据，可能会发生以下场景:1. 线程A要更新X = 2 （原值X = 1）2. 线程A先删除缓存3. 线程B读缓存，发现不存在，从数据库中读取

9、到旧值（X = 1）4. 线程A将新值写入数据库（X= 2）5. 线程B将旧值写入缓存（X =1）最终X的值在缓存中是1 （旧值），在数据库中是2 （新值），发生不一致。可见，先删除缓存，后更新数据库，当发生读+写并发时，还是存在数据不一致的情况。2）先更新数据库，后删除缓存依旧是2个线程并发读写数据：1. 缓存中X不存在（数据库X = 1）2. 线程A读取数据库，得到旧值（X = 1）3. 线程B更新数据库（X = 2）4. 线程B删除缓存5. 线程A将旧值写入缓存（X =1）最终X的值在缓存中是1 （旧值），在数据库中是2 （新值），也发生不一致。这种情况理论来说是可能发生的，但实际真的有

10、可能发生吗？其实概率很低，这是因为它必须满足3个条件：1. 缓存刚好己失效2. 读请求+写请求并发3. 更新数据库+删除缓存的时间（步骤3-4）,要比读数据库+写缓存时间短（步骤2和5）仔细想一下，条件3发生的概率其实是非常低的。因为写数据库一般会先加锁，所以写数据库，通常是要比读数据库的时间更长的。这么来看，先更新数据库+再删除缓存的方案，是可以保证数据一致性的。所以，我们应该采用这种方案，来操作数据库和缓存。好，解决了并发问题，我们继续来看前面遗留的，第二步执行失败导致数据不一致的问题。如何保证两步都执行成功？前面我们分析到，无论是更新缓存还是删除缓存，只耍第二步发生失败，那么就会导致数据

11、库和缓存不一致。保证第二步成功执行，就是解决问题的关键。想一下，程序在执行过程中发生异常.，最简单的解决办法是什么？答案是：重试。是的，其实这里我们也可以这样做。无论是先操作缓存，还是先操作数据库，但凡后者执行失败了，我们就可以发起重试，尽可能地去做补偿。那这是不是意味着，只要执行失败，我们无脑重试就可以了呢？答案是否定的。现实情况往往没有想的这么简单，失败后立即重试的问题在于：立即重试很大概率还会失败重试次数设置多少才合理？重试会一直占用这个线程资源，无法服务其它客户端请求看到了么，虽然我们想通过重试的方式解决问题，但这种同步重试的方案依旧不严谨。那更好的方案应该怎么做？答案是：异步重试。什

12、么是异步重试？其实就是把重试请求写到消息队列中，然后由专门的消费者来重试，直到成功。或者更直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直接放到消息队列中，由消费者来操作缓存。到这里你可能会问，写消息队列也有可能会失败啊？而且，引入消息队列，这又增加了更多的维护成本，这样做值得吗？这个问题很好，但我们思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目重启了，那这次重试请求也就丢失了，那这条数据就一直不一致了。所以，这里我们必须把重试或第二步操作放到另一个服务中，这个服务用消息队列最为合适。这是因为消息队列的特性，正好符合我们的需求：消息队列保证可靠性

13、：写到队列中的消息，成功消费之前不会丢失（重启项目也不担心）消息队列保证消息成功投递：下游从队列拉取消息，成功消费后才会删除消息，否则还会继续投递消息给消费者（符合我们重试的场景）至于写队列失败和消息队列的维护成本问题：写队列失败：操作缓存和写消息队列，同时失败的概率其实是很小的维护成本：我们项目中一般都会用到消息队列，维护成本并没有新增很多所以，引入消息队列来解决这个问题，是比较合适的。这时架构模型就变成了这样:那如果你确实不想在应用中去写消息队列，是否有更简单的方案，同时乂可以保证一致性呢？方案还是有的，这就是近几年比较流行的解决方案：订阅数据库变更日志，再操作缓存。具体来讲就是，我们的业

14、务应用在修改数据时，只需修改数据库，无需操作缓存。那什么时候操作缓存呢？这就和数据库的变更日志有关了。拿MySQL举例，当一条数据发生修改时，MySQL就会产生一条变更日志（Binlog）,我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存。订阅变更日志，目前也有了比较成熟的开源中间件，例如阿里的canal,使用这种方案的优点在于：无需考虑写消息队列失败情况：只要写MySQL成功，Binlog肯定会有自动投递到下游队列：canal自动把数据库变更日志投递给下游的消息队列当然，与此同时，我们需要投入精力去维护canal的高可用和稳定性。如果你有留意观察很多数据库的特性，就会发现其实很多数据库都逐渐开始提供订阅变更日志的功能了，相信不远的将来，我们就不用通过中间件来拉取日志，自己写程序就可以订阅变更日志了，这样可以进一步简化流程。至此，我们可以得出结论，想要保证数据库和缓存一致性，推荐采用I先更新数据库，再删除缓存方案，并配合消息队列或订阅变更日志的方式来做。主从库延迟和延迟双删问题到这里，还有2个问题，是我们没有重点分析过的。第一个问题，还记得前面讲到的先删除缓存，再更新数据库方案，导致不一致的场景么？这里我再把例子拿过来让你复习一下