Flink原理（一）——基础架构

Flink系列博客，基于Flink1.6，打算分为三部分：原理、源码、实例以及API使用分析，后期等系列博客完成后再弄一个目录。

该系列博客是我自己学习过程中的一些理解，若有不正确、不准确的地方欢迎大伙留言分享。文中引用均已标注，若有侵权，请联系我，立马删除！

---

1、前言

　　在讲Flink基本结构之前，我们的先知道Flink是什么？中文官网上的解释是：Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算[1]。关于无边界和有边界数据流的定义可以参考官网上的解释，从其解释上可以了解到Flink是一个框架和计算引擎，是用来处理数据流的。处理数据流并不意味着Flink仅仅能用于我们通常所说的流处理系统中，这里数据流主要是为了说明Flink处理数据的方式，是以流的形式进行的。其实不仅流处理，Flink也可以做到批处理，即Flink可以实现批/流一体化，至于如何实现的，这里仅提及相关概念，后续博客会慢慢道来。

2、Flink基本架构

　　2.1、Flink的基本架构图[2]：

　　从图中可知，Flink整个系统主要由两个组件组成：JobManager、TaskManager组件，其架构是遵循主-从设计原则的，JobManager为master结点、TaskManager为Slave结点（也称work结点），组件之间的通信是借助Akka Framework。

　　1）JobManager：负责整个Flink集群任务的调度和资源分配。从client获取提交的任务后，JobManager根据TaskManager中资源（TaskSlots）使用的情况，分配资源并命令TaskManager启动任务。在这个过程中，JobManager会触发checkpoint操作，TaskManager执行checkpoint操作，其中所有的checkpoint协调的过程都在JobManager中完成的。此外，若是任务失败了，也由JobManager协调失败任务的恢复。

　　2）TaskManager：负责具体的任务执行和结点上资源申请和管理，多结点之间的数据交换也是在TaskManager上执行。Flink集群中，每个worker（taskManager）对应的是一个JVM进程。

　　换句话说，JobManager分配资源、任务，TaskManager拥有资源、启动任务。一般在生产环境中，JobManager和TaskManager所在结点应是分离的，其目的主要是为了保证TaskManager（基于内存的计算）不抢夺JobManager的资源。

　　3）client客户端：不是runtime的一部分，换句话说，Flink集群启动client提交的任务之后，client客户端时可以断开的，是可以不需要的。client不像JobManager和TaskManager对应着 flink集群中的结点（或是物理机、或是虚拟机、或是容器），是触发执行的一个抽象化，若程序在JobManager所在结点执行，则称client在JobManager结点上，同样，其也可以在TaskManager结点上。

　　提交一个任务的正常流程是：client与JobManager构建Akka连接，将任务提交到JobManager上，JobManager根据已经注册在JobManager中TaskManager的资源（TaskSlot）情况，将任务分配给有资源的TaskManager，并命令TaskManager启动任务，TaskManager则从JobManager接受需所部属的任务，使用slot资源启动task，建立数据接入的网络连接，然后接受数据并开始处理。

　　2.2、taskSlot

　　每个task slot是TaskManager的一部分，若一个taskManager有三个taskSlot，则这三个taskSlot会均分这个TaskManager的资源（仅内存，不包括CPU）。有多个slot意味着同一个JVM中会有多个子任务，这些任务会共享JVM的TCP连接和心跳信息。这里要说明的是，slot的个数不是subtask的个数是一一对应，一个slot中可以有多个subtask。在默认情况下，同一个job中的子任务（subtask）是可以共享一个slot的。这里涉及slot共享的概念，后续博客中分析。

参考：

[1]https://flink.apache.org/zh/flink-architecture.html

[2]https://ci.apache.org/projects/flink/flink-docs-release-1.6/concepts/runtime.html