063.尚硅谷_Flink-状态一致性_基本概念

我们给大家讲一讲link里边的状态一致性的保证啊，那这一部分内容呢，我们先给大家介绍状态一致性的概念，然后呢，再回简单的回顾一下一致一致性检查点啊，就是在flink里边，它靠什么实现状态一致性呢？主要就是靠这个checkpoint，然后后边我们继续给大家讲一讲什么叫做端到端的状态一致性啊，那后边我们主要要实现的这个端到端状态一致性，那就是要实现一个exact one的精确一次状态一致性的保证，最后我们来给大家梳理一下flink和卡夫卡连接起来的这一套系统是怎么样去保证端到端状态一致性的，好接下来我们就一一给大家做讲解，首先是状态一致性的概念，那对于一个有状态的流处理器啊，啊，这个流处理器内部来讲，其实整体来说，它所谓的状态一致性，就是这个状态的技。

状态作为这个计算结果啊，它结果要正确对吧？我们之前说过有状态的流失计算嘛，每一个算子都有自己的状态，那这个状态整体来讲的话，那其实就是说，比方说像我们讲的这个例子，就是奇偶数求和，那就是每来一个数，我这里面都要把它算在这个求和里边，如果是偶数计算的话，那就是所有的偶数，每一个偶数我都应该算在里边，对吧？呃，那那另外还有一个含义，就是说每一个偶数我应该只算一次对不对？所以这里面其实有两点要求的，就是每一条数据来了之后，我应该首先不能丢啊，你如果要是说就是这里边，你看我在计算到这个七这一步的时候，这里面挂了对吧？挂了之后，接下来你看我现在的这个状态是12跟九嘛，那如果说接下来那就你这个七有一个问题，就是说，如果说我是当前SS任务，就是它保存了一个我给这个下游传递的这个数据。

传递到哪里有这个，呃，这个上下文信息的话，那之后我可以根据这个再给它重放一遍，对吧？那如果没保存这个的话，那是不是要从数据源这里边重新去读取啊，啊，那我们就直接考虑这个重新读取的这种场景，如果重新读取数据的话，那这里边已经处理完七了，如果说这个S这里边已经处理完七了，他再读一遍不会影响我们这里边的这个状态改变，对吧？啊，所以说再读一遍这个是没问题的，然后接下来这个sum这里边七没有做过处理，九这里边没有做过这个叠加，当然就必须得再重新读一遍，如果你要是这个不再重放的话，这数就丢了嘛，啊，这是前提保证，那另外呢，就是他也不应该重复计算，对吧，就万一之前这个挂的时间节点是什么呢？是这个七已经加进去了，变成16了，这个时候挂了，然后下一个数还没读进来对吧？呃，这个在在路上的时候，这个时候挂了，那你这个七呢，那就理论上来讲。

啊，就不应该重放，或者说假如说如果重放了的话，我们后边这个状态是不是就不应该是16啊，恢复到16对不对，你如果恢复到16，再去加一次七，它就重复计算了嘛，啊所以这里边我们的要求其实就是这两条不能丢，也不能重复计算啊，所以其实最终的想法，我们想要的结果就是恢复之后的那个状态计算，就应该是跟我们当时保存检查点checkpoint的时候一模一样，然后保证我们后边做的这个计算结果是完全正确，这就是所谓的状态一致性，然后我们就会提出，基于这个就可以提出不同状态一致性的级别啊，就可以做一个分类了，那这里边给大家列出了常见的三种状态一致性级别，首先是at most one啊，字面理解的话，大家看到这个就是最多一次嘛，啊，最多一次什么意思呢？啊，就是说我当前处理这个。

数据啊，就是最多处理一次，也就是说有可能就不处理，有可能就丢了，大家想想，如果说我遇到故障的时候什么都不干，就是说我根本就啥都不管，对吧，你故障就故障了，然后后面的数据我继续继续读，继续处理，那是不是就相当于这个数据大不了就丢了，就没处理吗？这是不是就是最多一次啊，哎，所以大家看到，其实这正常来讲，就是说你什么都不做的情况下，就能保证at most once最多一次，那家可能就会觉得奇怪，你这个这也叫一个状态一致性的级别吗？啊，这这这有意义吗？实际做操作的时候有意义吗？啊，所以所以说这个其实直观来理解的话，它其实相当于就没有一致性的保证，你根本啥事都没做嘛，但是在有些场景下可能也是有用的啊，就是说比方说什么情情形下呢啊，大家就会想到，既然你什么都不做，那是不是相当于就不会有任何checkpoint的开销。

