旧笔记整理：Redis和Mysql数据一致性问题

产生数据不一致的原因&＃xff1a;

当数据库的数据发生变化的时候&＃xff0c;引入 Redis 缓存以后&＃xff0c;增加了数据操作难度&＃xff0c;既要操作数据库又要操作 Redis&＃xff0c;对 Redis和数据库的操作有 2 种方案&＃xff1a;

1、先操作 Redis&＃xff0c;再操作数据库

2、先操作数据库&＃xff0c;再操作 Redis

我们无论选择以上的哪个方案&＃xff0c;都希望数据操作要么都成功&＃xff0c;要么都失败&＃xff0c;我们不希望看到一个失败&＃xff0c;一个成功的结果&＃xff0c;因为这样就产生了数据不一致的问题。

举个例子说明&＃xff1a;

假设 Redis 里缓存了一个热点商品数据&＃xff0c;有个 key 为 1001 的商品名称为“华为手机”&＃xff0c;数据库里这个 1001 号的商品名称也是华为手机&＃xff1b;此时商家觉得商品名称叫华为手机有点宽泛&＃xff0c;需要精确一下&＃xff0c;把 1001 号商品的名称修改为其对应的具体名称“华为 P40 Pro”。

1、如果我们选择先操作 Redis&＃xff0c;再操作数据库的方案&＃xff0c;当操作 Redis 成功&＃xff0c;操作数据库失败的时候&＃xff0c;Redis 里的名称修改为“华为 P40 Pro”&＃xff0c;但是数据库的名称还是“华为手机”&＃xff0c;产生了数据不一致问题。

2、如果我们选择先操作数据库&＃xff0c;再操作 Redis 的方案&＃xff0c;当操作数据库成功&＃xff0c;操作 Redis 失败的时候&＃xff0c;数据库里的名称修改为“华为 P40 Pro”&＃xff0c;但是 Redis 的名称还是“华为手机”&＃xff0c;产生了数据不一致问题。

由于 Redis 和数据库是 2 个不同的中间件&＃xff0c;我们无法通过事务来很好地解决数据一致性的问题&＃xff0c;因此只能在数据实时一致性和系统性能上做权衡&＃xff0c;选择一个可以接收的方案。

因为数据库是稳定的持久化的系统&＃xff0c;比 Redis可靠&＃xff0c;我们一般都是以数据库的数据为准&＃xff0c;解决这个数据一致性问题的原则就是&＃xff1a;我们可以为 Redis 缓存数据设置一个过期的时间&＃xff0c;当 Redis 数据过期了就去数据库查询&＃xff0c;然后再把数据库的数据写入 Redis 缓存中&＃xff0c;确保数据的一致性。

如果在这个过期时间范围内&＃xff0c;数据发生了更新操作&＃xff0c;当更新操作有一个失败&＃xff0c;有一个成功&＃xff0c;就会产生不一致的问题&＃xff0c;这个过期时间设置的太短了&＃xff0c;数据库的压力还是很大&＃xff0c;过期时间设置的太长了&＃xff0c;不一致性的问题就会凸显&＃xff0c;因此我们需要基于以数据库的数据为准的原则下&＃xff0c;继续探讨数据一致性问题的解决方案。

三、数据更新时&＃xff0c;如何操作 Redis

当数据更新时&＃xff0c;操作数据库我们都很熟悉&＃xff0c;直接更新数据库的值就可以了&＃xff0c;但是操作 Redis&＃xff0c;我们应该怎么办

1、有人会说&＃xff0c;这还不简单&＃xff0c;数据变化时&＃xff0c;直接更新缓存

2、也有人会说数据变化时把缓存的数据删掉&＃xff0c;当查询请求发现缓存没有数据&＃xff0c;就会从数据库加载新的数据。

以上的两种方法都可以&＃xff0c;那我们该如何选择呢&＃xff1f;

如果我们选择更新 Redis 的方案&＃xff0c;我们要评估一下更新的代价大不大&＃xff0c;比如拿到数据更新到 Redis 需要经过很多表的关联查询&＃xff0c;或者多个接口的调用查询&＃xff0c;经过大量计算才能得到数据的话&＃xff0c;就不要使用更新 Redis 的方案了&＃xff0c;因为面对这么复杂的更新流程&＃xff0c;不如直接删掉方便。如果要更新的数据直接可以获取到&＃xff0c;那么选择更新 Redis 的方案就是可行的。

四、选择 Redis 更新方案

1、先更新 Redis&＃xff0c;再更新数据库

首先不推荐选择这种方案。

因为我们的数据一致性的基本原则是以数据库的数据为准&＃xff0c;所以先更新缓存的话&＃xff0c;会存在缓存更新成功&＃xff0c;数据库更新失败的情况&＃xff0c;此时面临的问题就需要回滚掉刚才更新缓存成功的操作&＃xff0c;那么就需要从业务代码里加入很多判断逻辑来处理这种异常&＃xff0c;需要考虑数据变化是 insert,update&＃xff0c;delete 等&＃xff0c;根据不同的场景执行不同的回滚方案&＃xff0c;这种回滚操作比较麻烦&＃xff0c;对我们业务代码的倾入性也比较大&＃xff0c;所以不推荐选择这种方案。

当然&＃xff0c;如果业务层面可以接受这种数据的不一致性&＃xff0c;异常情况就不需要考虑&＃xff0c;选择这种方案也是可以的。

2、先更新数据库&＃xff0c;再更新 Redis

先更新数据库&＃xff0c;再更新 Redis 的方案&＃xff0c;由于把数据库操作放到了前面&＃xff0c;如果数据库操作失败&＃xff0c;那么客户端再发起一次就可以了。

