flink实时任务因jedis连接池导致的任务阻塞问题

最新推荐文章于 2024-08-07 18:23:37 发布

L13763338360

最新推荐文章于 2024-08-07 18:23:37 发布

阅读量2k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： flink

本文链接：https://blog.csdn.net/L13763338360/article/details/110873662

本文记录了一个Flink实时任务在运行一段时间后出现阻塞的问题，详细描述了从kafka消费异常到定位到Redis写操作的问题过程。任务看似正常，但实际上不再消费kafka并导致checkpoint失败。经过排查，发现是自定义的Redis setex方法未正确释放资源，导致连接池耗尽。进一步分析jedis连接池配置，发现默认设置在资源不足时不抛出异常，建议修改为在获取连接超时时抛出异常。最后，提出了问题的解决方案和预防措施。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

问题现象

有个flink实时任务，读kafka和redis，中间有复杂的逻辑处理过程，最终结果写redis。flink实时任务运行一段时间后阻塞了，有时是几个小时后，有时是一两天后。

任务看起来正常是正常的，但kafka消费已经停止，checkpoint也失败。看日志，当问题出现后，kafka一直WARN，提示如下

Marking the coordinator xxxxxx dead.
Marking the coordinator xxxxxx dead.
Marking the coordinator xxxxxx dead.

……

任务看起来正常运行，但不再消费kafka，checkpoint失败，除此之外，cpu、mem、io、日志，均看不出异常；集群节点登陆需要申请权限，比较麻烦。

原因分析

步骤1

刚开始以为是kafka消费的问题，导致了任务阻塞。于是寻找解决办法，发现也有部分人遇到类似的问题，但办法不管用。

后面了解到kafka集群版本之前是0.9，最近升级到了2.2.0，建议更新了kafka客户端版本。升级到2.2.0客户端版本后，没有"Marking the coordinator xxx dead."的日志了，但任务还是在运行一段时间后回挂起，问题还没有解决。

步骤2

由于没有权限登陆集群节点，只能通过flink ui，观察cpu、mem、io正常，查看job manager和task manager日志，也没有发现异常。

每次任务阻塞后查看checkpoint，都是失败。刚开始以为checkpoint间隔5秒太短，于是一直往上调整到10分钟，还是照样挂。

有次checkpoint刚挂不久，发现checkpoint挂在sink redis了，其他操作都是几到几十毫秒。那大概原因找到了，写redis有问题。

同时通过最近几次任务挂起后的观察，sink redis数量好像都是在1608，资源申请的是8核cpu、单核内存4G，配置文件prod.sink.redis.maxPools=200，(200+1)*8=1608，看起来有联系？

将prod.sink.redis.maxPools设置为1或者10，问题很快就复现了，可以基本确定，问题发生在sink redis操作了。

步骤3

分析代码，因为写redis需要设置key有效时间，所以没有用原生的flink-redis-connector，而是用了flink-redis-connector+jedis，基于二者做了稍显复杂的封装，用于读写redis三种集群模式：主从复制、哨兵模式、集群模式。

最终发现，setex实现方法有问题，使用完连接后，并没有释放资源。

基本代码逻辑如下：

@Override
public String setex(String key, int seconds, String value) {
String res = null;
Jedis jedis = null;
try {
jedis = getInstance();
res = jedis.setex(key, seconds, value);
} catch (Exception e) {
logger.error("Cannot get Redis message with command GET to key {} error message {}", key, e.getMessage());

最低0.47元/天解锁文章

新学期VIP享超值加赠