网站系统建设招标,做暧暧暖网站,wordpress支付宝流程,WordPress 百度联盟优化主题前言 数据库和缓存#xff08;比如#xff1a;redis#xff09;双写数据一致性问题#xff0c;是一个跟开发语言无关的公共问题。尤其在高并发的场景下#xff0c;这个问题变得更加严重。 我很负责的告诉大家#xff0c;该问题无论在面试#xff0c;还是工作中遇到的概率…前言 数据库和缓存比如redis双写数据一致性问题是一个跟开发语言无关的公共问题。尤其在高并发的场景下这个问题变得更加严重。 我很负责的告诉大家该问题无论在面试还是工作中遇到的概率非常大所以非常有必要跟大家一起探讨一下。 今天这篇文章我会从浅入深跟大家一起聊聊数据库和缓存双写数据一致性问题常见的解决方案这些方案中可能存在的坑以及最优方案是什么。 1、 常见方案 通常情况下我们使用缓存的主要目的是为了提升查询的性能。大多数情况下我们是这样使用缓存的 用户请求过来之后先查缓存有没有数据如果有则直接返回。 如果缓存没数据再继续查数据库。 如果数据库有数据则将查询出来的数据放入缓存中然后返回该数据。 如果数据库也没数据则直接返回空。 这是缓存非常常见的用法。一眼看上去好像没有啥问题。 但你忽略了一个非常重要的细节如果数据库中的某条数据放入缓存之后又立马被更新了那么该如何更新缓存呢 不更新缓存行不行 答当然不行如果不更新缓存在很长的一段时间内决定于缓存的过期时间用户请求从缓存中获取到的都可能是旧值而非数据库的最新值。这不是有数据不一致的问题 那么我们该如何更新缓存呢 目前有以下4种方案 先写缓存再写数据库 先写数据库再写缓存 先删缓存再写数据库 先写数据库再删缓存 接下来我们详细说说这4种方案。 2、先写缓存再写数据库 对于更新缓存的方案很多人第一个想到的可能是在写操作中直接更新缓存写缓存更直接明了。 那么问题来了在写操作中到底是先写缓存还是先写数据库呢 我们在这里先聊聊先写缓存再写数据库的情况因为它的问题最严重。 某一个用户的每一次写操作如果刚写完缓存突然网络出现了异常导致写数据库失败了。其结果是缓存更新成了最新数据但数据库没有这样缓存中的数据不就变成脏数据了如果此时该用户的查询请求正好读取到该数据就会出现问题因为该数据在数据库中根本不存在这个问题非常严重。 我们都知道缓存的主要目的是把数据库的数据临时保存在内存便于后续的查询提升查询速度。 但如果某条数据在数据库中都不存在你缓存这种“假数据”又有啥意义呢 因此先写缓存再写数据库的方案是不可取的在实际工作中用得不多。 3、先写数据库再写缓存 既然上面的方案行不通接下来聊聊先写数据库再写缓存的方案该方案在低并发编程中有人在用我猜的。 用户的写操作先写数据库再写缓存可以避免之前“假数据”的问题。但它却带来了新的问题。 什么问题呢 3.1 写缓存失败了 如果把写数据库和写缓存操作放在同一个事务当中当写缓存失败了我们可以把写入数据库的数据进行回滚。 如果是并发量比较小对接口性能要求不太高的系统可以这么玩。 但如果在高并发的业务场景中写数据库和写缓存都属于远程操作。为了防止出现大事务造成的死锁问题通常建议写数据库和写缓存不要放在同一个事务中。 也就是说在该方案中如果写数据库成功了但写缓存失败了数据库中已写入的数据不会回滚。 这就会出现数据库是新数据而缓存是旧数据两边数据不一致的情况。 3.2 高并发下的问题 假设在高并发的场景中针对同一个用户的同一条数据有两个写数据请求a和b它们同时请求到业务系统。 其中请求a获取的是旧数据而请求b获取的是新数据如下图所示 请求a先过来刚写完了数据库。但由于网络原因卡顿了一下还没来得及写缓存。 这时候请求b过来了先写了数据库。 接下来请求b顺利写了缓存。 此时请求a卡顿结束也写了缓存。 很显然在这个过程当中请求b在缓存中的新数据被请求a的旧数据覆盖了。 也就是说在高并发场景中如果多个线程同时执行先写数据库再写缓存的操作可能会出现数据库是新值而缓存中是旧值两边数据不一致的情况。 3.3、浪费系统资源 该方案还有一个比较大的问题就是每个写操作写完数据库会马上写缓存比较浪费系统资源。 为什么这么说呢 你可以试想一下如果写的缓存并不是简单的数据内容而是要经过非常复杂的计算得出的最终结果。这样每写一次缓存都需要经过一次非常复杂的计算不是非常浪费系统资源吗 尤其是cpu和内存资源。 还有些业务场景比较特殊写多读少。 如果在这类业务场景中每个用的写操作都需要写一次缓存有点得不偿失。 由此可见在高并发的场景中先写数据库再写缓存这套方案问题挺多的也不太建议使用。 如果你已经用了赶紧看看踩坑了没 4. 先删缓存再写数据库 通过上面的内容我们得知如果直接更新缓存的问题很多。 那么为何我们不能换一种思路不去直接更新缓存而改为删除缓存呢 删除缓存方案同样有两种 先删缓存再写数据库 先写数据库再删缓存 我们一起先看看先删缓存再写数据库的情况。 说白了在用户的写操作中先执行删除缓存操作再去写数据库。这套方案可以是可以但也会有一样问题。 4.1 高并发下的问题 假设在高并发的场景中同一个用户的同一条数据有一个读数据请求 c还有另一个写数据请求 d一个更新操作同时请求到业务系统。如下图所示 请求 d 先过来把缓存删除了。但由于网络原因卡顿了一下还没来得及写数据库。 这时请求 c 过来了先查缓存发现没数据再查数据库有数据但是旧值。 请求 c 将数据库中的旧值更新到缓存中。 此时请求 d 卡顿结束把新值写入数据库。 在这个过程当中请求 d 的新值并没有被请求 c 写入缓存同样会导致缓存和数据库的数据不一致的情况。 那么这种场景的数据不一致问题能否解决呢 4.2 缓存双删 在上面的业务场景中一个读数据请求一个写数据请求。当写数据请求把缓存删了之后读数据请求可能把当时从数据库查询出来的旧值写入缓存当中。 有人说还不好办请求 d 在写完数据库之后把缓存重新删一次不就行了 这就是我们所说的缓存双删即在写数据库之前删除一次写完数据库后再删除一次。 该方案有个非常关键的地方是第二次删除缓存并非立马就删而是要在一定的时间间隔之后。 我们再重新回顾一下高并发下一个读数据请求一个写数据请求导致数据不一致的产生过程 请求 d 先过来把缓存删除了。但由于网络原因卡顿了一下还没来得及写数据库。 这时请求 c 过来了先查缓存发现没数据再查数据库有数据但是旧值。 请求 c 将数据库中的旧值更新到缓存中。 此时请求 d 卡顿结束把新值写入数据库。 一段时间之后比如500ms请求 d 将缓存删除。 这样来看确实可以解决缓存不一致问题。 那么为什么一定要间隔一段时间之后才能删除缓存呢 请求 d 卡顿结束把新值写入数据库后请求 c 将数据库中的旧值更新到缓存中。 此时如果请求 d 删除太快在请求 c 将数据库中的旧值更新到缓存之前就已经把缓存删除了这次删除就没任何意义。必须要在请求 c 更新缓存之后再删除缓存才能把旧值及时删除了。 所以需要在请求 d 中加一个时间间隔确保请求 c或者类似于请求 c 的其他请求如果在缓存中设置了旧值最终都能够被请求 d 删除掉。 接下来还有一个问题如果第二次删除缓存时删除失败了该怎么办 这里先留点悬念后面会详细说。 5. 先写数据库再删缓存 从前面得知先删缓存再写数据库在并发的情况下也可能会出现缓存和数据库的数据不一致的情况。 那么我们只能寄希望于最后的方案了。 接下来我们重点看看先写数据库再删缓存的方案。 在高并发的场景中有一个读数据请求有一个写数据请求更新过程如下 请求 e 先写数据库由于网络原因卡顿了一下没有来得及删除缓存。 请求 f 查询缓存发现缓存中有数据直接返回该数据。 请求 e 删除缓存。 在这个过程中只有请求 f 读了一次旧数据后来旧数据被请求 e 及时删除了看起来问题不大。 但如果是读数据请求先过来呢 请求 f 查询缓存发现缓存中有数据直接返回该数据。 请求 e 先写数据库。 请求 e 删除缓存。 这种情况看起来也没问题呀 答对的。 但就怕出现下面这种情况即缓存自己失效了。如下图所示 缓存过期时间到了自动失效。 请求 f 查询缓存发缓存中没有数据查询数据库的旧值但由于网络原因卡顿了没有来得及更新缓存。 请求 e 先写数据库接着删除了缓存。 请求 f 更新旧值到缓存中。 这时缓存和数据库的数据同样出现不一致的情况了。 但这种情况还是比较少的需要同时满足以下条件才可以 缓存刚好自动失效。 请求 f 从数据库查出旧值更新缓存的耗时比请求 e 写数据库并且删除缓存的还长。 我们都知道查询数据库的速度一般比写数据库要快更何况写完数据库还要删除缓存。所以绝大多数情况下写数据请求比读数据情况耗时更长。 由此可见系统同时满足上述两个条件的概率非常小。 推荐大家使用先写数据库再删缓存的方案虽说不能 100%避免数据不一致问题但出现该问题的概率相对于其他方案来说是最小的。 但在该方案中如果删除缓存失败了该怎么办呢 6. 删缓存失败怎么办 其实先写数据库再删缓存的方案跟缓存双删的方案一样有一个共同的风险点即如果缓存删除失败了也会导致缓存和数据库的数据不一致。 那么删除缓存失败怎么办呢 答需要加重试机制。 在接口中如果更新了数据库成功了但更新缓存失败了可以立刻重试 3 次。如果其中有任何一次成功则直接返回成功。如果 3 次都失败了则写入数据库准备后续再处理。 当然如果你在接口中直接同步重试该接口并发量比较高的时候可能有点影响接口性能。 这时就需要改成异步重试了。 异步重试方式有很多种比如 每次都单独起一个线程该线程专门做重试的工作。但如果在高并发的场景下可能会创建太多的线程导致系统 OOM 问题不太建议使用。 将重试的任务交给线程池处理但如果服务器重启部分数据可能会丢失。 将重试数据写表然后使用 elastic-job 等定时任务进行重试。 将重试的请求写入 mq 等消息中间件中在 mq 的 consumer 中处理。 订阅 mysql 的 binlog在订阅者中如果发现了更新数据请求则删除相应的缓存。 7. 定时任务 使用定时任务重试的具体方案如下 当用户操作写完数据库但删除缓存失败了需要将用户数据写入重试表中。如下图所示 在定时任务中异步读取重试表中的用户数据。重试表需要记录一个重试次数字段初始值为 0。然后重试 5 次不断删除缓存每重试一次该字段值1。如果其中有任意一次成功了则返回成功。如果重试了 5 次还是失败则我们需要在重试表中记录一个失败的状态等待后续进一步处理。 在高并发场景中定时任务推荐使用elastic-job。相对于 xxl-job 等定时任务它可以分片处理提升处理速度。同时每片的间隔可以设置成1,2,3,5,7 秒等。 如果大家对定时任务比较感兴趣的话可以看看我的另一篇文章《学会这10种定时任务我有点飘了》里面列出了目前最主流的定时任务。 使用定时任务重试的话有个缺点就是实时性没那么高对于实时性要求特别高的业务场景该方案不太适用。但是对于一般场景还是可以用一用的。 但它有一个很大的优点即数据是落库的不会丢数据。 8. mq 在高并发的业务场景中mq消息队列是必不可少的技术之一。它不仅可以异步解耦还能削峰填谷。对保证系统的稳定性是非常有意义的。 对 mq 有兴趣的朋友可以看看我的另一篇文章《mq的那些破事儿》。 mq 的生产者生产了消息之后通过指定的 topic 发送到 mq 服务器。然后 mq 的消费者订阅该 topic 的消息读取消息数据之后做业务逻辑处理。 使用mq重试的具体方案如下 当用户操作写完数据库但删除缓存失败了产生一条 mq 消息发送给 mq 服务器。 mq 消费者读取 mq 消息重试 5 次删除缓存。如果其中有任意一次成功了则返回成功。如果重试了 5 次还是失败则写入死信队列中。 推荐 mq 使用rocketmq重试机制和死信队列默认是支持的。使用起来非常方便而且还支持顺序消息延迟消息和事务消息等多种业务场景。 当然在该方案中删除缓存可以完全走异步。即用户的写操作在写完数据库之后不用立刻删除一次缓存。而直接发送 mq 消息到 mq 服务器然后有 mq 消费者全权负责删除缓存的任务。 因为 mq 的实时性还是比较高的因此改良后的方案也是一种不错的选择 9. binlog 前面我们聊过的无论是定时任务还是 mq消息队列做重试机制对业务都有一定的侵入性。 在使用定时任务的方案中需要在业务代码中增加额外逻辑如果删除缓存失败需要将数据写入重试表。 而使用 mq 的方案中如果删除缓存失败了需要在业务代码中发送 mq 消息到 mq 服务器。 其实还有一种更优雅的实现即监听binlog比如使用canal等中间件。 具体方案如下 在业务接口中写数据库之后就不管了直接返回成功。 mysql 服务器会自动把变更的数据写入 binlog 中。 binlog 订阅者获取变更的数据然后删除缓存。 这套方案中业务接口确实简化了一些流程只用关心数据库操作即可而在 binlog 订阅者中做缓存删除工作。 但如果只是按照图中的方案进行删除缓存只删除了一次也可能会失败。 如何解决这个问题呢 答这就需要加上前面聊过的重试机制了。如果删除缓存失败写入重试表使用定时任务重试。或者写入 mq让 mq 自动重试。 在这里推荐使用mq自动重试机制。 在 binlog 订阅者中如果删除缓存失败则发送一条 mq 消息到 mq 服务器在 mq 消费者中自动重试 5 次。如果有任意一次成功则直接返回成功。如果重试 5 次后还是失败则该消息自动被放入死信队列后面可能需要人工介入。
