一.引言
Flink 程序内有读取 hbase 的需求，近期任务启动后偶发 sink 端背压 100% 导致无数据写入下游且无明显 exception 报错，重启任务后有较大概率恢复服务，但也有可能继续背压 100% 从而堵塞任务，遂开始排查。
二.问题描述
程序执行一段时间后，查看监控发现 Source + Process + Sink 端 back pressure 背压全部达到 100% ，很明显是数据发生堵塞
查看 on-cpu 无堆栈显示因此排除 cpu 问题，需要进一步查看任务执行、IO、网络等问题，随后查看 off-cpu 的 Flame Graph 看到堆栈最终定位在:
org.apache.hadoop.hbase.util.RetryCounter.sleepUntilNextRetry
三.问题分析
1.堆栈分析
上述任务定位在 hbase 的 retryCounter.sleepUnitlNextRetry ，虽然没有看过 Hbase 的源码，但是根据这个堆栈信息大致可以判断是 hbase 读取时遇到问题导致:
retry 重试 + sleepUntilNextRetry 等待并重试
?二者结合导致任务卡死从而数据流处理堵塞，再影响后续数据，从而导致背压全部达到 100%。
2.代码定位
off-cpu 的 root 调用为下述语句，非常基本的 hbase get 操作：
Result result = hbaseTable.get(sampleGet);
按照堆栈看一下底层源码：
可以看到 Try 内逻辑真正执行的只有 1行，即 checkZk() 随后 getData()，本地测试 Get 没有问题，所以只能定位到 checkZk() 这里。
下面看一下 checkZk 主要负责什么事情：
checkZk 初始化新的 Zookeeper，如果初始化失败则返回 unable to create Zookeeper Connection，所以上面集群 hbase 无法获取数据基本定位在 Zk 创建失败。
?
3.问题解决
zookeeper 连接失败导致 Hbase Client 初始化失败从而数据无法获取导致 RetryAndSleep，一般服务器无法创建连接都因为访问过多导致，即服务过载，例如 JedisPool 的 resource，其使用有限制，超过后将无法获取连接从而导致获取数据失败。
查看 hbaes 对应 zk 下的服务器连接情况：
看到某个 ip 下存在大量 zk 连接，通过查询 zk server 的配置，查看当前单台客户端允许的最大连接数已全部被该 ip 占用，从而导致我的 Flink 程序无法初始化 zk。所以下面只需要解决这里连接过多的问题，经过排查发现该 ip 下对应 java 任务存在 zookeeper 泄露，即代码逻辑内不断申请 zookerper 连接，从而导致连接数过多，修改后空闲连接数上升，Flink-Hbase 服务也正常运行。
三.总结
1.Flink 问题定位
Flink 发生问题第一步查看 Excpetion，如果没有 Exception 就查看 Flame Graph，根据 on-cpu 和 off-cpu 的堆栈定位是 cpu 的问题还是自身代码的问题。
2.客户端初始化
Flink 初始化客户端的代码在 ProcessFunction 的 open 函数内，该方法可以保证一个 TaskManger 只初始化一个 Hbase Connection，所以很难突破单台机器初始化 zk 的限制，同学们在执行任务时也需要注意初始化无论 Hbase,Jedis 等客户端最后不要频繁初始化以及初始化过多。
?这里我初始化了 35 个 TaskManager，每个 Manger 上只初始化了一个 connection。
3.重启解决问题
上面有一个现象是我的任务重启后有一定概率恢复正常，通过上面的问题排查我们也可以得到答案，由于某 ip 下占用过多 connection，如果我的任务恰巧提交到该任务对应的机器，则我的任务无法获取连接导致堵塞，而如果任务提交恰好避开该 ip 对应的机器则代码执行无误，所以任务重启会有一定概率修复。
