早于Flink的异步快照的一个算法，比flink那个有名很多～ (十)简单解释: 分布式数据流的异步快照(Flink的核心)
非常简单的一个给分布式系统做consistency的快照的算法，可以应对环形流，且不需要节点知道有环(Flink的算法要求环的交接节点知道哪个input channel是环的回路)，但是要求所有通信channel是FIFO的（flink也是, 相比之下Google的MillWheel则不需要）。
算法简述
任何节点的snapshot由本地状态snapshot和节点的input channel snapshot组成
任何src可以任意时间决定take本地状态snapshot，take完本地snapshot，广播一个marker给所有下游
任意没有take本地snapshot的节点(注意这个算法里src也是可以接受别人的msg的)，假设从第x个channel收到第一个marker的时候，take本地状态snapshot(且take接受到第一个marker的input channel-x的channel snapshot为空)，然后给所有output channel广播这个marker
从收到第一个marker并take完本地snapshot之后，记录所有input channel的msg到log里，直到从所有的input channel都收到这个marker. 作为这些input channel的channel snapshot。
Flink在系统内有环形通信时的算法
套路跟Chandy-Lamport算法几乎一样。
当一个节点是环的msg流动的起点时(或者说这个节点正好同时是环的起点和终点)，它必定有一个input channel是来自自己的downstream节点的。
这个节点不能像其他节点一样，等待所有的input channel的barrier到来，才take snapshot且广播barrier，因为它有一个或多个input channel的消息是被自己往“下游”发的消息所引发的。如果它自己不向下游广播barrier，那么这些回环input channel永远也不会有barrier发来，那么算法会永久等待。
所以这个这个节点只需要等待所有非回环input channel的barrier到了，它就知道所有可能的barrier都到齐了，那么它就可以take本地snapshot且往“下游”广播barrier了（从而造成barrier会通过回路再次抵达这个节点）
重点: 此节点take完本地snapshot之后，需要记录所有回环input channel的msg到log里，直到从此回环input channel收到自己发出的barrier，当所有回环input channel都收到barrier-n. 此时在Step3 take的本地snapshot，加上所有回环input channel的msg log一起，成为此节点在barrier-n的本地snapshot
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了。
但是这很蠢。
