实时流处理系统的最主要的特点就是数据是持续不断地到来的，这样的数据源通常都是无边界的。对于这种数据持续不断地，实时流处理系统必须被持续地部署到集群中去，并且持续地占用集群资源。但是在分布式环境下，Failure是随时都会发送的。比如说集群机器宕机，网络拥塞，数据丢失每时每刻都可能发生，并且这种Failure是不可避免的。实时流处理系统对于这种Failure必须采取一定的措施进行Failure恢复。
1.实时流处理系统容错机制
现有的实时流处理系统对于错误恢复主要都采用以下三种做法：
1.1 Checkpoint-based recovery
在此策略中，系统中Operator会将其快照定期检入到可靠的永久性存储中。 当Operator所在的任务失败时，它将加载最近的检查点并恢复执行。 检查点的直接实现在正常执行中引入了头部，这对于维持较大内部状态的顶点并不理想。 高级检查点技术通常需要特定的数据结构，这会引入复杂性和开销。
1.2 Replay-based recovery
很多时候，由于使用窗口操作符，流式计算要么是无状态的，要么是短期记忆;也就是说，其当前的内部状态仅取决于某个持续时间（例如最后5分钟）的最近窗口中的事件。在这些情况下，一个顶点可以逃脱并不明确的检查点状态，而是重新加载事件的窗口以从最初的状态重建状态。虽然这是一种特殊情况，但通常情况下很有用处。利用这个属性，实时流处理系统可以简单地跟踪输入/输出流的序列号，而不必存储顶点的局部状态。这种策略可能需要在恢复过程中重新加载可能较大的输入事件窗口，但它避免了在正常情况下检查点的前期成本。这个策略对垃圾回收具有微妙的含义。Operator点必须在输入流中的早期事件中恢复，而不是在快照中加载状态。
当Failure发生后，实时流处理系统可以通过回放之前保存的事件来生成之前的状态，实时流处理系统通过保存输入/输出流的序列号，而不必存储顶点的局部状态。当Failure发生后，系统从之前保存的输入/输出流的序列号开始回放数据，最终达到系统Failure之前的状态。
1.3 Replication-based recovery
最后一种策略是同时运行同一个Operator的多个实例：它们可以连接到相同的输入流和输出流。 通过复制，Operator可以让实例轮流使用检查点，而不会影响读取器所观察到的延迟，因为其他实例正常运行。 当一个实例失败时，它也可以直接从另一个实例获取当前快照，以加速恢复。 所有这些好处都是以多个实例同时运行为代价的。
2. 实时流处理系统语义分析
2.1 State Semantics
实时流处理系统每个Operator保存着各自的状态State。这个状态有着各自的语义规则，其中包括Exactly Once、At least Once、At Most Once三个语义。Exactly Once 表示状态中累加的数据只累加一次，At least Once 表示状态中累加的数据累加至少一次，At Most Once 表示状态中累加的数据累加最多一次。
2.2 Output Semantics
实时流处理系统每个Operator都输出各自的数据，这个输出的数据都有各自的语义规则，其中包括Exactly Once、At least Once、At Most Once三个语义。Exactly Once 表示输出的数据只输出一次，At least Once 表示输出的数据至少输出一次，At Most Once 表示输出的数据中输出的数据最多输出一次。
