gydtep

平头哥乐见更多学术机构和商业组织开源RISC-V处理器，我们也与中科院计算所有相关合作，共同探索RISC-V先进架构。
具体而言，香山处理器更侧重于敏捷开发技术，基于Chisel开发语言，对于科研领域意义重大。

gydtep

等，发生故障后重新执行计算，在存在不确定输入的前提下设计健壮的容错机制难度很大。

除了数据输入带来的挑战，流计算输出的数据会被实时消费，类似这样不同于批处理的应用场景，也给数据的一致性带来的诸多挑战，如出现 FO 后，是撤回之前发出的数据，还是是同下游进行协商实现一致性，都是需要考虑的。

gydtep

一致性相关概念祛魅
正确认识流计算系统一致性的内在含义和其能力范畴，对我们构建正确且健壮的流计算任务至关重要。下面我会介绍几组概念，以便于大家更好地理解流计算系统的一致性。

gydtep

恰好一次≠恰好一致

今天大多数流计算引擎用「Exactly-Once」去暗示用户：既然输入的数据不是静态集合而是会连续变化的，那对每一条消息「恰好处理」了一次，输出的数据肯定是一致的。上述逻辑的推导过程是没问题的，但并不严谨，因为 Exactly-Once 作为一个形容词，后面所连接的动词或者宾语被故意抹去了，不同的表达含义也会大相径庭。

gydtep

在通用解法中，我们需要存储每一次计算的中间结果，这对引擎的架构设计、配套基建能力有着很高的要求，如需要高可用、高吞吐的存储后端用于状态存储。

gydtep

。因此，我们将条件退化为可以通过事务的方式进行批量存储，这是因为事务的 ACID 特性能保证结果能以原子提交的方式作用于下游算子或者是外部的消息系统/数据库，在保证了结果（状态）一致性的前提下，能达到较高的吞吐率。

gydtep

进一步分析，每一次存储或者批量事务存储 O(t) 时，引擎到底做了什么？前面我们定义了 O(t) = Sink(t) + State(t) -> O(t) = Sink(t) + OperatorState(t) + SourceState(t) ，对于引擎来说，当出现 FailOver 时，都会通过 SourceState(t) 回拨数据

gydtep

如上图所示，Flink 引擎会定时（每个周期称之为一个 epoch）以 2PC 的方式提交结果。事实上，即便不考虑结果输出，Flink 「分布式一致性快照」的快照的实现也是一个 2PC 的过程：算子的状态快照存储类似于 2PC 的 Prepare 阶段，但 C

gydtep

ommit 的确认仅需 Coordinator（ Flink JobManager） 根据「是否收到了完整算子的 ACK 」来推出是否 Commit 或 Abort。将结果输出纳入快照生成的 2PC 后，端到端一致性数据处理语义的充分必要条件在这里也得到了满足：在流计算过

gydtep

程中，定期（epoch）以事务（2PC）的方式进行批量存储结果（分布式一致性快照 + 写外部存储）。需要注意的是，由于 Flink 会以 epoch 为周期输出结果，因此基于此构建的流处理系统会存在一定的端到端延迟。