Flink工作原理
JobClient
JobClient是Flink程序和JobManager交互的桥梁，主要负责接收程序、解析程序的执行计划、优化程序的执行计划，然后提交执行计划到JobManager。
程序解析
Flink会将程序中每一个算计解析成Operator，然后按照算子之间的关系，将operator组合起来，形成一个Operator组合成的Graph。Flink的JobClient主要包含如下三类 Operator：
- Source Operator ，顾名思义这类操作一般是数据来源操作，比如文件、socket、kafka等，一般存在于程序的最开始
- Transformation Operator 这类操作主要负责数据转换，map，flatMap，reduce等算子都属于Transformation Operator，
- Sink Operator，意思是下沉操作，这类操作一般是数据落地，数据存储的过程，放在Job最后，比如数据落地到Hdfs、Mysql、Kafka等等。
执行计划优化
解析形成执行计划之后，JobClient还负责执行计划的优化，这里执行的主要优化是将相邻的Operator融合，形成OperatorChain。
因为Flink是分布式运行的，程序中每一个算子，在实际执行中被分隔为多个SubTask，数据流在算子之间的流动，就对应到SubTask之间的数据传递，SubTask之间进行数据传递模式有两种：
- one-to-one，数据不需要重新分布，也就是数据不需要经过IO，节点本地就能完成，比如上图中的source到map；
- re-distributed，数据需要通过shuffle过程重新分区，需要经过IO，比如上图中的map到keyBy。
显然re-distributed这种模式更加浪费时间，同时影响整个Job的性能。
Flink为了提高性能，将one-to-one关系的前后两类subtask，融合形成一个task。而TaskManager中一个task运行一个独立的线程中，同一个线程中的SubTask进行数据传递，不需要经过IO，不需要经过序列化，直接发送数据对象到下一个SubTask，性能得到提升
除此之外，subTask的融合可以减少task的数量，提高taskManager的资源利用率。图1.0中的执行计划，优化结果如下图，Flink的subTask融合规则可以参考官方文档。
JobManager
JobManager是一个进程，主要负责申请资源，协调以及控制整个job的执行过程，具体包括，调度任务、处理checkpoint、容错等等。
在接收到JobClient提交的执行计划之后，针对收到的执行计划，继续解析，因为JobClient只是形成一个operaor层面的执行计划，所以JobManager继续解析执行计划（根据算子的并发度，划分task），形成一个可以被实际调度的由task组成的拓扑图，如上图被解析之后形成下图的执行计划，最后向集群申请资源，一旦资源就绪，就调度task到TaskManager。
TaskManager
TaskManager是一个进程，及一个JVM（Flink用java实现）。主要作用是接收并执行JobManager发送的task，并且与JobManager通信，反馈任务状态信息。
比如任务分执行中，执行完等状态，上文提到的checkpoint的部分信息也是TaskManager反馈给JobManager的。
如果说JobManager是master的话，那么TaskManager就是worker主要用来执行任务。在TaskManager内可以运行多个task。
Slot
Slot是TaskManager资源粒度的划分，每个Slot都有自己独立的内存。所有Slot平均分配TaskManger的内存，比如TaskManager分配给Solt的内存为8G，两个Slot，每个Slot的内存为4G，四个Slot，每个Slot的内存为2G。
值得注意的是，Slot仅划分内存，不涉及cpu的划分。同时Slot是Flink中的任务执行器（类似Storm中Executor），每个Slot可以运行多个task，而且一个task会以单独的线程来运行。
共享Slot
在flink中允许task共享Slot提升资源利用率，但是如果一个Slot中容纳过多task反而会造成资源低下（比如极端情况下所有task都分布在一个Slot内），在Flink中task 按照如下规则共享Slot：
- 同一个job中，同一个group中不同operator的task可以共享一个Slot
- Flink是按照拓扑顺序从Source依次调度到Sink的
