2. 缓存一致性问题怎么测试
缓存一致性是 Redis 和数据库结合使用时最容易出问题的地方。很多项目为了提升查询性能，会把商品、用户、配置、字典、活动、订单状态等热点数据放到 Redis 中。查询时先查缓存，缓存没有再查数据库。这样可以提升响应速度，但也带来一个风险：数据库数据变了，缓存没有及时更新，用户看到的还是旧数据。
面试中问“缓存一致性怎么测试”，不要只说“看 Redis 和数据库是否一致”。更好的回答是：先明确哪些业务数据用了缓存，再设计新增、修改、删除、过期、并发、回滚、异常和多端查询场景，验证缓存和数据库在不同操作后是否保持一致。缓存一致性测试的核心是围绕业务变化验证“用户最终看到的数据是否正确”。
一、什么是缓存一致性
缓存一致性指的是 Redis 中的数据和数据库中的真实数据保持一致，或者在可接受时间内最终一致。
例如商品价格原来是 99，运营改成 89。数据库已经更新为 89，但 Redis 中还是 99，用户页面继续显示 99，这就是缓存不一致。
缓存不一致常见后果：
- 页面显示旧数据；
- 用户权限不生效；
- 库存状态错误；
- 活动配置未刷新；
- 订单状态延迟或错误；
- 删除的数据仍然能查到；
- 自动化断言结果不稳定。
二、缓存一致性的常见更新策略
测试不一定要实现策略，但要知道常见方式。
1. 先更新数据库，再删除缓存
修改数据后删除 Redis 缓存，下次查询重新从数据库加载。
这是比较常见的做法。
2. 先删除缓存，再更新数据库
这种方式可能有并发风险：删除缓存后，有请求读取旧数据库并重新写入缓存。
3. 更新数据库后同步更新缓存
数据库改了，同时更新 Redis。这要求缓存更新逻辑不能漏。
4. 设置过期时间
即使缓存没有主动删除，到期后也会失效。但过期时间内仍可能读到旧数据。
5. 异步刷新缓存
通过 MQ 或任务异步更新缓存，存在短暂延迟，属于最终一致。
测试时要先问清楚项目采用哪种策略，再设计预期结果。
三、缓存一致性测试基本思路
可以按“读 -> 改 -> 再读 -> 验证”的方式设计。
第一步：确认缓存生成
先查询一次数据，让系统把数据写入 Redis。
第二步：修改数据库或业务数据
通过后台接口、管理页面或数据库脚本修改数据。
第三步：再次查询
看前端、接口返回和数据库是否一致。
第四步：判断缓存是否刷新
如果接口返回旧数据，就可能是缓存未删除或未更新。
第五步：等待过期时间
如果项目是最终一致或依赖 TTL，要等过期时间后再次验证。
四、商品信息缓存测试案例
商品详情是最典型场景。
测试步骤：
- 查询商品详情，确认页面显示价格 99；
- 确认 Redis 中已生成商品缓存；
- 后台把商品价格改为 89；
- 再次查询商品详情；
- 预期页面和接口返回 89；
- 如果仍返回 99，说明缓存未刷新；
- 查看 Redis key 是否仍为旧值；
- 查看修改商品时是否执行删除缓存逻辑。
Bug 描述可以写：
后台修改商品价格后，数据库 price 已更新为 89，但前台商品详情接口仍返回 99。等待 5 分钟后仍未刷新，初步判断商品缓存未删除或未同步更新。
五、删除数据后的缓存一致性
删除场景很容易漏测。
比如用户删除收货地址后，数据库中地址已删除，但 Redis 地址列表缓存未清理，页面仍显示旧地址。
测试步骤：
- 查询地址列表，生成缓存；
- 删除某个地址；
- 再次查询地址列表；
- 验证被删除地址不应出现；
- 查看数据库和缓存是否一致。
删除数据后缓存不清理，用户体验会非常差。
六、权限缓存一致性
很多系统会缓存用户角色、菜单和权限。
测试场景：
- 给用户新增角色后是否立即生效；
- 取消权限后是否仍能访问；
- 修改菜单后是否刷新；
- 退出重新登录是否刷新；
- 权限缓存过期时间是否合理。
权限类缓存不一致可能带来安全风险。比如取消管理员权限后，用户仍能访问后台接口。
七、并发下的一致性问题
并发场景下可能出现：
- 请求 A 修改数据库；
- 请求 B 同时读缓存或重建缓存；
- 缓存被写回旧值；
- 用户短时间看到旧数据。
测试可以通过并发请求模拟：
- 同时修改和查询；
- 多用户同时操作；
- 修改后立即高频查询；
- 检查最终数据是否正确。
普通功能测试不一定深入并发，但面试提到并发一致性会加分。
八、最终一致性怎么测
有些系统允许短时间不一致，比如通过 MQ 异步刷新缓存。测试时要明确可接受延迟。
例如需求规定 30 秒内刷新缓存：
- 修改数据；
- 立即查询可能还是旧值；
- 等待 30 秒；
- 再次查询必须是新值；
- 超过 30 秒仍旧值则为 Bug。
测试要区分强一致和最终一致，不要把符合设计的短暂延迟误报为 Bug。
九、缓存一致性常见 Bug
1. 修改后忘记删除缓存
数据库改了，缓存仍旧值。
2. 删除后缓存仍存在
数据已删除，页面还能查到。
3. 只更新单个缓存，列表缓存未更新
商品详情缓存刷新了，但商品列表缓存还是旧价格。
4. 多端缓存不一致
PC 页面刷新了，App 仍旧数据。
5. 异步刷新失败
MQ 消息丢失或消费者异常，导致缓存未更新。
十、面试回答模板
如果面试官问“缓存一致性问题怎么测试”，可以这样回答：
我会先确认哪些业务数据用了 Redis 缓存，以及项目采用的是更新缓存、删除缓存、TTL 过期还是 MQ 异步刷新策略。测试时通常按先查询生成缓存，再修改或删除数据库数据，然后再次查询验证返回是否为最新数据的思路来测。比如商品价格缓存，先查询商品生成缓存，再后台修改价格，随后验证接口、页面和数据库是否一致，同时检查列表缓存和详情缓存是否都刷新。如果是最终一致，还要按照约定时间等待后再次验证。对于权限、库存、订单状态这类关键数据，还会补充并发和异常场景。
十一、常见追问
追问：怎么判断是缓存问题？
数据库是新值，接口或页面返回旧值，等待或清缓存后恢复，通常可判断和缓存有关。
追问：修改商品后详情正确但列表错误怎么办？
说明可能只刷新了详情缓存，漏掉列表缓存或搜索缓存。
追问：最终一致怎么验收？
按需求约定的延迟时间验证，比如 30 秒内必须刷新。超过时间仍不一致就是问题。
追问：缓存不一致怎么提 Bug？
附数据库值、接口返回值、页面展示、操作时间、缓存 key 或日志证据。
十二、练习清单
- 找一个缓存业务；
- 查询生成缓存；
- 修改数据后再次查询；
- 删除数据后再次查询；
- 验证详情缓存；
- 验证列表缓存；
- 验证权限缓存；
- 验证 TTL 过期；
- 验证最终一致时间；
- 准备缓存一致性面试回答。
缓存一致性测试不是简单比较 Redis 和数据库，而是围绕业务变化验证用户看到的数据是否正确、是否及时、是否在所有入口都一致。
配套刷题：
