标签：请求 Flink Client 线程 Sink 算子 多线程
简介： 本人通过分析痛点、同步批量请求优化为异步请求、多线程 Client 模式、Flink 算子内多线程实现以及总结四部分帮助大家理解 Flink 中使用多线程的优化及在 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 任务发出请求到响应这 50ms 期间，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 是瓶颈的任务，可以降低任务的并行度，使得每个并行度内处理多个线程。
Flink 算子内多线程实现
Sink 算子的单个并行度内现在有 5 个 Client 用于消费数据，但 Sink 算子的数据都来自于上游算子。如下图所示，一个简单的实现方式是 Sink 算子接收到上游数据后通过轮循或随机的策略将数据分发给 5 个 Client 线程。
但是轮循或者随机策略会存在问题，假如 5 个 Client 中 Client3 线程消费较慢，会导致给 Client3 分发数据时被阻塞，从而使得其他正常消费的线程 Client1、2、4、5 也被分发不到数据。
为了解决上述问题，可以在 Sink 算子内申请一个数据缓冲队列，队列有先进先出（FIFO）的特性。Sink 算子接收到的数据直接插入到队列尾部，五个 Client 线程不断地从队首取数据并消费，即：Sink 算子先接收的数据 Client 先消费，后接收的数据 Client 后消费。
- 若队列一直是满的，说明 Client 线程消费较慢、Sink 算子上游生产数据较快。
- 若队列一直为空，说明 Client 线程消费较快、Sink 算子的上游生产数据较慢。
五个线程共用同一个队列完美地解决了单个线程消费慢的问题，当 Client3 线程阻塞时，不影响其他线程从队列中消费数据。这里使用队列还起到了削峰填谷的作用。
文章进行了部分删减，完整内容请点击：https://developer.aliyun.com/article/740572?utm_content=g_1000096527
标签：请求,Flink,Client,线程,Sink,算子,多线程 来源： https://www.cnblogs.com/developer2020/p/12102531.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。