Flink的基石 : Chandy Lamport Algorithm

Flink处理“流”,对流消息的处理支持三种级别语义分别是“At Most once、At Least once、Exactly once”。


At Most onces:消息最多被处理一次,sender发出消息之后,receiver无论是否处理成功,都不会再重发。类似于UDP协议的效果,只管发送,不管结果。


At Least once:消息至少被处理一次,sender发出消息之后,receiver处理失败或者处理成功但是回复sender确认成功的时候超时,都会重发,直到sender确认成功。这里消息就很有可能被多次重复处理,比如超时回复、消息发送之后断网之后又重连。类似于TCP协议效果,发送之后会确保receiver接收到,但是如果receiver出现异常,消息可能被处理2次,然后导致幂等问题。


Exactly once:消息恰巧被处理一次。不管出现任何异常整套系统对这个消息只处理一次。类似于TCP协议的效果再加上幂等。


看完以上对语义的解释,这些处理语义在分布式系统的实现难度正好逐渐增加。解决掉复杂度最高的处理语义,其他的在此基础上稍微简化些就能达到。在Flink中实现语义“Exactly once”,采用的是checkpoint,使用的是Asynchronous barrier snapshots 算法,而该算法是根据Chandy Lamport Algorithm进行了一些轻微的变种。所以Chandy Lamport Algorithm算法是Flink实现语义“Exactly once”的基石,该算法受之无愧。



首先如上图中所示,Chandy 与Lamport 发布这篇paper的题目“分布式快照:确定分布式系统的全局状态”,Chandy Lamport Algorithm 算法是一个采用分布式快照算法来解决记录分布式全局状态一致的算法。


普及一下什么是快照算法。


在维基百科中这样解释:“快照算法是一个用来在分布式同创建快照来是分布式系统的状态保持一致的算法,因为分布式系统中没有一个全局共享的内存和全局时钟,所以它基本是不可能的”。


Chandy Lamport Algorithm 的基本实现流程


在论文中把分布式系统简化为两个进程(process)上进行的论证


进程 p 与进程q,它们之间数据的交互通过socket channel  c 与 c’。p 发送消息通过 c 到达q,q发送消息通过c’到达p。


在然后作者采用的“single-token conservation”的模型,在此模型中进程中只有一个token。当进程拥有token状态记为sl,进程未拥有token状态记为s0。



在这些基础概念解释之后,请先看看下图,大概理解一下这幅图。



(1)首先进程p和q启动,token  in p [ p:s1 q:s0 ]


(2)p发送token去q进程,此时正在socket channel 中 传输,token in channel [ p:s0 q:s0 ]


(3)q收到token ,token  in q[ p:s0 q:s1] 


(4)这个时候q ack回复p,token in channel [ p:s0 q:s0 ] 


(5)p 收到回复 token  in p  [ p:s1 q:s0 ] 


通过上面的流程,在任意时刻都可以记录下俩进程中token的状态,此时再推广到多个进程,多个token基本都是一样。


伪代码:


这里解释一下,代码中的maker和token 可以理解为一个东西,就是一种消息类型,根据这种消息类型判读是否开启快照。


//(1)(2)

begin 

         p  records its state;

end    

then 

        p sends one marker along c after p records its state and before p sends further messagesalong c.     

//(3)(4) 

if q has not recorded its state then 

      begin 

                 q records its state; 

                 q records the state c as the empty sequence 

      end 

else 

       q records the state of c as the sequence of messages received along c after q’s statewas recorded and before q received the marker along c.


这个算法的核心,就是创造出一个maker来记录整个分布式链的状态,当链上的节点出现异常需要恢复的时候就根据当前状态找到之前的maker,然后重新计算,保证分布式状态一致。


好了,算法已经讲完,你是否有兴趣去看看原文呢。


下一篇博文将介绍Flink基于此算法的改进


欢迎关注公众号 “技术求索之路”

回复“基石1”获取

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

推荐阅读更多精彩内容