MySQL与Redis一致性问题分析
一、一致性问题概述
1.1 什么是一致性问题?
在数据库-缓存架构中,当MySQL中的数据(最新值)与Redis缓存中的数据(缓存旧值)出现差异时,由于程序总是优先读取Redis缓存,就会导致应用程序获取到过期数据,这种现象称为缓存一致性问题。
1.2 一致性分类
- 强一致性:读取的数据永远是最新值
- 弱一致性:尽可能的保证某个时间级别后可以读到最新值
要实现强一致性,必然要加锁,不符合缓存思想
所以MySQL与Redis一致性问题是弱一致性问题,要保证的是数据最终一致,且尽可能减少不一致时间
二、一致性解决方案
2.1 基本操作规范
读写线程标准操作:
操作类型 | 处理流程 |
---|---|
读操作 | 1. 检查Redis缓存 2. 命中则返回缓存值 3. 未命中则读取MySQL 4. 将结果写入Redis |
写操作 | 1. 更新MySQL数据 2. 对Redis执行删除或覆盖写 |
2.2 不同场景分析
-
场景1:单线程操作 (无一致性问题)
读线程:Redis值始终为最新值
写线程:删除策略(Redis无数据);覆盖策略(Redis值为最新值)
-
场景2:多个读线程并发 (无一致性问题)
所有读线程读取并写入相同的最新值到Redis (Redis值始终为最新值)
-
场景3:多个写线程并发
覆盖写策略:
相当于双写数据库(需要分布式锁保证一致性)
删除策略:
写线程只删除Redis不更新(Redis无数据)
推荐方案:写线程采用删除策略
-
场景4:读写并发(重点问题)
写线程更新MySQL后删除Redis
在此期间读线程可能:
在MySQL数据被写之前读取到MySQL旧值
在Redis值被删除后将旧值写入Redis
注意到:
读操作(读MySQL+写Redis)通常比写操作(写MySQL+删Redis)快
时间窗口较小但仍可能发生(低概率事件)
我们需要保证 写Redis(旧值) 操作后面存在 删Redis 操作
2.3 解决方案
延迟双删策略:
写线程在更新MySQL前删除Redis (避免MySQL更新时,其他请求读取已失效的缓存)
在更新MySQL后延迟一定时间(如500ms)后再次删除 (应对读线程写入的旧值)
在延迟期间可能存在短暂的不一致,可以通过多次删除 减少不一致时间
优点:捕获可能的脏写
缺点:引入额外开销(删除两次缓存)、增加系统复杂度(引入消息队列,异步延迟删除)