一、风控系统性能调优概述
做风控系统这些年，我见过太多团队一上来就堆机器、加缓存，结果钱花了不少，系统该慢还是慢。说白了，性能调优不是拍脑袋的事，得先搞清楚瓶颈在哪、目标是什么、怎么下手。这一章，我就把这几件事掰开了讲。
1.1 性能瓶颈的常见类型
我在项目中遇到过各种各样的性能问题，总结下来，无非就这几类：
- 计算瓶颈：规则引擎跑得慢、模型推理耗时。比如一个规则集里有上百条规则，每条都要遍历用户的所有行为数据，那肯定慢。
- IO瓶颈：数据库查询慢、外部接口调用超时。我记得有一次，风控系统每次请求都要查三次数据库，结果QPS一上来，数据库直接挂了。
- 内存瓶颈：特征缓存太大、对象创建太频繁。你想想看，每次请求都new一堆对象，GC频繁触发，系统能不卡吗？
- 锁竞争：分布式锁、数据库行锁、线程锁。嗯，这里要注意，锁用不好，性能直接腰斩。
核心观点：性能瓶颈往往不是单一的，而是多个因素叠加的结果。调优前，先定位主因。
1.2 调优的目标与原则
调优不是追求极致性能，而是找到性价比最高的平衡点。我个人习惯把目标分成三个层次：
| 层次 | 目标 | 典型指标 |
|---|---|---|
| 基础层 | 保证系统稳定 | 不OOM、不频繁Full GC |
| 业务层 | 满足SLA | P99延迟 < 200ms |
| 成本层 | 资源利用率最优 | 单机QPS最大化 |
调优的原则，我总结了三句话：
- 先稳定，后性能：系统都跑不稳，谈什么性能？
- 先定位，后优化：别瞎猜，用数据说话。
- 先业务，后技术：有时候改一条规则比优化代码更有效。
避坑指南：我曾经为了优化一个接口的响应时间，花了三天重构代码，结果发现是业务方传了一个全量数据，根本不需要优化。所以，调优前先确认问题是不是真的在系统层面。
1.3 调优的通用方法论
调优这件事，说白了就是一套流程。我习惯用下面这个框架：
这个流程看起来简单，但每一步都有坑。我重点说说瓶颈定位这一步：
- 先看监控：CPU、内存、IO、网络，哪个指标异常？
- 再看日志：慢查询日志、GC日志、错误日志。
- 最后压测：用压测工具复现问题，确认瓶颈点。
注意：不要跳过压测直接优化。我曾经见过一个团队，看监控觉得是数据库慢，结果优化完发现是网络带宽不够。压测能帮你验证假设。
1.4 调优的常见误区
做调优这么多年，我踩过不少坑，也见过别人踩坑。这里列几个最常见的：
- 过早优化：系统还没上线，就开始优化代码。其实很多问题只有线上流量才能暴露出来。
- 过度优化：为了省几毫秒，把代码改得又复杂又难维护。你想想看，值吗？
- 忽视业务：技术优化做得再好，业务逻辑不合理，也是白搭。
- 不做验证：优化完了不压测，直接上线。结果性能没提升，反而出了新问题。
我的建议：每次优化只改一个点，改完就压测验证。这样出了问题，你也能快速回滚。
1.5 本章小结
这一章，我们聊了性能瓶颈的常见类型、调优的目标与原则，还有一套通用的方法论。说白了，调优就是发现问题、定位问题、解决问题、验证效果，然后循环往复。别想着一步到位，性能调优是个持续的过程。
嗯，下一章我们会深入具体的调优工具和手段，比如怎么用火焰图定位CPU瓶颈、怎么分析GC日志。但那是后话了，先把这一章的基础打牢。