系统上线后的监控与调优，请说明如何处理高并发场景（如资产核销的峰值处理），包括性能瓶颈定位、优化措施。

1) 【一句话结论】针对资产核销等高并发场景，需通过分层监控识别性能瓶颈，结合数据库分库分表、缓存优化、异步消息队列等架构手段，确保系统在高并发下满足业务一致性并保持稳定。

2) 【原理/概念讲解】老师口吻解释：高并发处理的核心是“识别-优化-验证”。性能瓶颈定位常用方法：监控指标（如QPS、响应时间、数据库连接数）、日志分析（追踪请求处理路径）、压力测试。调优层次分为代码级（SQL优化、算法）、架构级（缓存、异步、分库分表）、资源级（服务器扩容）。类比：系统像城市交通网络，高并发是高峰期拥堵，瓶颈是数据库查询慢，优化方法包括“拓宽道路”（分库分表）、“增加公交”（缓存）、“错峰出行”（异步处理）。

3) 【对比与适用场景】

优化手段	定义	特性	使用场景	注意点
数据库分库分表	按业务或时间维度拆分数据库，提升读写性能	分片后单库负载降低，但需处理跨分片事务	高并发读写（如核销记录写入）	分片键设计（如资产ID哈希），数据一致性用最终一致性（TCC/Saga）
缓存	存储热点数据，减少数据库访问	响应快，但需防穿透/雪崩	热点数据查询（如资产状态）	写时刷新+读时回源，布隆过滤器防穿透，限流防雪崩
异步消息队列	请求入队，后台消费	解耦请求与处理，提高吞吐	长耗时操作（如核销后通知）	队列容量（历史峰值1.5倍），消费者数匹配资源，积压告警

4) 【示例】

• 分库分表设计：资产ID哈希分库（如asset_id % 8，对应db0-db7），核销记录按月分表（表名destruction_log_202405）。
• 缓存更新：Redis中asset_status缓存，写时刷新（更新数据库后立即更新缓存，TTL 5分钟），读时回源（未命中时查询数据库）。
• 消息队列：RabbitMQ，队列容量1500条（历史峰值1000QPS*1.5），消费者根据CPU负载（每个处理速率100条/秒，负载>70%时增加消费者），积压告警阈值1000条。

5) 【面试口播版答案】
面试官您好，针对资产核销的高并发场景，我会从监控、瓶颈定位、优化三方面处理。首先，通过设置关键监控指标（如QPS、响应时间、数据库连接数、缓存命中率），实时监控，当核销QPS超阈值且响应超200ms时告警。然后定位瓶颈：日志分析发现数据库查询（如查询资产状态和关联账户的SQL）耗时久。优化措施：1. 数据库分库分表：按资产ID哈希分库（如asset_id % 8），按月分表（表名destruction_log_202405），读写分离提升性能；2. 缓存优化：Redis缓存热点资产状态，写时刷新（更新数据库后立即更新缓存，TTL5分钟），布隆过滤器防穿透（资产ID布隆过滤器，误判率1%）；3. 异步处理：核销请求入RabbitMQ队列，消费者后台处理，避免阻塞前端；4. 资源扩容：根据监控动态增加服务器。通过这些，确保系统在高并发下稳定，数据一致。

6) 【追问清单】

• 问：分库分表如何保证数据一致性？答：采用最终一致性，如TCC模式，确保核销后资产状态与记录一致。
• 问：消息队列积压时如何处理？答：增加消费者或扩容服务器，记录积压日志分析原因。
• 问：缓存更新策略具体怎么做？答：写时刷新（更新数据库后立即更新缓存），读时回源（未命中时查询数据库），TTL5分钟。
• 问：监控哪些关键指标？答：QPS、响应时间（P99）、资源占用（CPU、内存）、缓存命中率、错误率。

7) 【常见坑/雷区】

• 坑1：分库分表未考虑数据一致性，导致核销后状态不一致。
• 坑2：缓存未设置TTL，核销后缓存未更新，后续查询错误。
• 坑3：消息队列容量不足，积压导致请求丢失。
• 坑4：未考虑业务实时性，异步处理导致延迟超预期。
• 坑5：监控指标设置不合理，无法及时发现瓶颈。