MySQL和Redis中数据的一致性的两种解决方案

Redis 在互联网行业中使用最为广泛，常被称为“内存数据库”。它集合了缓存和数据库的优势，但并非开启持久化和主备同步机制就可以高枕无忧。从架构设计的角度思考：缓存就是缓存，缓存数据会随时丢失。缓存存在的目的是拦截数据库请求，相比数据的可靠性、一致性，吞吐量与稳定性优先。

缓存架构主要面临三大矛盾：

第一个矛盾即本文讨论的核心问题。解决这三大矛盾的刷新策略通常包括：

实时策略是最常用且保持实时性最好的策略，其典型模式为 Cache Aside Pattern：

从用户体验的角度，数据库有了写入后，应马上废弃缓存，触发一次数据库读取从而更新缓存。

在高并发业务场景下，数据库通常是用户并发访问最薄弱的环节。因此，需要使用 Redis 做缓冲操作，让请求先访问 Redis 而不是直接访问 MySQL 等数据库，这样可以大大缓解数据库压力。具体业务流程如下：

读取缓存步骤一般没有什么问题，但一旦涉及到数据更新（数据库和缓存同时更新），就容易出现缓存和数据库间的数据一致性问题。不管是先写数据库再删除缓存，还是先删除缓存再写库，都有可能出现数据不一致的情况。举个例子：

因为写和读是并发的，无法保证顺序，就会出现缓存和数据库的数据不一致的问题。如何解决？这里给出两个核心解决方案，先易后难，可结合业务和技术代价选择使用。

一、延时双删策略

在写库前后都进行 redis.del(key) 操作，并且设定合理的超时时间。具体步骤是：

那么，这个 500 毫秒怎么确定的？具体该休眠多久呢？

需要评估自己项目的读数据业务逻辑耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

当然，这种策略还要考虑 Redis 和数据库主从同步的耗时。最后的写数据休眠时间，则在读数据业务逻辑耗时的基础上，加上几百毫秒即可。比如：休眠 1 秒。

从理论上来说，给缓存设置过期时间是保证最终一致性的解决方案。所有的写操作以数据库为准，只要到达缓存过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。

结合双删策略 + 缓存超时设置，这样最差的情况就是在超时时间内数据存在不一致，而且又增加了写请求的耗时。

上述方案有一个缺点：操作完数据库后，由于种种原因删除缓存失败，这时可能就会出现数据不一致的情况。因此，我们需要提供一个保障重试的方案。

具体流程：

然而，该方案有一个缺点：对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的 binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。

具体流程：

以上方案都是在业务中经常会碰到的场景，可以依据业务场景的复杂度和对数据一致性的要求来选择具体的方案。

说明：本文所述架构模式（如延时双删、Cache Aside、Binlog 订阅）为通用设计方案，适用于大多数 MySQL 与 Redis 版本组合。文中流程图链接来源于 2019 年，但核心逻辑至今仍具参考价值。

如果对本文有什么问题或疑问都可以在评论区留言，我看到后会尽量解答。