在日常的数据处理中，比如电商平台每秒产生的订单、用户行为日志，或是社交平台上的消息流，数据量动辄上TB甚至PB级别。这些任务通常依赖像Apache Spark、Flink这样的大数据处理框架来完成。但机器会宕机，网络会波动，程序也可能出错。这时候，容错机制就成了系统稳定运行的“保险丝”。
数据丢失不可怕，重算就行
Spark采用的是基于血统（Lineage）的容错方式。简单说，它不直接保存每个计算结果，而是记录下数据是从哪里来、经过了哪些转换。比如从原始日志读取，做过滤、聚合，最后输出报表。如果某个节点挂了，导致中间结果丢了，Spark不会去别的地方找备份，而是根据记录的操作步骤，重新计算一遍。
这就像你做菜时没保存步骤，锅打翻了就得从头再来。但如果你记了菜谱，哪怕中间失败，也能按原路重做一遍。Spark的RDD（弹性分布式数据集）就是靠这种“菜谱式”记录实现容错的。
检查点：定期存档防万一
虽然重算可行，但如果链条太长，比如跑了两个小时的任务，从头再来显然不现实。因此，框架会定期做检查点（Checkpoint），把当前状态写入可靠的存储，比如HDFS。一旦出问题，就从最近的检查点恢复，而不是最开始。
这类似于打游戏时的存档机制。你不会希望每次角色死亡都从第一关开始吧？每隔几关自动存一次，失败后从最近一关继续，效率高多了。
Flink的状态与快照
对于实时流处理框架如Flink，情况更复杂。它处理的是持续不断的数据流，还可能维护着用户会话、累计金额等状态信息。Flink用的是分布式快照机制，通过Chandy-Lamport算法，在整个系统中同步生成一致性快照。
比如一个统计用户点击次数的任务，每收到一条事件就加1。快照会把当前所有算子的状态统一保存下来。即使集群部分节点故障，重启后也能从快照恢复，继续累加，不会丢也不会重复。
env.enableCheckpointing(5000); // 每5秒触发一次检查点
stateBackend = new FsStateBackend("hdfs://namenode:8020/checkpoints");
environment.setStateBackend(stateBackend);任务重启策略也很关键
除了数据层面的恢复，框架还会配合调度器做任务级重试。比如YARN或Kubernetes发现某个处理进程退出，会自动拉起新的实例。Spark可以通过配置参数设置最大重试次数：
--conf spark.task.maxFailures=4意思是单个任务最多允许失败4次，超过才标记整个作业失败。这样能应对临时性故障，比如磁盘IO抖动、短暂网络超时等瞬态问题。
数据复制不是万能解
有人可能会想，能不能像传统数据库那样多存几份？理论上可以，但大数据场景下数据量太大，全量复制成本过高。所以主流框架更倾向用计算换存储——宁可重算，也不盲目复制数据。只有关键元数据或检查点才会做多副本存储。
比如Flink的checkpoint写入HDFS时，默认会保留三个副本，确保存储可靠。但中间计算过程中的数据分区，一般只存在于内存或本地磁盘，不额外复制。