就不会有任何我们为了状态恢复，为了一致性保证而影响到我们的实时性，影响到我们的这个延迟，对吧？所以说如果我们要求当前的这个任务，他他的这个drop要求是必须要足够快，延迟一定要低，那至于结果正确性呢，无所谓对吧，你丢两个数无所谓，你你随便这个呃恢复，或者说随便这个去做处理都都是可以的，如果要只是这样的一个要求的话，那我就可以就是只要定时去存一次盘就可以了，对吧，那你也不重放数据，也不管别的，呃，你这个能恢复多少恢复多少，呃，只要是保证我还能故障之后恢复就完事了，这就是at most once。那这种用法其实在其他的一些场景里边，大家也并不陌生，比方说我们大家都很熟悉的网络传输的时候，传输层协议有这个非常著名的两个协议，一个叫做TCP，一个叫做udp，对吧？这个大家都听说过吧？啊，那平常我们日常情况下上网的时候，大家可能呃，呃，UUDP啊，平常我们上网的时候更加常常用的这个，常用到的这个，呃，这种传输层协议是什么的，当然是TCP了，对吧？啊，因为我们正常情况下你都要去登录对吧，做交互做做这个呃，一些操作，那肯定我们是需要建立一个稳定的连接的，这个时候呢，就要用到TCP协议，我们要做三次握手，大家知道对吧，那就是引发一个请求，然后确认，然后再确认，然后建立连接，开始传传输数据，那这种方式它的好处在于什么呢？就是连接有保证，如果你出现现在网络情况，网络不太稳。

定的时候，对吧，经常丢包的时候，你这个连接可能就握手就不成功，那你就得反复去尝试，直到网络比较稳定的时候，诶能够连上的时候，我再去发送数据，这样这样的话，数据基本上就是啊有保证的一个状态啊，那但是这种情况就会带来什么呢？每次你都要三次握手，肯定就会很慢嘛，对吧，传输数据的效率就没那么高，那在有些场景下，我们可能根本不需要那么精确的保持这个连接，数据丢就丢了，比方说在什么场景下呢？哎，就是我们说像这个比方说视频流对吧，我们看一段视频的时候，你丢一帧画面，丢一部分，这个数据根本没影响，对吧，马上就跳过去了，呃，对对我们接收这个信息并没有本质的影响，所以在这种场景下就可以怎么样呢？就是我只管发对吧，就是你这个数无所谓，丢就丢了对吧，大不了之后你再请求的时候，我重新再给你重新请求，重新再给你发发送一次嘛。至于我们现在。

网络情况啊，根本不管对吧，来了数据就发，来了数据就发，这个效率就会更高一些，传输的速度就会更快一些，这就是这个udp的这种协议对吧？啊，它本身叫这个用户数据报协议啊，但是有些时候这个程序员就管它叫做什么叫做这个呃，Unrelizable呃，这个DA protocol，对吧，就是不可靠的糟糕的协议啊，但是事实上它是有应用场景的，并不是说所有的场景下它都非常的糟糕啊，那像我们现在这个网络的硬件环境越来越好了之后，其实UGP也还是非成靠了，对吧？就正常来讲，我们网络不会那么差，所以说像我们这个状态一致性也是at most ones看起来不是一个好选择，但是在有些场景下，诶，这么做其实就是挺好的一种处理方式啊，那另外。

在更多的场景下，我们会想到你既然都用到flink这样的这个实时对这个状态一致性保证这么好的工具了，对吧？哎，那肯定我们想要的就不只是at most ones了，我至少你这个保证一点，我结果正确性，你不要让数据数据丢，对吧？你能不能先给我保证这个数据不丢，那保证到这一个层级的话，那我们实现的语义就是at least one，它的含义是至少处理一次，意思就是说数据至少不会丢，每个数据都会做处理，但是呢，哎，在有一些场景下，这个数据可能会重放，就会处理多次，对吧？就像我们之前那个，呃，就是这个求和，诶大家会想到了，在在这种场景下，有些时候为什么觉得这个可以接受呢？哎，因为有些场景下数据重放不影响结果，对吧，哎，你比方说这个，假如说我们的要求是，我就统计当前这个数出现过没有，如果出现过的话，诶，这个就就相当于是出不出现过的话，我最后出的结果是。

Bos，那这个你你重重放一次没关系嘛，我再再重新判断一次，还是触码，这这没什么影响对吧？但是假如说你现在是一个word count，或者说你像我们前面这个是一个sum求和，对吧，那它重放一次，这个结果就就改变了啊，这个正确性就有影响了啊，所以说就是这个至少一次at least once呢？呃，其实也不是最好的状态一致性保证，那最好的是什么呢？当然就是所谓的exactly ones对吧？传说中的exactly ones，它其实呃，它是最严格的状态一致性保证，也是最难实现的，它意味着就是同时满足了我们前面提的两个要求，首先数据不能丢，而且数据只处理一次，什么叫exactly罐词，那就是精确一次，或者说我们所说的这个就是恰好一次对吧，那恰好一次指的就是处理一次，而且只处理一次。

这样的话，我们内部的状态就是绝对正确，不会出现错误，这就是关于这个状态一致性的分类。