horizon client长时间不操作不断开_敖丙怎么连Flink的背压都不懂，太菜了吧？

三歪第402篇原创文章

作者：三歪

本文已收录至我的GitHub

最近一直在迁移Flink相关的工程，期间也踩了些坑，checkpoint和反压是其中的一个。

敖丙太菜了，Flink都不会，只能我自己来了。

看敖丙只能图一乐，学技术还是得看三歪

平时敖丙黑我都没啥水平，拿点简单的东西来就说我不会，麻烦专业点@敖丙。

今天来分享一下 Flink的checkpoint机制和背压原理，我相信通过这篇文章，大家在玩Flink的时候可以更加深刻地了解Checkpoint是怎么实现的，并且在设置相关参数以及使用的时候可以更加地得心应手。

上一篇已经写过Flink的入门教程了，如果还不了解Flink的同学可以先去看看：《Flink入门教程》

前排提醒，本文基于Flink 1.7

《浅入浅出学习Flink的背压知识》

开胃菜

在讲解Flink的checkPoint和背压机制之前，我们先来看下checkpoint和背压的相关基础，有助于后面的理解。

作为用户，我们写好Flink的程序，上管理平台提交，Flink就跑起来了(只要程序代码没有问题)，细节对用户都是屏蔽的。

实际上大致的流程是这样的：

1. Flink会根据我们所写代码，会生成一个StreamGraph的图出来，来代表我们所写程序的拓扑结构。
2. 然后在提交的之前会将StreamGraph这个图优化一把(可以合并的任务进行合并)，变成JobGraph
3. 将JobGraph提交给JobManager
4. JobManager收到之后JobGraph之后会根据JobGraph生成ExecutionGraph(ExecutionGraph 是 JobGraph 的并行化版本)
5. TaskManager接收到任务之后会将ExecutionGraph生成为真正的物理执行图

可以看到物理执行图真正运行在TaskManager上Transform和Sink之间都会有ResultPartition和InputGate这俩个组件，ResultPartition用来发送数据，而InputGate用来接收数据。

屏蔽掉这些Graph，可以发现Flink的架构是：Client->JobManager->TaskManager

从名字就可以看出，JobManager是干「管理」，而TaskManager是真正干活的。回到我们今天的主题，checkpoint就是由JobManager发出。

而Flink本身就是有状态的，Flink可以让你选择执行过程中的数据保存在哪里，目前有三个地方，在Flink的角度称作State Backends：

• MemoryStateBackend(内存)
• FsStateBackend(文件系统，一般是HSFS)
• RocksDBStateBackend(RocksDB数据库)

同样的，checkpoint信息也是保存在State Backends上

耗子屎

最近在Storm迁移Flink的时候遇到个问题，我来简单描述一下背景。

我们从各个数据源从清洗出数据，借助Flink清洗，组装成一个宽模型，最后交由kylin做近实时数据统计和展示，供运营实时查看。

迁移的过程中，发现订单的topic消费延迟了好久，初步怀疑是因为订单上游的并发度不够所影响的，所以调整了两端的并行度重新发布一把。

发布的过程中，系统起来以后，再去看topic 消费延迟的监控，就懵逼了。什么？怎么这么久了啊？丝毫没有降下去的意思。

这时候只能找组内的大神去寻求帮忙了，他排查一番后表示：这checkpoint一直没做上