-- at most onece:最多一次,如果算子处理事件失败,事件将不再尝试该事件。
-- at least onece:至少一次,如果算子处理事件失败,算子会再次尝试该处理事件,直到有一次成功。
-- 1.分布式快照+状态检查点,思想就是对比检查点和分布式快照中的状态,如出现状态不一致就回退到最小状态处,重新计算。
-- 2.at least onece + 去重,重播失败的算子,并删除重复算子的结果。
-- 虽然从理论上看,分布式快照,和至少一次事件交付外加去重,这两种机制之间存在差异,但两者均可理解为至少一次处理外加幂等保证。
上文提到的两种机制均使用持久的后端存储作为事实来源(source of truth),用于保存每个操作符的状态,并自动提交状态更新。对于机制 1(分布式快照 / 状态检查点),这个持久的后端存储可用于保存流应用程序中全局一致的状态检查点(每个运算符的状态检查点);对于机制 2(至少一次事件交付,外加去重),这个持久的后端存储可用于保存每个运算符的状态,以及为了追踪哪些事件已经被成功处理过而为每个运算符生成的事务日志。
状态的提交或对事实来源的持久后端进行的更新可描述为事件(occurring)的严格一次。然而在计算状态的更新 / 改动,例如所处理的事件正在针对事件执行各种用户定义的逻辑时,如果失败则可能进行多次,这一点正如上文所述。换句话说,事件的处理可能会进行多次,但处理的最终结果只会在持久的后端状态存储中体现一次。因此 streamlio 认为“实际一次(effectively-once)”可以更精确地描述这样地处理语义。
如对本文有疑问, 点击进行留言回复!!
去 HBase,Kylin on Parquet 性能表现如何?
如何找到Hive提交的SQL相对应的Yarn程序的applicationId
如何在 HBase Shell 命令行正常查看十六进制编码的中文?哈哈~
网友评论