一、有实际高并发经验（建议结构）
- 直接量化
"在XX项目中，系统日活用户约XX万，核心接口峰值QPS达到XX，TPS处理能力为XX/秒。通过压力测试验证过XX并发线程下的稳定性。" - 技术方案展开
"为支撑这个量级，我们做了这些优化： - 缓存层：Redis集群+本地缓存，缓存命中率提升至92%
- 数据库：MySQL分库分表（XX个分片）+读写分离，配合连接池优化
- 流量削峰：RabbitMQ异步化处理订单，Kafka做日志采集
- 限流降级：Sentinel对核心接口配置QPS阈值和熔断策略
- 横向扩展：通过K8s实现自动弹性伸缩，高峰期扩容30%容器节点"
- 结果与反思
"最终系统在双十一大促期间平稳度过，平均响应时间控制在200ms以内。后续通过全链路压测发现XX环节存在瓶颈，优化线程池参数后吞吐量提升了40%。"
二、无直接经验但懂原理（迂回展现能力）
"虽然我目前的工作场景并发量在QPS 500左右，但通过系统性学习掌握了高并发设计的核心方法：
- 分层防御策略：从DNS负载均衡到Nginx反向代理，再到服务层熔断限流
- 读写分离实践：在个人项目中用MyCAT实现MySQL读写分离，压测时QPS提升3倍
- 异步化改造：使用线程池处理非核心链路，响应时间降低70%
- 技术验证：用JMeter模拟过万级并发，通过Redis+Lua实现分布式锁解决超卖问题
如果有机会参与高并发项目，我可以快速落地这些技术方案。"
三、典型回答示例
面试官：能具体说说数据库优化的细节吗？
候选人：
"当QPS突破2000时，我们遇到了数据库连接瓶颈：
- 将单库拆分为16个分片，使用ShardingSphere做路由
- 配置HikariCP连接池，根据TP99调整maxPoolSize到50
- 对热点数据（如商品库存）采用Redis原子操作+MQ异步落库
- 慢查询优化：通过SkyWalking定位到未命中索引的SQL，优化后执行时间从800ms降到15ms"
四、避坑指南
- 错误示范：
"我们系统用户量很大，具体数字记不清了，主要用Redis和MQ解决的"
（缺乏量化指标，显得经验模糊） - 正确姿势：
"在618大促期间，订单服务要支撑峰值2000QPS，我们通过： - 预减库存方案避免实时查库
- 订单状态变更走MQ异步通知
- 动态扩容到20个Pod实例
最终系统在1分钟内处理了12万笔订单，期间CPU负载维持在70%以下"