在处理直播系统的性能测试时，遇到峰值流量导致服务器CPU飙升，如何定位问题并优化？请描述你的排查思路和解决方案。

1) 【一句话结论】：在直播系统CPU飙升时，通过分层排查（应用层逻辑、数据库、网络、硬件），定位到高并发场景下的热点SQL或无效计算，通过数据库索引、缓存、异步化等优化，降低CPU负载，提升系统稳定性。

2) 【原理/概念讲解】：老师解释，性能测试中CPU飙升的核心是系统资源过载。类比：CPU像机器的发动机，如果发动机持续高转速（高负载），可能是因为负载过大（比如太多请求同时计算，或数据库查询慢导致CPU等待I/O）。具体原因包括：①应用层存在循环计算或重复计算（如循环遍历数据并计算，导致CPU持续运算）；②数据库查询复杂，未使用索引导致全表扫描（CPU用于处理大量数据）；③缓存未命中，频繁访问数据库（数据库I/O等待导致CPU空闲但资源占用高）；④网络延迟导致应用层等待（CPU等待网络数据，占用资源）。排查需从应用、数据库、网络、硬件四个层面逐步缩小范围。

3) 【对比与适用场景】：以“排查方法”为例，对比日志分析、监控指标、压力测试工具：

方法	定义	特性	使用场景	注意点
日志分析	通过系统日志（如数据库慢查询日志、应用日志）分析耗时操作	定位具体操作，但需人工解析	发现异常操作、错误日志	需日志格式规范，可能延迟
监控指标	通过系统监控（CPU、内存、数据库连接数等）实时观察	实时反映系统状态	识别资源瓶颈、异常波动	需监控指标设置合理，避免误报
压力测试工具（如JMeter）	模拟高并发请求，记录响应时间、资源占用	可控的负载测试，定位性能瓶颈	验证系统在高负载下的表现	需配置合理，避免测试环境与生产环境差异

4) 【示例】：假设直播系统有一个“获取用户实时观看数据”的接口，高并发时，数据库查询“select * from live_view where user_id=? and time between ? and ?”未添加索引，导致全表扫描。伪代码：

def get_realtime_view(user_id, start_time, end_time):
    sql = "SELECT * FROM live_view WHERE user_id = %s AND time BETWEEN %s AND %s"
    result = db.query(sql, (user_id, start_time, end_time))
    return result

当并发请求达到峰值（如1000QPS），数据库执行全表扫描，CPU占用率飙升至90%以上。

5) 【面试口播版答案】：遇到直播系统CPU飙升，首先通过监控指标（如Prometheus的CPU使用率）发现应用服务器CPU占用率超过80%，然后分层排查：先看应用层日志，发现高并发时存在大量数据库查询；接着检查数据库慢查询日志，发现上述SQL全表扫描；分析后，为数据库添加user_id和time的联合索引，优化后CPU占用率下降到30%以下，系统稳定。

6) 【追问清单】：

• 问具体排查工具？回答：用Prometheus监控CPU指标，JMeter模拟压力，以及数据库慢查询日志。
• 问如何验证优化效果？回答：通过压力测试，记录优化前后的CPU使用率、响应时间，对比数据。
• 问分布式系统中如何处理？回答：检查微服务调用链，优化异步通信或增加缓存。
• 问是否考虑过缓存？回答：是的，引入Redis缓存热点数据，减少数据库压力。
• 问硬件资源不足怎么办？回答：先优化软件（如调整数据库连接池），再考虑增加服务器。

7) 【常见坑/雷区】：

• 只看CPU而不看其他指标（如内存泄漏导致CPU飙升，实际是内存问题）。
• 忽略缓存策略（缓存未设置过期时间，导致失效，频繁访问数据库）。
• 优化过度（过度索引导致数据库写入性能下降）。
• 忽略网络延迟（网络抖动导致应用层等待，CPU占用率上升）。
• 不区分生产与测试环境（测试环境压力测试结果与生产环境差异大）。