腾讯后端多轮复盘：热 Key、缓存一致性与库存
本场面试题
- QPS 增长时，怎样用压测定位系统瓶颈？
- 怎样分析和缓解 Redis 热 Key？
- 已有本地缓存，为什么还可能需要分布式缓存？
- 删除缓存后大量并发回源，怎样保护数据库？
- 加入本地缓存后，为什么热点压力仍可能存在？
- Redis 与 MySQL 共同参与库存扣减时，怎样避免超卖并保证回滚一致性？
面经与参考答法
腾讯后端多轮复盘：热 Key、缓存一致性与库存
这是一份发表于 2025 年的多公司面试日记。本页仅选取明确标记为腾讯的一面、三面、复试或加面片段，围绕压测、缓存、运行诊断与库存整理；具体轮次关系、部门和面试日期并不完整，不把其他公司的问题归到腾讯。
面试经历为个人自述，未经企业独立确认。以下短答及示例为编辑教学整理，不代表当事人的现场回答、项目配置或实验结果。
（1）QPS 增长时，怎样用压测定位系统瓶颈？
先定义入口负载、数据分布、成功标准和目标分位延迟，在稳定环境下逐步增加压力，同时观察错误率、排队、CPU、内存、GC、连接池及数据库等依赖。用同一时间轴的指标和 Trace 识别饱和点，再通过单项调整验证假设。用户总数、主从或集群名称都不能单独证明容量；原帖没有提供可复现的压测数值。
（2）怎样分析和缓解 Redis 热 Key？
先定位是读流量集中、数据过大、写入竞争还是单分片资源饱和。读热点可评估进程内缓存、请求合并、只读副本或受控复制，写热点则要重新审视数据模型与原子更新边界。每种办法都带来一致性、失效或合并成本；增加分片不能自动拆开单个 Key 的工作量，也不能保证把热点彻底消除。
（3）已有本地缓存，为什么还可能需要分布式缓存？
本地缓存减少单进程内的重复访问，分布式缓存可以在多实例间共享数据并减轻权威存储压力，但它们不是强一致副本。先说明可容忍陈旧时间和数据权威，再设计版本、TTL、失效传播与失败恢复。日志订阅的低延迟不能等同于同步保证，异步更新、旧值回填和节点失联都需要明确处理。
（4）删除缓存后大量并发回源，怎样保护数据库？
可在明确的范围内合并同一 Key 的回源请求，用有界等待、限流、预热或允许的陈旧值降低冲击。进程内锁只能合并本进程的请求；跨实例协调另有租约、失效与持有者身份问题，不能声称一个本地锁解决全局并发。数据库容量仍是硬约束，回填失败、慢请求和重试需要共同的预算与监控。
（5）加入本地缓存后，为什么热点压力仍可能存在？
缓存可能尚未预热、命中率不足、容量过小或同时过期，也可能只是把读热点移成写入与失效热点。分别看每层命中、回源、Key 分布和资源使用，再选择 TTL 扰动、刷新、单飞合并或数据模型调整。过期策略必须与业务允许的陈旧窗口一致，不能以长期保留旧值换取表面命中率。
（6）遇到性能问题，升级 JDK 前应检查什么？
关联知识点待核实。
先保留可复现负载和运行基线，关联接口延迟、CPU、分配速率、堆使用及 GC 日志，区分内存泄漏、分配压力、停顿和其他依赖等待。确认瓶颈后，再在相同条件下比较候选 JDK 与配置的正确性、性能和回退能力。升级版本不是根因分析的替代，原帖也没有给出实际版本或测量结果。
（7）Redis 与 MySQL 共同参与库存扣减时，怎样避免超卖并保证回滚一致性？
先确定最终库存与订单事实由谁负责，用权威存储中的条件更新或事务保证不变量，并用业务幂等键约束重复扣减和补偿。Redis 预扣只能在明确的协议下参与准入，缓存与数据库不会因为各自操作原子就自动组成一个事务。提交结果不确定时先查证，再重试或补偿；回滚和对账也要记录状态并能幂等恢复。
（8）手撕算法（题目名称和条件待补）
关联知识点待核实。
原文只提到 Hot100 和另一道手撕，没有给出算法名称与题面。这里保留待补，不猜成任何具体算法题，不据此建立知识关联或热度。
（9）大模型相关提问（具体内容待补）
关联知识点待核实。
原文仅有零散的大模型提及，以及作者说自己没有介绍相关项目的片段，没有可确认的具体追问。因此本页不据此编写 Agent、RAG 或多模态问答，也不把这些术语计为考点频次。