Fault-tolerance in Flink(一)|学习笔记

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 快速学习 Fault-tolerance in Flink

开发者学堂课程【开源 Flink 极速上手教程:Fault-tolerance in Flink】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/331/detail/3710


Fault-tolerance in Flink(一)


内容简介:

一、有状态的流计算

二、全局一致性快照

三、Flink 的容错机制

四、Flink 的状态管理

五、总结


一、有状态的流计算

1.流计算

流计算,本身就是会有一个数据源,持续不断的去发送消息,而同时,有一个常驻的一个程序,然后会运行自己写的代码,然后每从数据源拿到一笔消息之后,数据都会进行处理,然后把产出,把结果付出到下游。

2.分布式流计算

那什么是一个分布式的计算?其实就是说把输入流以某种方式进行一个划分,然后使用多个分布式的一个实例,然后来去对流进行处理。

3.流计算中的状态

无状态计算:只需处理单一事件

有状态计算:需要并处理多个事件

图片17.png

有状态计算例子:去重、窗口计算、机器学习/深度学习、访问历史数据

什么是流计算的状态?计算可以分成两种,有状态和无状态,无状态的计算只需要处理一个单一的事件,而有状态的计算需要记录并且处理多个时间。

举个简单的例子来说明,假如有一个事件,由时间的 ID 和时间的值两部分组成。如果处理逻辑是说,每拿到一个事件之后,都要解析并且输出事件的值,这就是一个无状态的计算。

相应的,如果说每拿到一个状态并解析它的值出来之后,需要和前一个事件的值进行比较,比前一段时间的值大的时候,才把它进行补充,那这就是一个有状态的计算。

有计算当中的状态?有很多种,比如在去重的时候,这种场景下会去掉所有的主见,又或者在窗口计算里边,比如有一个小时的窗口,已经进入那个窗口还没出发的数据,这也是它自身的状态。然后在机器学习、深度学习这种场景里边,这种蜗牛招聘的这种空间结构数据,或者说训练的模型和参数数据,那这些数据都是流计算当中的状态。


二、全局一致性快照

为何要介绍全局性拍照?因为分布式的系统的全局性快照,是给分布式的系统做故障恢复的一个方式。

1.什么是全局拍照?

什么是全局快照?就是分布式的系统做故障恢复的一个方式。

