高频面试问题与回答框架：常见问题、答题结构、公司侧重点

📌 面试问题

“线上突然出现大量504超时，你怎么排查？”

🎯 面试官考察点

• 能否快速锁定故障范围（全量/单机/单接口）
• 排查路径是否体系化而非靠直觉
• 是否具备代码级、中间件、OS/网络三层视角

📐 回答框架

1. 定界：看全局监控（SLB/网关）确认影响集群；查看错误日志是否集中在某台机器。
2. 分层定位：依次检查CPU/内存（OS层）→ 连接数/慢查询（中间件）→ 业务线程堆栈（应用层）。
3. 根因+止血：给出原因（如连接池耗尽），立即扩容/重启/降级。
4. 治理：分析代码未释放连接/优化SQL → 上线补丁并加监控。

✏️ 简短示例回答

“首先通过SLB监控发现502集中在A机房，查看对应Nginx错误日志，确认upstream超时。接着检查该机房Redis连接数，发现单台Redis连接打满。定位为代码中未使用连接池导致频繁创建连接。立即摘流量重启Redis，同时扩容临时节点。后续对代码增加JedisPool并压测，上线后监控连接数稳定在80%以内。”

🔁 可能追问

• 如果重启后仍然超时，你会怎么进一步排查？
• 你怎么区分是网络丢包还是应用层慢？
• 当时压测数据是多少？容量基线怎么定的？

⚠️ 避坑提醒

不要只说“我会上机器看日志”——要讲清看什么日志、怎么看、顺序是什么。避免跳第一步猜测DB问题，否则会被认为排查缺乏层次。

📌 面试问题

“你处理过最复杂的故障是什么？怎么解决的？”

🎯 面试官考察点

• 故障复杂度是否真实（而非简单重启）
• 是否有完整链路思考，而非只解决表象
• 是否具备跨团队协作与复盘输出能力

📐 回答框架（STAR）

• S：背景 – 业务&QPS、故障现象（如缓存穿透导致DB打爆）
• T：目标 – 恢复可用性 + 避免再次发生
• A：行动 – 先限流降级保核心，再分析热点Key，最后加布隆过滤器+本地缓存
• R：结果 – 恢复时间、系统承载能力提升、故障复盘文档

✏️ 简短示例回答

“一次大促热点商品导致缓存击穿，QPS 10w直接打垮MySQL。我先对非核心接口降级，对核心用户限流，保证订单不丢。然后分析发现单个SKU占80%流量，在Redis上加互斥锁+本地缓存。最终故障10分钟恢复，后续上线布隆过滤器，该场景下DB再无超载。”

🔁 可能追问

• 布隆过滤器如何设置误判率？
• 本地缓存的一致性怎么处理？
• 如果热点Key不止一个，你的方案会怎么变化？

⚠️ 避坑提醒

避免过度强调“自己一个人的功劳”，要体现团队协作（如通知DBA、业务方）。方案一定要量化：恢复时间、QPS下降比例、代码行数等。

📌 面试问题

“如何从架构层面预防高并发下的故障？”

🎯 面试官考察点

• 是否有系统性的容量评估与冗余设计经验
• 对限流、熔断、降级策略的落地细节
• 能否结合具体业务场景而非纯理论

📐 回答框架

1. 流量治理：网关层限流（令牌桶/漏桶），核心接口单独配置。
2. 依赖防护：核心服务与弱依赖之间加Hystrix/Sentinel熔断，设置线程池隔离。
3. 容量规划：根据历史峰值×1.5倍扩容，压测量化单机水位，预留Buffer。
4. 灰度与回滚：小流量发布、代码级别开关、配置中心动态开关降级。

✏️ 简短示例回答

“我在订单系统推动‘三合一’防护：网关层针对下单接口限流1000/s，Sentinel对支付链路熔断，非关键通知降级为MQ异步。同时每月压测，单机QPS 200设为告警水位。大促时开启预扩容，系统从未因流量突发雪崩。”

🔁 可能追问

• 限流阈值怎么定？误拦截怎么处理？
• Sentinel的熔断恢复机制是什么？
• 如果下游依赖完全不可用，你的降级方案如何保证数据最终一致？

⚠️ 避坑提醒

不要只罗列“限流熔断降级”名词，要举例说明在什么场景下触发、阈值依据什么数据设定、触发后用户体验如何。面试官反感纸上谈兵。