075_尚硅谷大数据技术_Flink理论_状态一致性（一）一致性概念和分类

下来我们再详细的给大家讲解一下，什么叫做flink里边的状态一致性啊，这一部分内容呢，主要分成这么几大部分，首先提出一下状态一致性的概念啊，以及它的一些不同状态一致性的级别分类，然后呢，我们再回顾一下所谓的一致性检查点，因为前面大家已经提到了啊，所谓的checkpoint是不是就是就是用来保证状态一致性的呀，对吧，保证状态一致性，然后呃，做这个发生故障的时候可以做故障恢复啊，然后之后呢，我们再来提出一个概念，叫做端到端的状态一致性，End to end这样的一个概念。啊，那最关键的当然就是端到端，怎么样去保证精确一次状态一致性的保证，最后呢，我们再来讲一下弗林跟卡夫卡连接在一起之后，它是怎么样去保证端到端状态一致性的，所以这就是我们这节课主要要讨论的内容，首先我们来先来说一下什么是状态一致性，简单来讲的话啊，那首先大家回忆一下什么是状态，对吧？

就是我们要分开吧，状态和一致性啊，什么叫状态呢？状态其实就是我们在这个流处理里边，每一个算子，每一个任务啊，他自己是不是都可以有内部的一些数据用来，就是我们在处理数据的时候，需要去读取，需要去保存，对吧？啊，就是额外的一些那些数据啊，自己维护的这些数据都叫做自己的状态，我们说所谓的弗link是有状态的流失处理，就是每个算子里边都可以有自己的状态。那对于流处理器内部来讲，什么叫状态一致性呢？那其实就是我们说的一致，是不是就是说的啊，这个它是准确的正确的呀。不一致的话，那就是发生错误了啊，所以我们说的计算结果要保持正确的话，这就是做到了内部的状态一致性，比方说像之前我们的这个例子，这就是说的，假如说这个读取数据啊，读到七的时候，处理到七的时候这里挂掉了。

那之后如果我们要是恢复这个状态，是不是必须这个七，就是必须是加在我们这个奇数求和里边只加一次啊，大家想，如果要是说本来我这里边七在路上的时候直接挂了，这个状态是不是没加进去，没加进去的话，那相当于之后我就应该重放，如果没重放，最后这个结果里面就少了一个七的。呃，这个求和的过程，那最终结果就不对，这就叫不一致，那如果说这个我们之前这个七是已经，或者说这里面我们说这个六吧，六这里边大家看到这是不是已经加了一次啊。12这个结果里面大家知道二加四加六是不是已经加了六了。那所以六接下来发生故障的时候，回滚的时候，六要重新重放吗？那那就考虑到如果我当时保存的这个状态直接存的是12的话，后边如果再重放六这个数据，是不是相当于六就加了两次啊。啊，所以大家要注意就是，呃，如果说我们要保证结果正确的话，数据就是不能重复计算也不能丢掉。

这就是我们说的要计算，而且只计算一次对吧，就发生故障的时候，我们可以从那个之前保存的状态里边把状态恢复出来，恢复出来之后跟没有发生故障之前是完全一样的，这就是这就是一致性的定义。呃，那我们来说一下具体这个状态一致性的分类啊，最简单的状态一致性的级别叫做at most one。字面上翻译的话，这个叫做最多一次，什么叫最多一次呢？啊，就是说可以是计算一次对吧？啊，但是也有可能，但是说最多一次的话，是不是就有可能不计算啊，那他想不计算的话，是不是我发生故障的时候啥都不干，那大不了就是这个数丢了嘛，那是不是就不计算啊，啊所以大家注意啊，就是这个at most once，其实它就代表就是什么都不干，呃，就相当于什么都没保证啊，这也是这这就能达到所谓的at most ones的这样的一个状态一致性的语义。

那那我们可能会觉得有点奇怪，这也算是状态一致性级别吗？诶，在有些场景下，其实它还是有意义的啊，比如说呃，你像之前大家应该也听说过，就是关于这个网络传输，传输层协议里边啊，比较经典的两个协议，TCP和udp，大家知道这两个协议。它们的主要特点就是TCP。要三次握手对吧？啊，这个连接的时候，这个非常重，但是建立连接之后非常有保证对不对，传输数据的话就是很稳定的一个方式，大家知道我们如果要是做一些比方说你登录网站对吧？啊网银啊，登录上去之后，它肯定是要三四握手做这个连接的，那大家想对于这个udp而言的话，它是所谓的这个用户数据报协议啊，啊，它其实是什么呢？根本不见连接。就是有数据直接就发对不对，哎，那他他想的就是，哎，反正没关系，你这个大不了我这个数据不重要对吧？呃，你如果要是丢丢一两个可能也没影响，如果要是说呃这个有影响，你那边还需要的话，我你再请求我再发一次不就完了吗。