分布式应用(多个进程(领导人),分布在多个服务器上(多国)运行

应用间互通通信(消息在“管道”内进行传递)

应用内部有处理逻辑和状态(处理数据并随事件产生变化)

某一时刻的全局状态(包括各个进程的本地状态和传递中的消息)

首先,来看一下什么叫全局快照。假设,有一个 G20 的领导人系统,二零一六年的第二次会议是在杭州。对领导人系统,假如要给所有参会的领导人拍一张照,在一六年,就非常简单,应该是大家都在同一个时间同一个地点,让所有人摆好POS拍照就好了。

图片18.png

但是今年的情况比较特殊,今年因为疫情的原因,大家没有办法聚在一起,所以沙特阿拉伯的今年的第二次 G20 会面,实际上,大家都是通过网络会面,这种情况下,如果想拍一个全局拍照,就只能是大家每个领导人在不同的地点,然后分别拍一张照片,然后把它结合起来。全局拍照,首先它肯定是一个分布式应用,还有多个进程,分布在多个服务器上,另外它的员工内部,有它自己的处理逻辑和状态,移动间,目前是可以通信的。比如说这些领导人,它们就可以打电话或者发短信的,或者说在视频会议的过程当中,它们是可以互相交流的。所以,在这种分布式的应用,有内部的状态和空间可以更新的情况下,某一时刻的全局状态,就把它叫做全局的拍照。

网络异常,图片无法展示
|

2.为什么需要全局牌照?

(1).检查点(checkpointing)

用于应用程序故障恢复

(2).死锁检测

检查当前应用是否存在死锁而不影响程序运行

为什么需要分布式系统的全局拍照?第一个方面,可以用它来做检查点。将定期对它的全局状态做备份,然后当应用程序故障的时候,可以拿来恢复。第二个方面,其实可以做检测。然后对它进行拍照,然后当前的程序,可以去运行,然后可以对快照进行一个分析,应用程序是不是存在一种思索的状态,然后去进行一个相应的处理。

3.全局快照的例子

图片20.png

在分布式系统里面选取拍照的地方,第一、第二是两个进程。然后这两个进程之间,有消息发送的管道的,分批发送给第二小区的管道叫做 C12,把 P2发给批发详细的广告,叫做 C21。另外对于 PE 镜头来说,C2是它发送消息的管道,它被称为 output Channel na c21是它接收消息的管道,它被称为input channel。另外除了管道之外,每个进程还有本地的状态,比如第一和第二,每个进程的内存里都有 X、Y、Z 3 个变量,有它相应的值。p he PR 进程的本地状态,再加上它们之间发送消息的管道的状态,它是一个初始的成绩状态,它也被称为全局的拍照。假设拼音哪片儿发了一条消息,它让第二把状态从X的状态值从四改为七,但是消息,在广告中没有到达提案,状态下,它也组成一个全局的拍照。然后 P2 收到了 PE 的消息,状态它层次太高。然后第二把它本地的 X2 的值从四更改为七,同样的,这也是一个全局拍照。发现有一个特点,当有事件发生的时候,全局的状态就会发生改变,这里的时间包括进程发送一个消息,或者是经常接收到一个条件,或者进程修改它自己的状态,这都是时间。

4.什么是全局一致性快照?

当事件发生时,全局的状态发生改变,这里的事件包括:

-进程发送消息

-进程接受到消息

-进程修改状态

a->b代表在绝对时钟(real time)下a happened before b,则当一个全局快照满足下述条件时,称其为一个全局一致性快照:-如果 A->B 且 B 被包含在该快照中,则A也被包含在快照中。

什么叫全局一致性快照?已知幸存在哪里?

假如有两个事件 a 和 B,在绝对的使用下,时间是客观的,假设有一个绝对的时间,那如果在绝对的时间下,A 在 B之前发生。当一个全局快到满足什么条件的时候叫做一个全局一次性的扩张?就是如果 a 发生在 B之前,且 B 被包含在 A 当中,则 a 也被包涵在这块当中。满足条件的全局拍照,就称它为全局自信拍照。

5.判断是否是全局一致性快照的例子

图片21.png

解析:

它是一致性的特征,因为它的拍照里边这些事件,其实都是并发的,互相之间没有先后的关系。那在这种场景下,它是不是一个全局一致性的拍照?它也是一个全局性的拍照,因为它没有发生在后边的事件包含在括号里,而发生在前面的事件不包含在扩张。例子,它就不是全局一致性快照,因为发生在后面的事情被包含在拍照里,而前面的事情没有回放。

6.全局一致性快照的实现方法

想去取得这种全局一致性的拍照,怎么去实现?一种想法说那就做始终同步,有这种MTV 的 server。始终同步是没有办法保证全局性的,举例说明,看例子

图片22.png

因为 APP,它始终同步,存在时间差的它的偏差虽然有可能很小,但是它也只有毫秒级,假如说在批进程,它在本地的09:20做了本地的快照。然后接下来它的一个事件发生,并且发送一个消息给 P2,消息达到 P2的时候。它的本地的时间,还不到09:20。事件发生了之后,它本地的时间才达到09:20,那这样的话,就出现了不一致的情况。那还有什么别的其它的方法?需要一个异步的产品。

7.异步全局一致性快照算法-Chandy-Lamport

System Requirement

-快照过程不影响应用运行

快照过程中不影响手法消息

快照过程中不需要停止应用进程

-每个进程可以记录自己的本地状态

-可以分布式的对记录的状态进行收集

-任意进程都可以发起快照

前提条件:no message loss/corruption/duplication

-消息有序且不重复(channels are FIFO)

-消息可靠性可以保障

这也是接下来要讲的产品和算法。这种要求,首先第一个,它是拍照过程不影响运行,在课件过程当中不影响收发消息,然后也不需要停止进场。另外还有一个关键点,任意的进场都可以把自己区分。算法有一个前提条件,产地蓝牌儿的算法可以执行的一个前提条件和它的消息有区分,而且不重复,并且它的消息是可靠的。没有消息的丢失,没有 corruption 也没有 education,而且先发出的消息最先到达。

8. Chandy-Lamport 算法流程

(1).发起快照

(2).分布式执行快照

(3).终止快照

Chandy-Lamport 流程的算法流程,它主要分成三个部分,二次快照、分布式的执行快照、还有终止快照。

图片23.png

发起快照

-记录本地状态(本地快照)

-向 output channel 发送 marker 消息

-开始记录所有 input channel 的消息

首先发起快照的一个流程, PE 拍照,当它发出几张快照的时候,它的第一步需要记录本地的一个状态,然后做完本地拍照之后,中间没有时间间隔,那马上向它的所有output channel 发送一个 marketing,消息是一个特殊的消息,它不同于应用之间传递,需要发送的重要性。然后,P1 就会开始触发它所有 input Channel 的消息。例子里面一共只有两个进程,所以它就开始记录  C21的管道消息,这是它发起拍照的一个流程。

图片24.png

分布式执行快照:当 p1接收到来自 Cki 的 marker 消息(即 Pk 发给 Pi 的 marker)

如果这是 Pi 看到的第一个 marker 消息

-Pi 记录本地状态(本地快照)

-Pi 标记 Cki 为空

-Pi 向所有 output channel 发送 marker 消息

分布式的执行快照。先假定,当 P 接收到来自 CP 的消息,这是 C 接触到 CPI 的消息的意思,PK 发给 P 的 marker,它分两种情况,总是说是 P 看到的第一个来自于。其它管道的 marker 消息,将来它会怎么办?如果它是第一个消息,它就会先记录一下本地的状态。然后它会把 C12管道,就是极为空,也就是说后续再从批发给我的消息,就不包含在这次的拍照。然后与此同时,立刻没有时间间隔的,像它的所有的才能帮助 marker。最后一步,它会把除了 C 之外的音谱的传统的消息都开始记录,刚才也提到了,CPI 的消息,就是不再包含 P,这次拍照发还是会发的,不会包含在一次拍照。

第二种情况,如果此前 P 已经接收过 marker?那它会怎么去做?它实际上会停止记录。Ck 的消息并同时将此前记录的所有离开的消息,作为开始在本次课程中的最终状态来进行保存,再往例子里面,就是它会把CD进行保存。然后是它的一个分布式执行的一个过程。

图片25.png

终止快照

-所有进程都已经接受到来 marker 并记录了本地快照

-所有进程都从 N-1个input channel 里收到了 marker 并记录了这些 input channel的状态(消息)

-快照收集器(central server)可以开始收集每个部分的快照并形成全局一致性快照

中止拍照的两个条件:第一,所有的进程都已经接触到了 marker。消息进入了本地的拍照;第二,一个所有进程都从它的N减一个,所有的它的 link 产能收到了marker,并且触发了这些管道的状态,也就是这些消息。那等它终止之后,这块儿收集器可以开始收集每一个部分的快照,去形容群体快到了。

9.Chandy-Lamport 算法-示例

图片26.png

举一个更复杂的例子进行说明,看一个三个进程的一个例子,那在例子里面会发现,有一些状态是在内部发生的,比如 a  的状态,它跟其它的进程没有交互,对它进行一个扩展,它的内部状态就是 PE 发给自己的消息,或者说 C,是 a 到 a。进行一个扩展,三个进程的产地,全局以及拍照的怎么咨询。假设是从 T1发起快照,发起拍照的时候,先对本地的状态进行拍照,它被称为S1。然后,立刻向它的所有的output Channel,也就是 P2和 P2、P3 分别发送 marker。然后接下来它开始去记录所有的它的 input channel。

例子里面,来自管道二管到三的消息,包括它自身的消息。纵轴是按照时间来看的,相当于P3 先收到 marker,为什么 P3 和 P2 发个消息的时间,因为假设它是一个真实的物理环境里边的分布式的进场,那不同的节点之间,它的网络的状况是不一样的。那这种情况会导致它的消息到达的时间是不同的。那撤回来,T3 现在收到的marker 消息,是它收到的第一个 marker 消息。那对于它及它的第一个 marker 消息,它应该怎么去处理?首先对自己的本地状态进行一个拍照。然后它会把C13管道的标记成 close na。与此同时,她开始向它的所有的 inputChannel 发送消息。

然后第三步,它会把除了 C13之外所有的 input channel 的消息开始进行记录。检测到 P1,从 P3 来的 marker。它遇到的第一个 marker,因为它发送的 marker,也是看到的 marker。所以不是它看到的第一个,所以它把来自 C31Channel 的管道立刻关闭,并且把它目前记录的消息,当做它的才能,所以在本次课程当中的状态,把管道关闭,是指后续从第三发来的消息,实际上不会进入到本次的课程当中,是关闭的意思。

接下来消息实际上是说,P3、P2接收到了来自 P3 的消息,这是 P2 接收到的第一个消息。这是它接触到的第一个消息,它开始对本地状态做一个拍照。然后它会把C32,同时立刻马上向所有的 or to Channel 发送消息。

然后最后一步,它除了 C32 之外,开始记录所有其它 into Channel。下一个时间点,第二节收到了来自 T 的消息,这不是它看到第一个 marker,它刚才刚看到第三来的 marker 消息,然后它就把它所有的 input channel 的全部都关闭,并且记录它的产能的状态,实体里面没有状态都是 I。P1直到了来自 P2 的消息,不是它接触到的第一个 marker,它会把它所有的管道都关闭,然后把所有的管道里边的记录的消息作为它的状态,这里头有两个状态,一个是 C 的内部事件,C11 的管道自己发送给自己的一个消息,还有就是 C21,H 等地的两个事件的消息。

最后的时间点,是 T3 接收到 P2 的一个消息,那这也不是它第一个看到的 marker 消息,它也把它所有的输入管道都关闭,然后去记录中间的状态作为它的最终的状态。在此期间,本地有一个时间,会把它作为一个状态。时候为什么说它色卡就终止了,因为它所有的进程都记录在本地状态,而且每一个进场的所有的输入的广告都已经关闭了。产品拍照就结束了。就可以知道快照代表着什么,就是它记录了一个过去的时间点的一个全局,一次性的一个状态。

10. Chandy-Lamport 与 Flink 的联系

Flink 也是一个分布式的执行的系统,因此 Flink 也会采用一些拍照的方式来形成一个检查点,来支持它的故障恢复。

Flink 也采用全局一致性快照来形成检查点,支持恢复

Chandy-Lamport 支持强连通图,而 Flink 面向弱连通图

Flink 采用的是一种裁剪的(tailored)Chandy-Lamport 异步快照

Flink 的异步快照算法在 DAG 场景下不需要存储 channelstate,从而极大节省快照存储空间

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
相关文章
|
流计算
在Flink中,Regular Join(包括Left Join)的结果顺序是由Flink的分区策略和数据的分布方式共同决定的
在Flink中,Regular Join(包括Left Join)的结果顺序是由Flink的分区策略和数据的分布方式共同决定的
61 1
|
6月前
|
安全 Java Apache
实时计算 Flink版操作报错合集之恢复 checkpoint 时报 "userVisibleTail should not be larger than offset" 错误如何解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
100 0
|
6月前
|
消息中间件 关系型数据库 MySQL
实时计算 Flink版操作报错合集之使用 Event Time Temporal Join 关联多个 HBase 后,Kafka 数据的某个字段变为 null 是什么原因导致的
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
121 0
|
存储 Java 流计算
Fault-tolerance in Flink(三)|学习笔记
快速学习 Fault-tolerance in Flink
Fault-tolerance in Flink(三)|学习笔记
|
存储 消息中间件 算法
Fault-tolerance in Flink(二)|学习笔记
快速学习 Fault-tolerance in Flink
123 0
Fault-tolerance in Flink(二)|学习笔记
|
存储 消息中间件 机器学习/深度学习
Fault-tolerance in Flink | 学习笔记(三)
快速学习 Fault-tolerance in Flink
Fault-tolerance in Flink | 学习笔记(三)
|
存储 算法 C语言
|
机器学习/深度学习 流计算 开发者
|
存储 机器学习/深度学习 算法
Fault-tolerance in Flink | 学习笔记
快速学习 Fault-tolerance in Flink
110 0
Fault-tolerance in Flink | 学习笔记
|
存储 机器学习/深度学习 算法
Flink 必知必会经典课程4:Fault-tolerance in Flink
本文由 Apache Flink PMC , 阿里巴巴高级技术专家李钰分享,主要从有状态的流计算、全局一致性快照 、Flink的容错机制、Flink的状态管理 四个方面介绍 Flink 的容错机制原理。
Flink 必知必会经典课程4:Fault-tolerance in Flink