简介

窗口机制是Flink流处理的核心，它将无限的流元素分割成有限的窗口。当一个窗口不再增加新元素时，就可以对这个窗口中的所有元素执行计算逻辑。而判断窗口不会再增加新元素的方式有：时间（Watermark）、计数、自定义。其中Watermark代表事件发生时的时间戳或者Flink收到事件时的时间戳。

当某个operator执行需要很长时间的话，使用异步操作对吞吐量的提升非常有帮助。

ACID和BASE

ACID是指原子性（Atomic）、一致性（Consistency）、隔离性（Isolation）、持久性（Duration）。

• 原子性 事务中的所有操作要么都成功要么都失败
• 一致性 外界访问数据库中的数据时，不会访问到事物的中间状态，只会访问到最终的状态
• 隔离性 事务之间不会相互影响，避免脏读、幻读给业务带来数据不一致问题
• 持久性 事务一旦执行成功，其最终状态会被持久化存储下来，不会失效。

BASE是指基本可用（Base Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。

• 基本可用 是指分布式系统出现故障时，允许损失部分可用性，保障系统基本可用。
• 柔性状态 是指允许系统出现中间状态，而该中间系统并不会影响系统的整体可用性。
• 最终一致性 系统在经过一段时间之后，系统中的所有副本最终会达到一致的状态。

ACID和BASE代表了两种截然相反的设计哲学。ACID是传统数据库常用的设计理念，追求强一致性模型；BASE支持的是高效的分布式数据库，通过牺牲强一致性来获得高可用性。不同的业务场景对数据的一致性要求不一样，因此这两种设计理念也可能会结合在一起使用。

一致性(consistence)和共识性(consensus)不是完全一致的概念。

数据处理语义

1. Exactly Once 精确一次
2. At Least Once 最少一次
3. At Most Once 最多一次

在处理数据时候，需要考虑在三种不同的语义会对业务产生什么影响。程序要实现不同的语言代价也是不同的，而且不同的语义对业务的影响也不一样。

数据处理过程对数据一致性的影响是强相关的。

设计一个流式任务的时候，需要从几个方面考虑：

1. 计算语义
2. 数据一致性
3. 业务场景对数据一致性的要求，不同的业务场景要求的技术方案可能也不一样

ACID原则

ACID是一种描述一致性的原则，通常出现在数据库系统中。

• A Atomicity: 原子性，事务中的所有操作要么不成功，要么都成功
• C Consistency: 一致性，外界访问数据库中的数据时，不会访问到事物的中间状态，只会访问到最终的状态
• I Isolation: 隔离性，事务可以并发执行，不会互相影响。
• D Duration: 持久性，一旦事务提交成功，状态的改变是持久的，不会失效。

单机事务一般是需要满足ACID的。

分布式事务需要多节点协作来完成一个事务，其实现方式和单机事务有很大不同，也很难满足ACID原则，实现方式和单机事务的实现方式也有很大不同。目前分布式事务是通过阶段提交来实现的，阶段提交分为二阶段和三阶段提交。

大部分高可用的场景中都会使用到ZooKeeper，例如：Hdfs，Hbase，Flink。

概要

应用场景

ZooKeeper应用场景非常广泛

1. 分布式锁

2. 高可用
   Hbase的Master选举，Flink的JobMaster选举。。

3. 发布/订阅

4. 微服务注册中心

5. 分布式队列

Flink Job有三种部署模式：

1. LAZY_FROM_SOURCES 仅当Task的上游都产生数据之后，才会真正的部署Task。
2. LAZY_FROM_SOURCES_WITH_BATCH_SLOT_REQUEST 与LAZY_FROM_SOURCES逻辑基本一致。不同的是在申请Slot的时候有超时时间限制。
3. EAGER ExecutionGraph在被调度时会将所有Task一次性到各个TaskManager。

分析Flink程序的启动过程，有助于理解和把握Flink是如何启动程序，集群和单机运行的区别，当出错时如何恢复重启，如何分配资源。

Demo

先看一个简单的stream demo

心跳

ResourceManager，TaskManager，JobManager会通过心跳来监测相互之间的状态

高可用服务

Leader选举和提取。只有配置了Zookeeper才是真正的高可用

Flink中的容错，一致性语义都是靠State来实现的。

State需要结合Checkpoint，Snapshot才能发挥作用。

State 可以按照维度进行划分：

类型：

1. Keyed State
2. Operator

数据组织格式：

1. Managed (List Value Map)
2. Raw (用户自定义的格式)

Flink以DAG的方式来执行程序，它会根据用户的代码生成三个Graph，但我认为实际上还有一个Graph，就是用户的程序直接映射出来的。

1. Plan ProgramGraph
2. StreamGraph
3. JobGraph
4. ExecutionGraph

Keyword

• Checkpoint
• Snapshot
• Barrier
• State
• Savepoint

CheckpointCoordinator定时checkpoint

CheckpointCoordinator会启动一个定时任务触发checkpoint

窗口机制是Flink流处理的核心，它将无限元素的流分割成有限元素的集合（窗口）。当一个窗口不再增加新元素时，就可以对这个窗口中的所有元素执行计算逻辑。

将一条消息从被Flink job消费到最后被sink下来的整个过程划分成两部分，算子的逻辑处理、task之间的消息传递。其中算子的逻辑处理需要用户参与，task之间的消息传递一般是不需要用户参与的，但是了解其实现过程，对理解Flink的原理是非常有帮助的。