认识达内从这里开始

对于程序员来说，在开发软件或者说系统运维方面，容错率一直都是一个硬性的标准。今天，我们就一起来了解一下，在不同的架构模式下的容错率都有哪些要求。

流式处理架构演化

在流式计算领域，同一套系统需要同时兼具容错和高性能其实非常难。 在传统的批处理中，当作业失败时，可以简单地重新运行作业的失败部分以修复由于之前失败导致的数据丢失。 这对于批处理是完全可行的，因为批处理的数据是静态的，可以从头到尾重放。 在连续的流式处理模型中，这种处理思路是完全不可行的。

原则上，数据流是无穷无尽的，不具有开始点和结束点。 一个带有 Buffer 缓存的数据流或许可以进行一小段的数据重放、重新计算 (即: 如果系统出错，系统可以尝试从在 Buffer 中缓存的数据流进行重新计算)，但出错时希望从数据流开始点进行重新计算是不切实际的(例如，一个流作业可以运行数月之久，当出现系统故障时候导致数据计算出错不可能参考批处理系统，从几个月前的数据开始计算)。 此外，与仅具有输入和输出的批处理作业相比，流式计算是有状态的。 这意味着除了输出之外，系统还需要备份和恢复部分计算 (我们称之为 Operator，下同) 状态。

由于这些问题带来的诸多复杂性，开源生态系统多个系统都在尝试多种方式来解决容错问题。容错机制的设计将对框架设计预计编程模型都有深远的影响，导致难以在现有的流式框架上类似插件机制一样扩展实现不一样的容错策略。因此，当我们选择流式计算内框架时，容错策略非常重要。

Distributed Snapshots (代表系统 Apache Flink™)

提供 exactly-once 流式处理语义保证的核心问题就是 确定当前流式计算的状态 (包括正在处理的数据，以及 Operator 状态)，生成该状态的一致快照，并存储在持久存储中 。如果可以经常执行状态保存的操作，则从故障恢复意味着仅从持久存储中恢复新快照，将源头 Source 回退到快照生成时刻再次进行”播放”。Flink 的状态算法在这篇论文有详细说明，以下我们给出一个简单总结。

Flink 的快照机制基于 Chandy 和 Lamport 于 1985 年设计的算法，用于生成分布式系统当前状态的一致快照(请参阅此处的详细介绍 )，不会丢失信息且不记录重复项。 Flink 使用的是 Chandy Lamport 算法的一个变种，定期对正在运行的流拓扑的状态做快照，并将这些快照存储到持久存储(例如，存储到 HDFS 或内存中文件系统)。 这些做快照的频率是可配置的。

这类似于微批处理方法，其中两个检查点之间的所有计算都作为一个整体原子地成功或失败。 然而，这个就是两者的类似点。 Chandy Lamport 算法的一个重要特点是我们永远不必按流处理中的“暂停”按钮，用来等待检查点完成后安排下一次 Batch 数据处理。 相反，常规数据处理始终保持运行，而状态持久化仅在后台发生。

延迟

一个大数据系统能否处理大规模数据量肯定至关重要。 但在流式处理系统中，另外一个特别重要的点在于计算延迟。 对于欺诈检测或 IT 安全等应用程序，在毫秒级别能够进行事件处理意味着可以避免业务损失，一套流式处理系统低只能优化到 100 毫秒的延迟通常意味着前述问题只能在业务损失发生的事后才能发现，而此时的问题发现对于我们避免业务损失实际上意义已经不大了。

作者：Kostas Tzoumas

译者：陈守元

节选：infoq

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。