解读

国内互联网流量高峰集中在秒杀、直播、大促等场景，本地缓存（Caffeine、Guava、Ehcache）+ Redis 两级架构几乎成为标配。性能测试工程师在面试中被追问“如何防止不一致”，核心不是让候选人背八股文，而是验证三点：

1. 能否量化不一致带来的业务损失（客诉量、资损额、SLA 违约分钟数）
2. 能否把“最终一致”翻译成可落地的测试方案（用多大并发、多长窗口、什么指标衡量）
3. 能否在压测环境里复现并给出调优证据（线程栈、网络包、GC 日志、Redis 延迟分布）

一句话：面试官想听的是“我怎么通过性能手段把不一致概率从 0.3% 压到 0.01%，并且让运维愿意签字上线”。

知识点

1. 不一致根因：本地缓存 TTL 漂移、Redis 主从异步复制、JVM 时钟漂移、消息队列重试、应用重启时本地缓存冷加载
2. 量化指标：
   • 数据新鲜度：Δt = 本地缓存最后更新时间 − Redis 最后更新时间
   • 业务容忍阈值：商品库存场景 Δt ≤ 500 ms；用户资产场景 Δt ≤ 100 ms
   • 客诉转换率：每 1‰ 不一致 ≈ 3 起工单/万订单
3. 测试手段：
   • 并发写：JMeter 线程组 20% 写、80% 读，Redis 用 keyspace-notification 打标时间戳
   • 时间窗口扫描： Gatling 持续 15 min，每 100 ms 采样一次本地与 Redis 值，输出 99th 延迟分布
   • 故障注入：用 tc/netem 给 Redis 加 200 ms 延迟，模拟主从复制滞后，观察本地缓存穿透率
   • 灰度指标：上线前在压测环境跑 4 h，不一致键占比 < 0.01% 才能进生产
4. 主流一致性策略：
   • 短 TTL + 异步刷新：本地缓存 1 s，后台线程 500 ms 轮询 Redis，降低脏读窗口
   • 版本号/时间戳：Redis 值携带毫秒时间戳，本地缓存比对，落后即丢弃
   • 发布订阅：Redis Keyspace Notification 或 Canal 广播，本地缓存收到失效消息立即清除
   • 分布式锁：写操作时先拿 Redisson 锁，再删本地缓存，再更新 Redis，读操作双重检查
   • 一致性哈希分片：把热点 key 按用户 ID 分片，降低单 key 更新频率，减少不一致概率
5. 性能权衡：
   • 短 TTL 导致 QPS 回源 Redis 增加 30%，需要评估 Redis CPU 利用率 < 70%
   • 发布订阅 1 万 key 场景下，网卡 PPS 增加 8 k，需要万兆网卡 + 多队列网卡绑定
   • 分布式锁粒度到用户维度，锁冲突概率 0.2%，对 99th 延迟增加 3 ms，仍在 SLA 50 ms 以内

答案

回答采用“场景—量化—验证—收口”四段式，总时长控制在 3 分钟，既体现性能测试深度，也给出可落地的数字。

1. 场景定义
   以电商秒杀商品库存为例，本地缓存 1 s TTL，Redis 主从异步复制，业务要求库存超卖为 0，Δt ≤ 500 ms。

2. 量化目标
   压测环境 2 万并发，持续 30 min，不一致键占比 ≤ 0.01%，对应生产客诉 ≤ 1 单/10 万订单。

3. 测试设计
   a) 数据构造：预热 10 万 SKU，每个 SKU 库存 1000，Redis 用 Hash 结构 <skuId,stock,version>
   b) 脚本模型：JMeter 15 线程组，读:写=4:1，写操作随机扣减库存，读操作先查本地缓存，再查 Redis，记录时间戳
   c) 采集指标：

   • 本地缓存命中率
   • Δt 分布，P99 ≤ 500 ms
   • 不一致键数/总键数
     d) 故障注入：
   • 用 redis-cli 给从节点加 300 ms 延迟，模拟主从复制 lag
   • kill -9 随机 20% 应用节点，观察重启后本地缓存冷加载期间不一致峰值
     e) 结果：
   • 无故障时 Δt P99=120 ms，不一致占比 0.005%
   • 故障期间 Δt P99=480 ms，不一致占比 0.008%，仍低于 0.01% 阈值

4. 收口策略
   上线前把本地缓存 TTL 缩到 500 ms，增加 Redis Keyspace Notification 失效广播，网卡 PPS 上升 5 k，在万兆网卡水位 30% 以内；同时运维侧加告警：连续 3 个采样周期不一致占比 > 0.02% 即回滚版本。

拓展思考

1. 如果业务不允许任何超卖，能否用本地缓存？
   答：库存场景可改用“本地缓存只缓存库存快照，真正扣减走 Redis + Lua 脚本原子扣减”，本地缓存仅做展示，不一致仅影响用户体验，不影响资损。性能测试需验证 Lua 脚本在 20 万 QPS 下 Redis 单节点 CPU < 80%，否则需分片。

2. 消息队列异步刷新方案里，如何验证“消息丢失”导致的不一致？
   答：在压测脚本里给每条更新打全局唯一 traceId，写 Redis 成功后写一张“消息发送表”，消费端处理完再写“消息消费表”，性能测试通过 Flink 双流 JOIN，计算 5 min 窗口内丢失率，要求 < 0.001%。

3. 单元化架构下，异地多活机房延迟 40 ms，如何评估本地缓存一致性？
   答：把用户按 UID 分片到单元，写操作只在主单元执行，通过 DTS 同步到从单元，从单元本地缓存 TTL 设置 2 s，性能测试在从单元用 1 万并发读，验证 Δt P99 ≤ 2 s + 40 ms，同时业务侧接受“异地用户看到延迟 2 s”的文案提示。

4. 压测通过，生产仍出现客诉，如何定位是本地缓存还是 CDN 缓存？
   答：在响应头返回“X-Cache-Layer: local/redis/cdn”字段，用户投诉时让客服一键复制 curl，性能测试回放该 curl，若 X-Cache-Layer=local 且版本号落后，即可锁定本地缓存问题，再回滚版本或手动清缓存。