2. 硬件与基础设施调优：CPU选型与配置、内存优化策略、磁盘I/O性能提升、网络延迟优化

风控系统说到底，就是跟时间赛跑。一笔交易从进来，到我们给出“放行”还是“拦截”的结论，中间可能就几十毫秒。硬件选不对，后面代码写得再漂亮，也是白搭。我这些年踩过的坑，有一半都跟硬件配置有关。今天咱们就聊聊，怎么把这四个最关键的硬件环节搞定。

2.1 CPU选型与配置：别只看核心数

很多人选 CPU，上来就问“几核几线程”。其实对于风控系统，单核性能往往比核心数更重要。为什么？因为风控决策链路是串行的——你得先查黑名单，再跑规则，最后调模型。每一步都依赖上一步的结果。

我个人习惯，优先看 主频 和 三级缓存。主频高，单线程处理快；缓存大，热点数据命中率高。举个例子，我曾在项目中用 AMD EPYC 7763（64核）替换了 Intel Xeon Gold 6248（20核），核心数翻了三倍，但风控决策的 P99 延迟反而高了 15%。

后来一查，问题出在 NUMA 架构上。跨 NUMA 节点访问内存，延迟能差 2-3 倍。所以我的建议是：

• 优先选高主频、大缓存的 CPU，比如 Intel Xeon W 系列或 AMD Ryzen Threadripper Pro。
• 如果必须用多路服务器，一定要做 NUMA 绑定。把风控进程固定在同一个 NUMA 节点上。
• 关闭超线程。超线程对计算密集型任务有帮助，但风控系统大量依赖内存访问，超线程反而可能引起缓存争用。

2.2 内存优化策略：别让 GC 成为你的噩梦

风控系统里，内存主要干两件事：缓存规则和模型参数，以及存储临时计算结果。内存不够，系统就会频繁 GC，甚至 OOM。我见过最夸张的一次，一个风控节点 64GB 内存，GC 停顿时间占了总运行时间的 40%。

怎么优化？我总结了三个原则：

1. 给 JVM 留够堆外内存。很多人只关注 -Xmx，忽略了堆外内存。风控系统如果用到了 Netty、DirectBuffer，堆外内存不够会直接 crash。
2. 用堆外缓存代替堆内缓存。比如用 Redis 或本地堆外缓存（如 Chronicle Map）来存规则和模型。堆内缓存一多，GC 压力剧增。
3. 设置合理的 GC 策略。我个人推荐 G1GC，配合 -XX:MaxGCPauseMillis=50，把 GC 停顿控制在 50ms 以内。

2.3 磁盘I/O性能提升：SSD 只是起点

风控系统离不开磁盘——日志、历史数据、模型文件，全得落盘。很多人觉得，上了 SSD 就万事大吉。其实不然。我见过用 NVMe SSD 但 I/O 延迟还是高的案例，问题出在文件系统和 I/O 调度上。

我的建议是：

• 用 NVMe SSD 替代 SATA SSD。NVMe 的队列深度和延迟表现，完全不是一个量级。
• 文件系统选 XFS 或 ext4，别用 ZFS 或 Btrfs。后者虽然功能多，但元数据操作开销大，不适合高并发写。
• 调整 I/O 调度器。对于 NVMe SSD，用 none（即 noop）调度器，别用 cfq 或 deadline。因为 SSD 没有机械臂寻道问题，调度器反而增加开销。
• 日志落盘用异步 I/O。风控日志量大，同步写会阻塞主线程。用 Log4j2 的异步 Appender，或者自己封装一个 RingBuffer 写日志。

2.4 网络延迟优化：别小看那 1ms

风控系统通常是个分布式系统——规则引擎、模型服务、数据库、缓存，全在不同的机器上。网络延迟每增加 1ms，整个决策链路可能就多 5-10ms。你想想看，如果一笔交易要调 10 个服务，那 1ms 的延迟就变成了 10ms。

怎么优化？我总结了几个关键点：

• 尽量同机房部署。跨机房延迟至少 1-2ms，同机房内可以做到 0.1ms 以内。
• 用 RDMA 替代 TCP。如果条件允许，用 InfiniBand 或 RoCE v2，延迟能降到 1-2 微秒。
• 调整 TCP 参数。比如 net.core.rmem_max 和 net.core.wmem_max 调大，减少丢包重传。
• 用连接池复用连接。每次请求都新建 TCP 连接，三次握手就浪费 1ms。用连接池，长连接复用。

知识体系总览

下面这张图，是我自己总结的硬件调优核心逻辑。你可以把它当成一个检查清单，每次调优时对照着看。

说白了，硬件调优没有银弹。你得根据自己系统的实际情况，找到那个最明显的短板。我个人的经验是：先看网络，再看磁盘，然后看内存，最后看 CPU。因为网络和磁盘的优化效果最明显，CPU 往往是最难啃的骨头。

---