简单解释: 分布式快照(Chandy-Lamport算法)

简单解释: 分布式快照(Chandy-Lamport算法)

早于Flink的异步快照的一个算法,比flink那个有名很多~ (十)简单解释: 分布式数据流的异步快照(Flink的核心)

非常简单的一个给分布式系统做consistency的快照的算法,可以应对环形流,且不需要节点知道有环(Flink的算法要求环的交接节点知道哪个input channel是环的回路),但是要求所有通信channel是FIFO的(flink也是, 相比之下Google的MillWheel则不需要)。

算法简述

  1. 任何节点的snapshot由本地状态snapshot和节点的input channel snapshot组成
  2. 任何src可以任意时间决定take本地状态snapshot,take完本地snapshot,广播一个marker给所有下游
  3. 任意没有take本地snapshot的节点(注意这个算法里src也是可以接受别人的msg的),假设从第x个channel收到第一个marker的时候,take本地状态snapshot(且take接受到第一个marker的input channel-x的channel snapshot为空),然后给所有output channel广播这个marker
  4. 从收到第一个marker并take完本地snapshot之后,记录所有input channel的msg到log里,直到从所有的input channel都收到这个marker. 作为这些input channel的channel snapshot。


Flink在系统内有环形通信时的算法

套路跟Chandy-Lamport算法几乎一样。

  1. 当一个节点是环的msg流动的起点时(或者说这个节点正好同时是环的起点和终点),它必定有一个input channel是来自自己的downstream节点的。
  2. 这个节点不能像其他节点一样,等待所有的input channel的barrier到来,才take snapshot且广播barrier,因为它有一个或多个input channel的消息是被自己往“下游”发的消息所引发的。如果它自己不向下游广播barrier,那么这些回环input channel永远也不会有barrier发来,那么算法会永久等待。
  3. 所以这个这个节点只需要等待所有非回环input channel的barrier到了,它就知道所有可能的barrier都到齐了,那么它就可以take本地snapshot且往“下游”广播barrier了(从而造成barrier会通过回路再次抵达这个节点)
  4. 重点: 此节点take完本地snapshot之后,需要记录所有回环input channel的msg到log里,直到从此回环input channel收到自己发出的barrier,当所有回环input channel都收到barrier-n. 此时在Step3 take的本地snapshot,加上所有回环input channel的msg log一起,成为此节点在barrier-n的本地snapshot
  5. Failover,failover的时候,除了从本地snapshot恢复状态之外,还需要replay所有input channel的msg。


简单的玄学解释“为什么”

  • 一个分布式系统的snapshot可以理解为时间静止时,系统的各个节点的状态和他们之间的channel的状态(channel里的msg list),就是一个stream集合和table集合的剪影。stream指还在channel里没有融入到table里的msg list,tables可以理解为各个节点的本地状态。
  • 从src开始,当src take一个snapshot之后,任何被src在snapshoting之前发出过的"历史msg"所引起的“蝴蝶效应”都必须被下游记录,才能构成完整的整个系统的consistent global snapshot, 难点在于, 我们无法时间静止,所以src在不知道下游什么状况的情况下,还是要继续往下游发msg,那么对所有下游节点,区分那些是“历史msg”和“历史msg引起的蝴蝶效应msg”,还是“new event”, "new msg引起的蝴蝶效应msg"是难点;任何被src的eventA所因果导致的eventB,C,D,E,都必须记录,对任意系统的msg(或者说event),要么这个event已经被状态吸收,merge在某节点最终的table里(这时候这个节点有可能会因为接受到这个event而发出另外的别的event,也需要保证在下游记录),要么这个event需要记录在这个节点的input stream log里。
  • 对于环来说,所有的被"历史event“所因果导致的"发给本节点的需要记录的"未来状态"还未到来,但是已经有"new event"(比如从src来的新消息)来改本地状态了,所以不能等待回环的消息,而必须先把本地状态take snapshot了才行,作为”历史msg的因果导致的msg“,只能作为”未来event“记录在stream log里了。
    • 当然flink的算法也可以设计为,即使非回环input channel的barrier都到齐了,也不unblock input channel ,而是等待所有的回环input channel的barrier也都到齐了,才take本地snapshot,且一起unblock所有的input channel;这样就不需要维护stream log了。
    • 但是这很蠢。



请点赞以给作者鼓励和动力。


发布于 2018-09-13

文章被以下专栏收录

    很多书和论文(特别是论文),写的比较晦涩难懂,有时候看懂了,但是没有把自己当时怎么理解的记录下来,很快就会忘记。我自己已经有习惯在自己的笔记本上记录我的理解,和一些我觉得珍贵的知识了。而且这些记录也是给自己的知识作索引,因为很多时候人无法把所有东西都塞在脑子里边,记住什么东西的细节能在什么地方找到,这才是读书最重要的。 既然自己本身就会记录这些东西,那么不如找一个大家都能看到的地方,分享知识吧,这,就是建立这个专栏的原因了