Flink 单并行度内使用多线程来提高任务的整体性能

分析痛点

笔者线上有一个 Flink 任务消费 Kafka 数据，将数据转换后，在 Flink 的 Sink 算子内部调用第三方 api 将数据上报到第三方的数据分析平台。这里使用批量同步 api，即：每 50 条数据请求一次第三方接口，可以通过批量 api 来提高请求效率。由于调用的外网接口，所以每次调用 api 比较耗时。假如批次大小为 50，且请求接口的平均响应时间为 50ms，使用同步 api，因此第一次请求响应以后才会发起第二次请求。请求示意图如下所示：

平均下来，每 50 ms 向第三方服务器发送 50 条数据，也就是每个并行度 1 秒钟处理 1000 条数据。假设当前业务数据量为每秒 10 万条数据，那么 Flink Sink 算子的并行度需要设置为 100 才能正常处理线上数据。从 Flink 资源分配来讲，100 个并行度需要申请 100 颗 CPU，因此当前 Flink 任务需要占用集群中 100 颗 CPU 以及不少的内存资。请问此时 Flink Sink 算子的 CPU 或者内存压力大吗？上述请求示意图可以看出 Flink 任务发出请求到响应这 50 ms 期间，Flink Sink 算子只是在 wait，并没有实质性的工作。因此，CPU 使用率肯定很低，当前任务的瓶颈明显在网络 IO。最后结论是 Flink 任务申请了 100 颗 CPU，导致 yarn 或其他资源调度框架没有资源了，但是这 100 颗 CPU 的使用率并不高，这里能不能优化通过提高 CPU 的使用率，从而少申请一些 CPU 呢？

同步批量请求优化为异步请求

首先可能想到可能是将同步请求改为异步请求，使得任务不会阻塞在网络请求这一环节，请求示意图如下所示。

异步请求相比同步请求而言，优化点在于每次发出请求时，不需要等待请求响应后再发送下一次请求，而是当下一批次的 50 条数据准备好之后，直接向第三方服务器发送请求。每次发送请求后，Flink Sink 算子的客户端需要注册监听器来等待响应，当响应失败时需要做重试或者回滚策略。通过异步请求的方式，可以优化网络瓶颈，假如 Flink Sink 算子的单个并行度平均 10ms 接收到 50 条数据，那么使用异步 api 的方式平均 1 秒可以处理 5000 条数据，整个 Flink 任务的性能提高了 5 倍。对于每秒 10 万数据量的业务，这里仅需要申请 20 颗 CPU 资源即可。关于异步 api 的具体使用，可以根据场景具体设计，这里不详细讨论。

多线程 Client 模式

对于一些不支持异步 api 的场景，可能并不能使用上述优化方案，同样，为了提高 CPU 使用率，可以在 Flink Sink 端使用多线程的方案。如下图所示，可以在 Flink Sink 端开启 5 个请求第三方服务器的 Client 线程：Client1、Client2、Client3、Client4、Client5。这五个线程内分别使用同步批量请求的 Client，单个 Client 还是保持 50 条记录为一个批次，即 50 条记录请求一次第三方 api。请求第三方 api 耗时主要在于网络 IO（性能瓶颈在于网络请求延迟），因此如果变成 5 个 Client 线程，每个 Client 的单次请求平均耗时还能保持在 50ms，除非网络请求已经达到了带宽上限或整个任务又遇到其他瓶颈。所以，多线程模式下使用同步批量 api 也能将请求效率提升 5 倍。

多线程的方案，不仅限于请求第三方接口，对于非 CPU 密集型的任务都可以使用该方案在降低 CPU 数量的同时，使得单个 CPU 承担多个线程的工作，从而提高 CPU 利用率。例如：请求 HBase 的任务或磁盘 IO 是瓶颈的任务，都可以降低任务的并行度，使得每个并行