状态一致性

什么是状态一致性

有状态的流处理，内部每个算子任务都可以有自己的状态。
对于流处理器内部（没有接入sink）来说，所谓的状态一致性，其实就是我们所说的计算结果要保证准确，一条数据不应该丢失，也不应该重复计算。
在遇到故障时可以恢复状态，恢复以后的重新计算，结果应该也是完全正常的。

状态一致性种类

最多一次（At-Most-Once）
- 任务发生故障时最简单的措施就是既不恢复丢失的状态，也不重放丢失的事件，所以至多一次是最简单的一种情况。
- 它保证了每个事件至多被处理一次。
至少一次（At-Least-Once）
- 对于大多数现实应用而言，用户的期望是不丢事件，这类保障被称为至少一次。
- 它意味着所有事件最终都会处理，虽然有些可能会处理多次。
精确一次（Exactly-Once）
- 精确一次是最严格，最难实现的一类保障。
- 它不但能够保证事件没有丢失，而且每个事件对于内部状态的更新都只有一次。
- Flink利用Checkpoints机制来保证精确一次语义。

端到端（end-to-end）状态一致性

端到端的保障指的是在整个数据处理管道上结果都是正确的。在每个组件都提供自身的保障情况下，整个处理管道上端到端的保障会受制于保障最弱的那个组件。

那么端到端的精确一次在各部分又是如何实现的呢？

内部：Checkpoints机制，在发生故障的时候能够恢复各个环节的数据。
Source：可设置数据读取的偏移量，当发生故障的时候重置偏移量到故障之前的位置。
Sink：从故障恢复时，数据不会重复写入外部系统。

其中前两种在上文已经介绍过了，下面就介绍一下Sink如何提供端到端的精确一次性保障。

Sink端到端状态一致性的保证

应用若是想提供端到端的精确一次性保障，就需要一些特殊的Sink连接器，根据情况不同，这些连接器可以使用两种技术来实现精确一次保障：

幂等性写（idempotent write）
- 幂等操作的含义就是可以多次执行，但是只会引起一次改变。
- 例如我们将相同的键值对插入一个哈希结构中就是一个幂等操作，因为由于该键值对已存在后，无论插入多少次都不会改变结果。
- 由于可以在不改变结果的前提下多次执行，因此幂等性写操作在一定程度上减轻Flink检查点机制所带来的重复结果的影响
事务性写（transactional write）
- 事务性写其实就是原子性写，即只有在上次成功的检查点之前计算的结果才会被写入外部Sink系统。
- 事务性写虽然不会像幂等性写那样出现重放过程中的不一致现象，但是会增加一定延迟，因为结果只有在检查点完成后才对外可见。
- 实现思想：构建的事务对应着Checkpoints，待Checkpoints真正完成的时候，才把所有对应的结果写入Sink系统中。
- 实现方式：
  - 预写日志（Write Ahead Log，WAL）
  - 两阶段提交（Two Phase Commit，2PC）

预写日志

把结果数据先当成状态保存，然后在收到Checkpoints完成的通知时，一次性写入Sink系统。
简单易于实现，由于数据提前在状态后端做了缓存，所以无论什么Sink系统都能用这种方式一批搞定。
但同时它也存在问题，写入数据时出现故障则会导致一部分数据成功一部分失败。
DataStream API提供了一个模板类GenericWriteAheadSink，来实现这种事务性Sink。

两阶段提交

