当某个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. 业务场景对数据一致性的要求，不同的业务场景要求的技术方案可能也不一样

业务

1. 详解互联网运营的本质与底层逻辑
2. 技术、产品、运营，谁才是核心？
3. 经济、市场、产业、行业
4. 市场分析、行业分析

方法

1. 如何成为技术大牛
2. 你的编程能力从什么时候开始突飞猛进- 阿莱克西斯的回答
3. 架构设计实践五部曲
4. 《软件架构设计》
5. 企业架构
6. what is togaf
7. 知识框架
8. DDD
9. 思维模型

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。