一、一致性问题概述
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)后再次删除 (应对读线程写入的旧值)
在延迟期间可能存在短暂的不一致，可以通过多次删除 减少不一致时间
优点：捕获可能的脏写
缺点：引入额外开销(删除两次缓存)、增加系统复杂度(引入消息队列，异步延迟删除)
)