大家想像这个udp这种协议啊，它有应用场景吗？这就看场景，这就看具体应用了，你像我们要是登录网站，这当然你不能说是我我这个请求，或者说就是我要发的这个交易，对吧，网银要做转账，丢就丢了，那那这肯定不行啊，这乱七八糟，你这什么都没有保证嘛啊所以有人就说这个呃，Udp啊，它是这个，呃，Unreallizable DA proocol就是不可靠的糟糕的协议是吧？啊，但其实在有些场景下，它还是很很有很有作用的，比如说大家想我们在看视频的时候，视频流，那你想视频流里边丢一个数据包，或者说缺缺失一点数据，这个有影响吗？哎，你稍微喊一下，或者是这个当前这个画面里边缺失一点东西，花一点无所谓对吧，马上就过去了，但是我们对什么要求比较高呢？我对当前的这个速度流畅性要要求比较高，对不对？那我实时看这个视频的话，我要的是快速流畅，所以说在这种场景下，Udp不去做繁琐的建立连接的操作，是不是就相当于可以保证传输速度啊，所以说这里面也一样，Atmo ones它它的应用场景是什么？

什么都不干，大家想，那就是说你也不用去做检查点保存对吧？啊，也不要有任何的什么简单点算法呀，什么Barry啊，去做这个处理啊，去做这个容错啊，那那你想它的特点就是。对系统性能的影响最小，对吧，那就是我所有的这个计算资源全部用来做task的处理计算，根本不用去做容错相关的保证，那就可以保证快嘛，性能最优嘛，但是带来的缺点就是没保证对吧？啊，就是数据可能丢就丢了，这就是这个atmos advance的这种状态。自然我们就想到了，在真实的场景里边，我会觉得你这个如果数据什么都没保证全丢了的话，这个太差劲儿了是吧，至少我想保证你这个数据不要丢，那这样的保证呢，就叫做at least once，字面上理解至少一次，至少一次，意思就是说，呃，我至少保证这个数据是不是要处理一次啊，而且还有可能啊，有可能要处理多次，所以它的含义就是说我只保证它不丢啊，但是呢，就是如果出现有可能出现故障的时候，我是不是就是就是不停的重放数据就完事了，你大不了就重新再做一遍嘛，对吧？啊，但是至少这个数据我是不会丢掉的，这是这种场景，呃，那我们可能想到有一些场景里边，其实这个at least ones还是可以，可以起到很好的作用的，比如说什么呢。

大家想我们在做这个数据统计的时候，很多这个平台指标里边都会做这样的一个，呃，都会做一个UV统计，对吧？那你想如果是UV数据的话，这个是不是你一个用户啊，同一个用户他的这个比方说浏览数据或者是下单数据啊，呃，他的活跃数据，你统计多次是不是最后不影响最后的UV值啊，那没问题对不对，只要他不丢，数据不丢，最后我就能保证结果，对对吧？诶所以有些场景下是没有问题的啊，那但是有一些场景肯定就不行了，就比方说像我们我要统计的是总共的订单，订单的那个销售额，那你说这个数据，你如果呃，你之前发生故障了，你不确定它到底计算没有，你再把它重放一遍，再算一遍，那那有可能加两遍，是不是这个订单就多了一倍啊啊，所以这个就是还是看具体的应用场景。

那所以at least once还是有缺陷的，那最好的最严格的状态一致性保证是什么呢？就是传说中的exactly once就是翻译过来一般是叫精确一次，或者叫恰好一次。它所说的就是。我当前所有的数据首先不能丢，每个数据都要处理到对吧，来了之后都要统计进去，然后呢，统计的结果里边只能统计一次，不管出现什么情况，对吧，不管是你发生故障回滚，还是说出现了其他的一些异常的状况，我最后回滚之后啊，重新处理也只能这个最后的结果里面只有一个，不能有重复的叠加。

这就是所谓的，大家自然就想到这个语义要求是最严格的，应该也就是最难实现的，对吧？各种异常状况你都得hold住，都得把它这个呃，就是重复计算的那种情形都排除掉，这就是所谓的状态一致性概念和分类。