如果数据库操作成功&＃xff0c;Redis 操作失败&＃xff0c;此时由于数据库的数据已经设置成功&＃xff0c;我们的重点就是讨论如何把 Redis的数据操作成功即可。从客户端层面来看&＃xff0c;他提交的数据已经在我们系统里存在了&＃xff0c;此时的问题就是我们系统内部如何解决的问题。

对于 Redis 操作失败&＃xff0c;我们可选的方案有以下几个&＃xff0c;根据业务要求的数据一致性级别&＃xff0c;进行权衡选择即可。

(1)、不做任何操作&＃xff0c;等着Redis里的缓存数据过期后&＃xff0c;自动从数据库同步最新的数据&＃xff0c;此时最严重的数据不一致性周期就是在缓存过期的一段时间&＃xff08;考虑一下这个过期时间的范围&＃xff09;&＃xff1b;如果在这个时间段内&＃xff0c;又有新的更新请求&＃xff0c;也许这次就更新缓存成功了。

(2)、如果数据一致性要求比较高&＃xff0c;那么 Redis 操作失败后&＃xff0c;我们把这个操作记录下来&＃xff0c;异步处理&＃xff0c;用 Redis 的数据去和数据库比对&＃xff0c;如果不一致&＃xff0c;再次更新缓存确保缓存数据与数据库数据一致。

再说删除方案:直接删除 Redis 缓存数据是更加简单的方案&＃xff0c;因为缓存数据删了&＃xff0c;只能从数据库读取了&＃xff0c;这样可以避免不一致性&＃xff0c;互联网公司一般选择删除 Redis 的方案。

1、先更新数据库&＃xff0c;再删除 Redis

我们如果更新数据库成功&＃xff0c;删除 Redis 失败&＃xff0c;那么 Redis 里存放的就是一个旧值&＃xff0c;也就是删除缓存失败导致缓存和数据库的数据不一致了。

对于删除 Redis 失败的异常情况来进行分析&＃xff0c;我们一般有如下的方案&＃xff1a;

(1)、我们可以重试删除&＃xff0c;比如&＃xff1a;我们可以把删除动作发送到消息队列 MQ&＃xff0c;MQ的消费者再去删除这个key&＃xff0c;一致尝试删除操作&＃xff0c;确保缓存删除成功&＃xff0c;这个方案缺陷就是删除缓存的地方&＃xff0c;通过代码实现对业务逻辑产生了入侵。

(2)、另外一种方案&＃xff0c;就是完全异步的方案&＃xff0c;对业务逻辑没有入侵&＃xff0c;通过监听 binlog 的变化来删除缓存。我们更新数据库会产生 binlog&＃xff0c;我们可以用一个服务监听数据库 binlog 的变化&＃xff0c;异步去删除缓存&＃xff0c;阿里开源的 canal 就是可以监听 binlog 的工具&＃xff0c;只要数据发生变化就可以删除 Redis 的数据。

2、先删除 Redis&＃xff0c;再更新数据库

我们如果删除 Redis 缓存成功&＃xff0c;更新数据库失败的话&＃xff0c;因为我们是以数据库为准&＃xff0c;再查一次就可以了&＃xff0c;这个方案看似很理想&＃xff0c;感觉没什么问题&＃xff0c;其实在并发下也可能产生数据一致性问题。

我们先看一个并发环境下的更新和查询流程&＃xff1a;

上面的图表示&＃xff0c;Thread-1 是个更新流程&＃xff0c;Thread-2 是个查询流程&＃xff0c;cpu 执行顺序是&＃xff1a;Thread-1 删除缓存成功&＃xff0c;此时 Thread-2 获取到 CPU 执行查询缓存没有数据&＃xff0c;然后查询数据库把数据库的值写入缓存&＃xff0c;因为此时 Thread-1 更新数据库还没有执行&＃xff0c;所以缓存里的值是一个旧值&＃xff08;old&＃xff09;&＃xff0c;最后 CPU 执行 Thread-1 更新数据库成功的代码&＃xff0c;那么此时数据库的值是新增&＃xff08;new&＃xff09;&＃xff0c;这样就产生了数据不一致行的问题。

代码逻辑

并发不高的情况&＃xff1a;

读: 读redis->没有&＃xff0c;读mysql->把mysql数据写回redis&＃xff0c;有的话直接从redis中取&＃xff1b;

写: 写mysql->成功&＃xff0c;再写redis&＃xff1b;

并发高的情况&＃xff1a;

读: 读redis->没有&＃xff0c;读mysql->把mysql数据写回redis&＃xff0c;有的话直接从redis中取&＃xff1b;

写&＃xff1a;异步化&＃xff0c;先写入redis的缓存&＃xff0c;就直接返回&＃xff1b;定期或特定动作将数据保存到mysql&＃xff0c;可以做到多次更新&＃xff0c;一次保存&＃xff1b;

对于不同业务&＃xff0c;数据应该怎么存储

方式1&＃xff1a;

数据库保存数据&＃xff0c;redis只做缓存
redis启动后&＃xff0c;从数据库加载数据

首先要明确一点&＃xff0c;redis并不适合处理要求强一致性的数据&＃xff0c;所以对于读请求&＃xff1a;

不要求强一致实时性的读请求&＃xff0c;都由redis处理

要求强一致实时性的读请求由数据库处理

优点&＃xff1a;redis启动不用处理redis数据和数据库不一致

缺点&＃xff1a;redis启动会给数据库很大的读压力

方式2&＃xff1a;

数据库和redis分别处理不同的数据类型

数据库处理要求强一致实时性的数据&＃xff0c;例如金融数据、交易数据

redis处理不要求强一致实时性的数据&＃xff0c;例如网站最热贴排行榜