1 - Flink Code
flink-client
CliFrontend
build StreamGraph
org.apache.flink.client.cli.CliFrontend#main
FLINK_CONF_DIR=./flink-dist/src/main/resources
# submit a job
run ./flink-examples/flink-examples-streaming/target/WordCount.jar
flink-runtime
StandaloneSessionClusterEntrypoint
run JobManager
org.apache.flink.runtime.entrypoint.StandaloneSessionClusterEntrypoint
-c ./flink-dist/src/main/resources
2 - Flink Deploy
Cluster
Starting a Session Cluster on Docker
# https://ci.apache.org/projects/flink/flink-docs-master/docs/deployment/resource-providers/standalone/docker/#starting-a-session-cluster-on-docker
FLINK_PROPERTIES="jobmanager.rpc.address: flink-jobmanager"
docker network create flink
# launch the JobManager
docker run -d \
--name=flink-jobmanager \
--network flink \
--publish 8081:8081 \
--env FLINK_PROPERTIES="${FLINK_PROPERTIES}" \
flink jobmanager
# one or more TaskManager containers
docker run -d \
--name=flink-taskmanager1 \
--network flink \
--env FLINK_PROPERTIES="${FLINK_PROPERTIES}" \
flink taskmanager
# submit a task
./bin/flink run ./examples/streaming/TopSpeedWindowing.jar
3 - Flink Principle
整体架构
Flink系统由Flink Program、JobManager、TaskManager三个部分组成。这三部分之间都使用Akka框架(Actor System)进行通信, 通过发送消息驱动任务的推进。
Flink Program 加载用户提交的任务代码，解析并生成任务执行拓扑图，并将拓扑图提交给JobManager。
JobManager基于任务执行拓扑图，生成相应的物理执行计划，将执行计划发送给TaskManager执行。除此之外，JobManager还负责协调checkpoint的生成，不断地从TaskManager收集Operator的状态，并周期性生成checkpoint，以便在系统出错时从checkpoint恢复之前的状态。
TaskManager负责管理任务执行所需的资源，执行具体的任务，并将任务产出的数据流传入给下一个任务。每个TaskManger上运行一个jvm进程。每个TaskSlot运行一个线程
一致性保证与出错处理
分布式场景中，数据会丢失、会乱序、会重复。乱序的问题，结合Event Time (表征事件发生的时间)与 Watermark(表征何时数据已经完整的标识)解决。针对丢失和重复的问题，Flink通过分布式快照(distributed snapshot),支持了Exactly Once的一致性语义
分布式快照
Flink基于Chandy and Lamport算法,实现分布式快照机制
在正常的数据流中，Flink会周期性插入一种特殊的数据记录 - barrier，当算子处理到barrier的时候，会保存算子当前的状态到持久性存储。当算子包含多个输入的时候，需要对齐多个barrier(align barriers)。当算子某个输入率先接收到barrier的时候，会缓存该输入的后续数据，直到所有的输入都收到barrier之后，才会触发状态备份操作，并输出barrier到下游算子。
除了备份各个算子的状态生成snapshot之外，对于sink还需要执行一步额外操作 —— 将结果写入外部设备。Flink通过两阶段提交的机制(2PC,two-phase commit), 来实现这个分布式事务。
流量控制
下游的InputChannel从上游的ResultPartition接收数据的时候，会基于当前已经缓存的数据量，以及可申请到的LocalBufferPool与NetworkBufferPool，计算出一个Credit值返回给上游。上游基于Credit的值，来决定发送多少数据。Credit就像信用卡额度一样，不能超支。当下游发生数据拥塞时，Credit减少值为0，于是上游停止数据发送。拥塞压力不断向上游传导，形成反压。