大家好，我是苏三，又和大家见面了。前言数据库和缓存（如redis）的双写数据一致性问题是一个与开发语言无关的公共问题。尤其是在高并发场景下，这个问题就更加严重了。很负责任的告诉大家，遇到这个问题的概率是非常大的，不管是面试还是工作中，所以非常有必要和大家一起探讨。在今天的文章中，我将由浅入深，和大家聊聊数据库和缓存双写数据一致性问题的常见解决方案，这些方案中可能存在的陷阱，以及什么是最优方案。1.常见解决方案通常，使用缓存的主要目的是提高查询性能。大多数情况下，我们是这样使用缓存的：用户请求后，首先检查缓存中是否有数据，有则直接返回。如果缓存中没有数据，则继续检查数据库。如果数据库有数据，将查询到的数据放入缓存，然后返回数据。如果数据库中没有数据，直接返回空。这是缓存的一种非常常见的用法。乍一看，好像没什么问题。但是你忽略了一个很重要的细节：如果数据库中的一条数据放入缓存后立即更新，如何更新缓存？不更新缓存不行吗？答：当然不是，如果不更新Cache，在很长一段时间内（由缓存的过期时间决定），用户请求可能会从缓存中获取旧值，而不是数据库的最新值.这不是数据不一致的问题吗？那么，我们如何更新缓存呢？目前有四种方案：先写缓存，再写数据库。先写入数据库，再写入缓存。先删除缓存，再写入数据库。先写入数据库，再删除缓存。接下来，我们将详细描述这四个选项。2.先写入缓存，再写入数据库。对于更新缓存的方案，很多人首先想到的是在写操作的时候直接更新缓存（writecache），这样比较直接。那么，问题来了：在写操作时，应该先写缓存还是先写数据库？先说写缓存再写数据库的情况，因为这是最严重的问题。对于某个用户的每一次写操作，如果缓存刚刚写入，网络突然出现异常，导致写入数据库失败。因此，缓存会更新为最新数据，但数据库不会。那么缓存中的数据就变成了脏数据？如果用户的查询请求只是读取数据，就会出现问题，因为该数据根本不存在于数据库中，这个问题非常严重。我们都知道缓存的主要目的是将数据库中的数据暂时存放在内存中，方便后续查询，提高查询速度。但是，如果数据库中不存在一条数据，那么缓存这条“假数据”有什么意义呢？因此，不宜先写缓存，再写数据库。实际工作中没有用到。许多。3、先写数据库，再写缓存。既然上面的方案不行，那我们就来说说先写数据库，再写缓存的方案。这种方案用于低并发编程（我猜）。对于用户的写操作，先写入数据库，再写入缓存，可以避免前面的“假数据”问题。但它产生了新的问题。有什么问题？(1)写缓存失败。如果写数据库和写缓存操作放在同一个事务中，当写缓存失败时，我们可以回滚写入数据库的数据。如果是并发量比较小，对接口性能要求不高的系统，可以这么玩。但是在高并发的业务场景下，写数据库和写缓存都是远程操作。为了防止大事务引起的死锁问题，一般建议不要在同一个事务中写数据库和写缓存。也就是说，在这个方案中，如果写数据库成功了，但是写缓存失败了，那么写入数据库的数据是不会回滚的。这样就会出现：数据库是新数据，而缓存是旧数据，两边数据不一致。(2)高并发下的问题假设在高并发场景下，同一个用户对同一条数据有两次写数据请求：a和b，同时请求到业务系统。其中，请求a获取的是旧数据，请求b获取的是新数据，如下图：请求a在前，刚刚写入数据库。但是由于网络原因，一时卡住了，还没来得及写缓存。这时候requestb过来了，先写数据库。接下来请求b成功写入缓存。此时请求a卡住了，缓存也写入了。显然，在这个过程中，请求b在缓存中的新数据被请求a的旧数据覆盖了。也就是说：在高并发场景下，如果多个线程同时执行先写数据库再写缓存的操作，可能数据库有新值而缓存有旧值，并且双方的数据可能不一致。(3)系统资源的浪费这种方案还有一个很大的问题是：每次写操作后，数据库都会立即写入缓存中，这是一种系统资源的浪费。你为什么这么说？你可以想象一下，如果写入缓存的不是简单的数据内容，而是经过非常复杂的计算之后的最终结果。这样，每次写入缓存都需要进行非常复杂的计算，不是浪费系统资源吗？特别是cpu和内存资源。还有一些特殊的业务场景：多写少读。如果在这类业务场景下，每次使用的写操作都需要写入缓存一次，得不偿失。可见，在高并发场景下，先写入数据库，再写入缓存，这种方案存在很多问题，不推荐。如果你已经用过了，赶快看看你有没有踩到坑？4.先删除缓存，再写入数据库。从上面的内容我们知道，如果直接更新缓存，会出现很多问题。那么，我们为什么不能换个思路：不直接更新缓存，而是删除缓存呢？删除缓存也有两种方案：先删除缓存，再写入数据库。先写入数据库，再删除缓存。一起来看看：先删除缓存，再写数据库。说白了就是在用户的写操作中，先进行删除缓存操作，然后再写数据库。这套方案或许可以，但是也会出现同样的问题。(1)高并发下的问题假设在高并发场景下，对于同一个用户的同一条数据，有一个读数据请求c，还有一个写数据请求d（更新操作），请求为同时发送到业务系统。如下图：请求d先到，删除缓存。但是由于网络原因，在写入数据库前卡住了一会。这时候请求c过来了。先查缓存，发现没有数据，再查数据库，有数据，只是旧值。请求c将数据库中的旧值更新到缓存中。至此，请求dfreeze结束，新值写入数据库。在这个过程中，请求d的新值并没有被请求c写入缓存，同样会造成缓存和数据库的数据不一致。那么，这种场景下的数据不一致问题能否解决呢？(2)缓存双删在上面的业务场景中，一个读数据请求，一个写数据请求。当写数据请求删除缓存时，读数据请求可能会将当时从数据库中查询到的旧值写入缓存中。有人说不好办。写完数据库再问d删除缓存还不行吗？这就是我们所说的缓存的双删，即在写数据库之前删除一次，写数据库之后再删除一次。这个解决方案很关键的一点是：第二次删除缓存，不是立即删除，而是在一定时间间隔之后。重温下一次高并发读数据请求和一次写数据请求导致数据不一致的过程：请求d先到，删除缓存。但是由于网络原因，在写入数据库前卡住了一会。这时候请求c过来了。先查缓存，发现没有数据，再查数据库，有数据，只是旧值。请求c将数据库中的旧值更新到缓存中。至此，请求dfreeze结束，新值写入数据库。一段时间后，比如：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订阅者获取更改的数据，然后删除缓存。这个方案中的业务接口确实简化了一些流程，你只需要关心数据库操作，在binlogsubscriber中做缓存删除工作即可。但是，如果只是按照图中的方案删除缓存，而且只删除一次，可能会失败。如何解决这个问题呢？答：这需要加上前面讨论的重试机制。如果删除缓存失败，写入重试表，使用定时任务重试。或者写入mq，让mq自动重试。这里推荐使用mq自动重试机制。如果binlog订阅者删除缓存失败，则向mq服务器发送mq消息，mq消费者自动重试5次。如果有成功，则直接返回成功。如果重试5次还是失败，消息会自动放入死信队列，后期可能需要人工干预。
