免费领取阿里云大礼包3150元+新客享0.26折起优惠

gydtep2002

例子2，后接不同的名词：Exactly-once State Consistency 和 Exactly-once Process Consistency。前者是 Flink 在官网中对其一致性的叙述，后者是 Kafka Streaming 的一致性保证，前者的语义约束弱于后者。

gydtep2002

当在故障发生的时间小于 t （数据没有输出）或者 大于 t + 1（数据已经输出了），数据肯定是一致的。

gydtep2002

可以通过回拨数据偏移量得到，O(t) 需要从持久化存储中获取。

gydtep2002

由于 O(t) = Sink(t) + State(t) ，引擎内部很好实现幂等状态更新，若引擎下游系统也实现了数据幂等，

gydtep2002

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

gydtep2002

将结果输出纳入快照生成的 2PC 后，端到端一致性数据处理语义的充分必要条件在这里也得到了满足：在流计算过程中，定期（epoch）以事务（2PC）的方式进行批量存储结果

gydtep2002

如果稍微回顾一下 Flink 一致性的实现逻辑，会发现这两者有很多相似点，因此 Kafka Streams 的输出结果也会存在一定的端到端延迟。

gydtep2002

但太小的间隔将导致吞吐下降，因此吞吐量与端到端处理延迟之间需要有一个折衷。

gydtep2002

如果 Spark Streaming 存在非确定性的计算，则不能实现端到端一致，原因是

gydtep2002

上面的充分必要条件还可以进一步简化，即实时存储结果或定期事务，均可以视为当前处理逻辑单元（算子或最终存储）对上游的输入（引擎状态+输出结果）进行的幂等化处理