9. Redis 和数据库数据不一致怎么排查
Redis 和数据库数据不一致，是缓存项目中最常见、也最容易引发线上问题的一类缺陷。页面显示旧价格、用户权限不生效、订单状态不更新、删除后的数据仍然可见、活动配置修改后前台不变，这些现象背后都可能是 Redis 缓存和数据库数据不一致。测试工程师如果能识别这类问题，并且说清楚排查思路，会比只会看页面结果专业很多。
面试中问“Redis 和数据库数据不一致怎么排查”，重点不是让你直接操作 Redis，而是看你是否能从业务现象出发，确认接口返回、数据库真实值、缓存值、缓存刷新逻辑、过期时间、异步消息和多入口缓存。回答时要有步骤、有证据、有项目场景。
一、什么情况下怀疑缓存不一致
常见现象：
- 后台修改商品价格后，前台仍显示旧价格；
- 删除地址后，地址列表仍显示旧地址；
- 修改用户角色后，权限没有变化；
- 订单状态数据库已更新，接口仍返回旧状态；
- 活动配置修改后页面不生效；
- 清除缓存后问题恢复；
- 等待缓存过期后页面恢复正常。
如果数据库是新值，但接口或页面返回旧值，就要怀疑缓存。
二、排查总思路
可以按这个顺序：
确认页面现象 -> 查看接口响应 -> 查询数据库 -> 查看 Redis 缓存 -> 确认更新逻辑 -> 验证 TTL -> 检查异步刷新 -> 验证多入口缓存
核心是用证据证明：数据库和缓存是否真的不一致。
三、第一步：确认接口返回
先不要直接查数据库。要抓包或调用接口，看后端返回什么。
如果页面显示旧值，但接口返回新值，问题可能在前端缓存、页面渲染或浏览器缓存。
如果接口也返回旧值，再继续查数据库和 Redis。
四、第二步：查询数据库真实值
确认数据库中的真实数据。
例如商品价格：
数据库 price = 89
接口返回 price = 99
这说明问题可能在缓存、查询逻辑或数据源。
测试要记录业务 ID，如商品 ID、订单号、用户 ID。
五、第三步：查看 Redis 缓存值
如果有权限，可以查看对应 Redis key。
关注：
- key 是否存在；
- value 是否旧值；
- TTL 是否合理；
- key 命名是否正确；
- 是否存在多个相关 key；
- 列表缓存和详情缓存是否都刷新。
很多问题不是单个 key，而是多个缓存入口不一致。
六、第四步：确认更新逻辑
数据修改后，系统通常应该删除或更新缓存。
排查：
- 修改接口是否执行删除缓存；
- 删除接口是否清理缓存；
- 是否只清了详情缓存，没清列表缓存；
- 是否异步发送刷新消息；
- 刷新消息是否消费；
- 是否因为异常导致缓存清理失败。
测试可以通过日志确认是否执行了缓存删除或刷新逻辑。
七、第五步：检查过期时间 TTL
如果缓存依赖自然过期，就要看 TTL。
问题可能是：
- TTL 设置太长，旧数据持续很久；
- key 没有设置过期时间；
- TTL 设置错误；
- 更新后没有重置 TTL；
- 不同 key 过期时间不一致。
如果等待 TTL 后恢复，说明问题和缓存刷新策略有关。
八、第六步：检查异步刷新链路
有些项目通过 MQ 异步刷新缓存。数据库更新后发送缓存刷新消息，消费者负责删除或重建 Redis。
排查：
- 修改操作是否发送消息；
- 消息是否进入队列；
- 消费者是否消费；
- 消费是否失败；
- 是否有消息积压；
- 是否进入死信队列。
如果消息未消费，缓存就不会刷新。
九、第七步：检查多端和多入口缓存
一个业务可能有多个缓存：
- 商品详情缓存；
- 商品列表缓存；
- 搜索缓存；
- 首页推荐缓存；
- App 端缓存；
- 前端本地缓存。
修改商品价格后，详情页正确但列表页错误，说明可能漏清列表缓存。
测试要覆盖多个入口，不要只测一个页面。
十、项目案例：商品价格不一致
现象：后台把商品价格从 99 改为 89，前台仍显示 99。
排查：
- 抓商品详情接口，接口返回 99；
- 查数据库，price 为 89；
- 查 Redis 商品详情 key，value 为 99；
- 查看修改商品日志，发现只更新数据库，没有删除缓存；
- 手动清缓存后前台显示 89；
- 提交 Bug：商品价格修改后 Redis 缓存未刷新。
十一、项目案例：权限修改不生效
现象：取消用户管理员权限后，该用户仍能访问后台接口。
排查：
- 确认数据库角色已取消；
- 抓接口返回仍有管理员权限；
- 查看 Redis 权限缓存仍是旧角色；
- 退出重新登录后仍不刷新；
- 等待 TTL 后恢复；
- 判断权限缓存刷新不及时，存在安全风险。
权限缓存问题比普通展示问题更严重。
十二、面试回答模板
如果面试官问“Redis 和数据库数据不一致怎么排查”，可以这样回答：
我会先确认页面和接口返回，再查数据库真实值。如果接口返回旧值而数据库是新值，就会怀疑缓存。接着查看 Redis 中对应 key 的值和 TTL，确认是否仍是旧数据。然后排查数据修改时是否删除或更新缓存，是否只清了详情缓存漏了列表缓存，是否通过 MQ 异步刷新但消息未消费。如果清缓存后问题恢复，基本可以定位为缓存刷新问题。提 Bug 时我会附上页面现象、接口响应、数据库值、Redis 值、业务 ID 和操作时间。
十三、常见追问
追问：数据库新值，页面旧值一定是 Redis 问题吗？
不一定。还可能是前端缓存、浏览器缓存、接口查询旧库、搜索索引未更新。要看接口响应和 Redis 值确认。
追问：详情正确列表错误怎么办？
可能漏刷新列表缓存或搜索缓存。要排查多个缓存入口。
追问：没有 Redis 权限怎么排查？
可以通过接口响应、数据库值、清缓存后结果、日志和开发协助确认。
追问：怎么降低不一致风险？
更新数据库后删除缓存、合理 TTL、消息补偿、监控告警、覆盖多入口回归。
十四、练习清单
- 准备商品价格缓存案例；
- 准备权限缓存案例；
- 抓接口返回值；
- 查询数据库真实值；
- 查看 Redis key；
- 查看 TTL；
- 验证清缓存后是否恢复；
- 验证列表和详情一致；
- 检查异步刷新消息；
- 准备排查面试回答。
Redis 和数据库不一致排查，重点是证据链。页面、接口、数据库、缓存、日志和消息链路要串起来，才能准确定位。
配套刷题：