对于每个Checkpoints，Sink任务会启动一个事务，并将接下来所有接收的数据添加到事务里。
然后将这些数据写入外部 Sink，但不提交它们，这时只是“预提交”。
当它收到Checkpoints完成的通知时，它才正式提交事务，实现结果的真正写入。
这种方式真正实现了精确一次，它需要一个提供事务支持的外部Sink系统，Flink提供了TwoPhaseCommitSinkFunction接口。
对外部Sink系统的要求
- 外部Sink系统必须提供事务支持，或者Sink任务必须能够模拟外部系统上的事务。
- 在Checkpoints的隔离期间里，必须能够开启一个事务并接受数据写入。
- 在收到Checkpoints完成的通知之前，事务必须是“等待提交”的状态。在故障恢复的情况下，这可能需要一些时间。如果这个时候 Sink系统关闭事务（例如超时了），那么未提交的数据就会丢失。
- Sink任务必须能够在进程失败后恢复事务。
- 提交事务必须是幂等操作。

不同Source和Sink的一致性保证

Flink+Kafka端到端状态一致性的保证

内部：利用Checkpoints机制把状态保存，当发生故障的时候可以恢复状态，从而保证内部的状态一致性。
source 端：Kafka Consumer作为Source，可以将偏移量保存下来，当发生故障时可以从发生故障前的偏移量重新消费数据，从而保证一致性。
sink端：Kafka Producer作为Sink，采用两阶段提交Sink，需要实现一个TwoPhaseCOmmitSinkFunction。

Flink 状态一致性：端到端状态一致性的保证相关推荐

吐血之作 | 流系统Spark/Flink/Kafka/DataFlow端到端一致性实现对比
长文预警, 全文两万五千多字, 37页word文档的长度 (略有杂乱,有些非常复杂的地方可能需要更多的例子来说明,使得初学者也能很容易看懂,但是实在花的时间已经太多太多了,留待后边利用起碎片时间一点点 ...
端到端一致性,流系统Spark/Flink/Kafka/DataFlow对比总结(压箱宝具呕血之作)
前这篇文章可以说是作者压箱底儿的知识总结(之一,毕竟作者学的东西很杂 ╮(￣▽￣"")╭ )了. 断断续续写了将近三个月, 耗费了大量的精力, 本来的目的本来只是想对比一下各个s ...
Flink端到端一致性
流式计算中,端到端表示从外部读取数据.中间处理.数据输出外部三个处理环节.在理想状态即7*24任务不出错或者异常情况下,也就是每一步处理都正常,那么就能保证最终处理输出的数据正确,但是在实际的情况中, ...
Flink 端到端一致性
1.at-most-once: 故障发生之后,计数结果可能丢失.同样的还有udp. 2.at-least-once: 计数程序在发生故障后可能多算,但是绝不会少算. 3.exactly-once: 这 ...
压箱底总结：流系统端到端一致性对比
点击上方"朱小厮的博客",选择"设为星标" 回复"666"获取公众号专属资料分布式最难的2个问题: 1.Exactly Once Mess ...
分布式理论二阶段提交 2PC 3PC 端到端一致性分布式事务
一.临界知识对我们学习的巨大帮助临界知识这个概念,是我上个月读<好好学习:个人知识管理精进指南>这本书学到的概念,真的有被启发到,现在觉得它对于我们深刻了解世界有着非常大的作用. 所谓临 ...
利用blinker，让arduino实现多路继电器状态控制和APP端状态反馈
利用blinker,让arduino实现多路继电器状态控制和APP端状态反馈有需要的朋友可以直接拷贝代码拿来使用,按钮是自锁按钮控制的,不是点动开关型的.这是经过许多人的经验总结和奉献才调通的程序, ...
小程序身份认证服务器,如何实现微信小程序与.net core应用服务端的无状态身份验证...
随着.net core2的发布,越来越多人使用.net core2开发各种应用服务端,下面我就结合自己最近开发的一款小程序,给大家分享下,怎么使用小程序登录后,小程序与服务端交互的权限控制. 服务端的 ...
发送端未知信道状态信息情况下MIMO系统容量仿真
在发送端与接收端天线个数不同的情况下,MIMO系统的容量 clear all; close all; M=1000;%循环次数 n_bins=round(M/10);%round函数用于舍入到最接近的 ...

Flink 状态一致性：端到端状态一致性的保证

文章目录