Flink 容错性机制- 屏障(barrier)实现原理

我们知道Flink提供了容错机制,能够在应用失败的时候重新恢复任务。这个机制主要就是通过持续产生快照的方式实现的。Flink快照主要包括两部分数据一部分是数据流的数据,另一部分是operator的状态数据。对应的快照机制的实现有主要两个部分组成,一个是屏障(Barrier),一个是状态(State)。因为Flink这里处理的数据流,数据在多个operator的DAG拓扑中持续流动,要想实现某个时刻快照可以用于系统故障恢复,必须保证这个快照,完全能够确定某一个时刻状态,这个时刻之前的数据全部处理完,之后的数据一个都没有处理。这里就引入了屏障这个概念。这里我们主要介绍一下屏障实现。

屏障 Barrier

Flink 分布式快照里面的一个核心的元素就是流屏障(stream barrier)。这些屏障会被插入(injected)到数据流中,并作为数据流的一部分随着数据流动。屏障并不会持有任何数据,而是和数据一样线性的流动。可以看到屏障将数据流分成了两部分数据(实际上是多个连续的部分),一部分是当前快照的数据,一部分下一个快照的数据。每个屏障会带有它的快照ID。这个快照的数据都在这个屏障的前面。从图上看,数据是从左向右移动(右边的先进入系统),那么快照n包含的数据就是右侧到下一个屏障(n-1)截止的数据,图中两个灰色竖线之间的部分,也就是part of checkpoint n。另外屏障并不会打断数的流动,因而屏障是非常轻量的。在同一个时刻,多个快照可以在同一个数据流中,这也就是说多个快照可以同时产生。


屏障示意图

如果是多个输入数据流,多个数据流的屏障会被同时插入到数据流中。快照n的屏障被插入到数据流的点(我们称之为Sn),就是数据流中一直到的某个位置(包含了当前时刻之前时间的所有数据),也就是包含的这部分数据的快照。举例来说,在Kafka中,这个位置就是这个分区的最后一条记录的offset。这个位置Sn就会上报给 checkpoint 的协调器(Flink的 JobManager)。

然后屏障开始向下流动。当一个中间的operator收到它的所有输入源的快照n屏障后,它就会向它所有的输出流发射一个快照n的屏障,一旦一个sink的operator收到所有输入数据流的屏障n,它就会向checkpoint的协调器发送快照n确认。当所有的sink都确认了快照n,系统才认为当前快照的数据已经完成。

一旦快照n已经执行完成,任务则不会再请求Sn之前的数据,因为此刻,这些数据都已经完全通过了数据流拓扑图。

对齐机制

接收不止一个数据输入的operator需要基于屏障对齐输入数据流。详述如下:
整个流程图如下所示

image.png

然后我们挨个看一下:

  • 当operator接收到快照的屏障n后并不能直接处理之后的数据,而是需要等待其他输入快照的屏障n。否则话,将会将快照n的数据和快照n+1的数据混在一起。图中第一个所示,operator即将要收到数据流1(上面这个我们当成数据流1(6,5,4,3,2,1),下面的当成数据流2好了)的屏障n,1,2,3在屏障n之后到达operator,这个时候如果数据流1的继续处理,那么operator中就会包含n屏障之后的数据(1,2,3),但是operator中此刻在接收和处理数据流2,数据(a,b,c)就会和数据流1中的(1,2,3)混合。


    image.png
  • 快照n的数据流会被暂时放到一边。从这些数据流中获取到的数据不会被处理,而是存储到一个缓冲中。图中第一个所示,因为数据流2的屏障n还没到,所以operator持续接收1,2,3然而并不做任何处理。但是需要将1,2,3存入到buffer中。此时第二个数据流接到a,b,则直接发送,接到c发送c。
image.png
  • 一旦最后一个数据流收到了快照n,opertor就会将发出所有阻塞的数据,并发出自己的屏障。如图中第三个所示,operator最后收到了另一个数据流的屏障n,然后再发出a,b,c(图中operator中的c,b,a)以后,发出自己的屏障,这个时候buffer中又增加了一个4,变成(4,3,2,1)。
image.png
  • 之后operator会重新开始处理所有的输入数据流,先处理buffer中的数据,处理完之后再处理输入数据流的数据。如图第四个所示,先将buffer中的1,2,3,4先处理完,在接收并处理这两个数据源的数据。
image.png

··=-·=···············

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容

  • Flink总结 Flink简介 Apache Flink作为一款高吞吐量、低延迟的针对流数据和批数据的分布式实时处...
    bigdata_er阅读 10,585评论 0 10
  • Apache Flink是一个面向分布式数据流处理和批量数据处理的开源计算平台,它能够基于同一个Flink运行时,...
    康小为6840阅读 1,183评论 0 7
  • 记录一下曾经走过的一些坑,一定要注意operator状态之前尽量不要用keyby Flink提供了Exactly ...
    大酱游说大数据阅读 3,889评论 0 3
  • Flink源码分析系列文档目录 请点击:Flink 源码分析系列文档目录[https://www.jianshu....
    AlienPaul阅读 2,883评论 0 1
  • 大家都觉得文敏独立有想法稳妥 只有他知道文敏也是一个需要被照顾的女生 哈哈 今天的大象先生,有点甜。
    文敏_4e83阅读 243评论 0 0