吞吐量监控与优化：吞吐量瓶颈定位、并行度调优、数据倾斜处理、背压与流量控制
吞吐量，说白了就是系统在单位时间内能处理多少数据。做金融流计算，这玩意儿就是命根子。你想想看，每秒几百万笔交易流过，系统稍微打个嗝，那就是真金白银的损失。我这些年踩过的坑，十有八九都跟吞吐量有关。
这一章，咱们就聊聊吞吐量的那些事儿。怎么定位瓶颈？怎么调并行度？数据倾斜怎么治？背压来了怎么办？嗯，都是实战中天天要面对的问题。
吞吐量瓶颈定位：别瞎猜，拿数据说话
很多同学一上来就说「系统慢」，然后就开始盲目加资源。我个人习惯是：先找到瓶颈在哪，再动手。没有数据支撑的优化，都是耍流氓。
吞吐量瓶颈通常出现在三个地方：
- CPU 瓶颈：计算密集型的算子，比如复杂的风控模型、加密解密
- IO 瓶颈：读写数据库、写日志、网络传输
- 内存瓶颈：状态后端过大、GC 频繁
怎么定位？我一般用三板斧：
- 看监控面板：CPU 使用率、内存占用、网络 IO、磁盘 IO，哪个先打满，哪个就是瓶颈
- 看算子耗时：Flink 的 Web UI 里，每个算子的「耗时」和「记录数」一目了然。哪个算子耗时最长，就盯着它
- 看反压指标：背压高的地方，就是瓶颈所在
核心原则：吞吐量由最慢的那个算子决定。别优化那些已经很快的环节，没用。
我曾经遇到过一个案例，某个交易处理链路，吞吐量死活上不去。监控一看，CPU 才用了 30%，内存也够，但背压就是高。后来仔细排查，发现是某个算子在做大量的序列化/反序列化，把 CPU 时间都耗在了这上面。换了个高效的序列化框架，吞吐量直接翻倍。
并行度调优：不是越大越好
并行度，就是同时干活的人手。人手多了，理论上干活快。但现实没那么简单。
并行度调优，我总结了几个经验：
- 并行度不是越大越好：并行度太大，线程切换开销、网络通信开销都会增加。反而可能降低吞吐量
- 上下游并行度要匹配：上游并行度 10，下游并行度 1，那下游就是瓶颈。反过来也一样
- 考虑数据分布：如果数据按 key 分区，某个 key 的数据量特别大，那这个分区的并行度再高也没用
我建议的调优步骤：
- 从默认并行度开始，比如 4 或 8
- 逐步增加，观察吞吐量变化
- 找到拐点——再增加并行度，吞吐量不再提升，甚至下降
- 拐点对应的并行度，就是最优值
小技巧：并行度最好设置为 CPU 核心数的 1-2 倍。IO 密集型的任务可以更大一些，CPU 密集型的要保守一点。
举个例子，我之前调优一个实时风控系统。默认并行度 8，吞吐量 5 万条/秒。我逐步加到 16，吞吐量到了 8 万。加到 24，反而掉到了 7 万。为什么？因为线程切换开销太大了。最后定在 16，刚刚好。
数据倾斜处理：最头疼的问题
数据倾斜，说白了就是「忙的忙死，闲的闲死」。某个 key 的数据量特别大，导致它所在的分区处理不过来，其他分区却在空转。
金融场景里，数据倾斜太常见了。比如某个热门股票的交易量是其他股票的几百倍，或者某个大客户的订单特别多。
怎么处理？我常用的方法：
- 加盐：给热点 key 加随机后缀，把数据打散到多个分区。处理完后再去掉后缀
- 两阶段聚合：先局部聚合，再全局聚合。适合 count、sum 这类操作
- 调整分区策略：不用默认的 hash 分区，改用自定义分区，把热点 key 单独处理
注意：加盐虽然好用，但会引入额外的计算和网络开销。而且有些场景下，加盐后数据顺序会乱，需要小心处理。
我曾经处理过一个交易对账系统，某个银行的数据量是其他银行的 100 倍。用默认的 hash 分区，那个分区直接被打爆。后来我用了「加盐 + 两阶段聚合」的方案，把那个银行的数据先按交易类型拆成 10 份，处理完再合并。吞吐量从 2 万提升到了 15 万。
背压与流量控制：别让系统崩了
背压，就是下游处理不过来，向上游传递压力。流量控制，就是主动限制流入的数据量，防止系统过载。
这两个概念，说白了就是「堵车了怎么办」。背压是下游告诉上游「慢点，我吃不消了」，流量控制是上游主动说「我慢点发，别把下游撑死」。
在 Flink 里，背压是自动的。但自动不代表不用管。我建议：
- 监控背压指标：Flink Web UI 里能看到每个算子的背压状态。如果某个算子长期处于高背压，那就是瓶颈
- 设置合理的缓冲区大小：缓冲区太大，延迟高；太小，容易触发背压。需要根据业务场景权衡
- 使用流量控制策略：比如限流、降级、熔断。防止突发流量把系统打垮
我的经验：背压不可怕，可怕的是背压导致的数据堆积和延迟飙升。一旦发现背压持续升高，就要立即排查原因，而不是等着系统自己恢复。
我记得有一次线上事故，某个数据源突然发了 10 倍于平时的数据量。下游的数据库扛不住，背压一路传到源头。结果整个链路延迟从 100ms 飙升到了 30 秒。后来我加了一个限流器，在源头就限制最大流入速率，超过的部分直接丢弃或写入死信队列。从那以后，再也没出过类似问题。
吞吐量优化的核心逻辑
说了这么多，其实吞吐量优化的核心逻辑就一句话：找到瓶颈，消除瓶颈，然后找下一个瓶颈。
下面这张图，是我自己总结的吞吐量优化流程，你可以参考一下：
嗯，这张图把整个优化流程串起来了。从监控开始，到定位瓶颈、分析原因、实施优化，然后循环迭代。每一步都有对应的技术手段。
最后说一句：吞吐量优化没有银弹。每个系统都不一样，每个瓶颈的解法也不同。但只要你掌握了定位问题的方法，剩下的就是时间问题了。
我的建议：平时多积累一些常见的瓶颈案例和对应的解法。遇到问题的时候，能快速匹配。别等到线上出事了再临时抱佛脚。
好了，这一章就到这里。吞吐量这块，说白了就是「找瓶颈、解瓶颈」的循环。下一章咱们聊聊延迟监控与优化，那又是另一番天地了。
公众号:蓝海资料掘金营，微信deep3321