1.Job Managers、Task Managers、客户端（Clients）
Flink 运行时包含两类进程：
- JobManagers （也称为 masters）协调分布式计算。它们负责调度任务、协调 checkpoints、协调故障恢复等。
每个 Job 至少会有一个 JobManager。高可用部署下会有多个 JobManagers，其中一个作为 leader，其余处于 standby 状态。 - TaskManagers（也称为 workers）执行 dataflow 中的 tasks（准确来说是 subtasks ），并且缓存和交换数据 streams。
每个 Job 至少会有一个 TaskManager。
JobManagers 和 TaskManagers 有多种启动方式：直接在机器上启动（该集群称为 standalone cluster），在容器或资源管理框架，如 YARN 或 Mesos，中启动。TaskManagers 连接到 JobManagers，通知后者自己可用，然后开始接手被分配的工作。
客户端虽然不是运行时（runtime）和作业执行时的一部分，但它是被用作准备和提交 dataflow 到 JobManager 的。提交完成之后，客户端可以断开连接，也可以保持连接来接收进度报告。客户端既可以作为触发执行的 Java / Scala 程序的一部分，也可以在命令行进程中运行./bin/flink run ...。
2.任务与算子链
分布式计算中，Flink 将算子（operator）的 subtask 链接（chain）成 task。每个 task 由一个线程执行。把算子链接成 task 能够减少线程间切换和缓冲的开销，在降低延迟的同时提高了整体吞吐量。（在 flink 中一般用 subtasks 指代 task）
3.Task Slot 与资源
每个 worker（TaskManager）都是一个 JVM 进程，并且可以在不同的线程中执行一个或多个 subtasks。为了控制 worker 接收 task 的数量，worker 拥有所谓的 task slot （至少一个）。
每个 task slot 代表 TaskManager 的一份固定资源子集。例如，具有三个 slot 的 TaskManager 会将其管理的内存资源分成三等份给每个 slot。 划分资源意味着 subtask 之间不会竞争资源，但是也意味着它们只拥有固定的资源。注意这里并没有 CPU 隔离，当前 slots 之间只是划分任务的内存资源。
拥有多个 slot 意味着多个 subtasks 共享同一个 JVM。 Tasks 在同一个 JVM 中共享 TCP 连接（通过多路复用技术）和心跳信息（heartbeat messages）。它们还可能共享数据集和数据结构，从而降低每个 task 的开销。
默认情况下，Flink 允许一个 slot 有多个 subtasks，即使它们是不同 tasks 的 subtasks，只要它们来自同一个 job。因此，一个 slot 可能会负责这个 job 的整个管道（pipeline）。
Slot 的数量：根据经验，合理的 slots 数量应该和 CPU 核数相同。在使用超线程（hyper-threading）时，每个 slot 将会占用 2 个或更多的硬件线程上下文（hardware thread contexts）。
4.State Backends
key/values 索引存储的数据结构取决于 state backend 的选择。一类 state backend 将数据存储在内存的哈希映射中，另一类 state backend 使用 RocksDB 作为键/值存储。除了定义保存状态（state）的数据结构之外， state backend 还实现了获取键/值状态的时间点快照的逻辑，并将该快照存储为 checkpoint 的一部分。
233
