后端研发工程师社招面试：高并发经历深挖与防追问指南

笼统回答（示例）：
“有一次系统慢了，我们看监控发现 CPU 高，然后重启了服务器，后来把 JVM 堆内存调大了一倍就好了。”

具体回答（虚构示例，请替换为真实证据）：
“在一次大促期间，网关 P99 延迟突然从 35ms 飙升至 1200ms。我通过全链路 Trace 追踪定位到某一报表导出接口未走限流，导致频繁 Full GC。通过 jstack 抓取堆栈发现大量线程阻塞在数据库连接池获取上，jmap 抽样确认是某导出查询在内存中一次性加载了 8 万条无分页数据。应急方案先动态降级熔断该非核心接口，后续重构为基于游标批次流式导出，并将连接池与核心下单链路物理隔离。”

笼统回答（示例）：
“我们用双写加分布式锁，保证缓存和数据库数据每时每刻绝对一致。”

具体回答（虚构示例，请替换为真实证据）：
“在业务工程中没有‘绝对的一致’，只有与业务容忍度匹配的权衡。对于库存和余额等金融级强一致场景，我们直接走数据库行级悲观锁/版本号乐观锁，缓存仅作只读库存预扣与前置拦截；对于商品详情等弱一致场景，我们采用‘先更库 + 删缓存 + 延时双删/监听 Canal Binlog 异步重试’，并将容忍窗口控制在毫秒级，用最简单稳健的架构支撑 99.99% 的可用性。”

笼统回答（示例）：
“直接上分布式数据库分库分表 100 个库，把并发分摊开。”

具体回答（虚构示例，请替换为真实证据）：
“核心原则是‘层层过滤，把 99% 的无效流量阻挡在数据库之前’。第一步是在边缘 CDN 与网关层做静态化与用户维度限流防刷；第二步是服务端内存基于令牌桶预扣减，只有拿到令牌的有效请求才落到 Redis 分段扣减；最后异步 MQ 削峰解耦写入数据库完成持久化，让真正触达数据库核心存储的请求只有几百 QPS。”