一、有实际高并发经验（建议结构）

1. 直接量化
   "在XX项目中，系统日活用户约XX万，核心接口峰值QPS达到XX，TPS处理能力为XX/秒。通过压力测试验证过XX并发线程下的稳定性。"
2. 技术方案展开
   "为支撑这个量级，我们做了这些优化：
3. 缓存层：Redis集群+本地缓存，缓存命中率提升至92%
4. 数据库：MySQL分库分表（XX个分片）+读写分离，配合连接池优化
5. 流量削峰：RabbitMQ异步化处理订单，Kafka做日志采集
6. 限流降级：Sentinel对核心接口配置QPS阈值和熔断策略
7. 横向扩展：通过K8s实现自动弹性伸缩，高峰期扩容30%容器节点"
8. 结果与反思
   "最终系统在双十一大促期间平稳度过，平均响应时间控制在200ms以内。后续通过全链路压测发现XX环节存在瓶颈，优化线程池参数后吞吐量提升了40%。"

二、无直接经验但懂原理（迂回展现能力）

"虽然我目前的工作场景并发量在QPS 500左右，但通过系统性学习掌握了高并发设计的核心方法：

1. 分层防御策略：从DNS负载均衡到Nginx反向代理，再到服务层熔断限流
2. 读写分离实践：在个人项目中用MyCAT实现MySQL读写分离，压测时QPS提升3倍
3. 异步化改造：使用线程池处理非核心链路，响应时间降低70%
4. 技术验证：用JMeter模拟过万级并发，通过Redis+Lua实现分布式锁解决超卖问题
   如果有机会参与高并发项目，我可以快速落地这些技术方案。"

三、典型回答示例

面试官：能具体说说数据库优化的细节吗？
候选人：
"当QPS突破2000时，我们遇到了数据库连接瓶颈：

1. 将单库拆分为16个分片，使用ShardingSphere做路由
2. 配置HikariCP连接池，根据TP99调整maxPoolSize到50
3. 对热点数据（如商品库存）采用Redis原子操作+MQ异步落库
4. 慢查询优化：通过SkyWalking定位到未命中索引的SQL，优化后执行时间从800ms降到15ms"

四、避坑指南

• 错误示范：
  "我们系统用户量很大，具体数字记不清了，主要用Redis和MQ解决的"
  （缺乏量化指标，显得经验模糊）
• 正确姿势：
  "在618大促期间，订单服务要支撑峰值2000QPS，我们通过：
• 预减库存方案避免实时查库
• 订单状态变更走MQ异步通知
• 动态扩容到20个Pod实例
  最终系统在1分钟内处理了12万笔订单，期间CPU负载维持在70%以下"