任务恢复成功，在线结果就正确了吗
算子从 checkpoint 恢复了状态，外部接口可能已经执行过；离线特征按事件时间回填成功，历史请求当时却未必看得到它。恢复、对外生效和时间可见性，需要分别约定。
有状态流计算持续维护窗口、聚合或业务进度。故障之后，系统需要恢复输入位置与算子状态的一致组合；在线系统还要确认输出是否重复，以及结果是否属于调用者要求的那个时间点。
本文用 Flink 2.3.0 的单机本地执行环境、JDK 21.0.12 验证一次受控算子失败恢复。特征时间部分使用完全虚构的数据作确定性示例。没有杀死 TaskManager、重启 JobManager、测试分布式 checkpoint 存储，也没有连接真实推荐或设备系统。
一、checkpoint 把状态与输入进度联系起来
Flink 的有状态流处理可以持续处理记录，以 checkpoint 保存恢复所需的状态。checkpoint 的一致性截面要同时考虑来源进度、算子状态以及适用模式下的在途记录，不能把某个变量的临时副本视为完整恢复点。
图中 checkpoint 之后的记录可能在失败前后各处理一次。恢复的目标是在选定状态语义下得到正确结果；并不要求每条用户代码物理上只执行一次。
Flink 的有状态流处理不等同于将持续输入切成固定微批再执行批作业；具体执行模式、算子和连接器需要分别理解。checkpoint 也不以每次快照替代正常的逐记录处理，更不承诺所有应用都能在固定毫秒内出结果。Flink 状态与 checkpoint 文档说明了状态一致性与配置的关系。
二、恢复后的第一条记录，能看到多少状态
实验通过官方 DataGeneratorSource 以受限速率生成序号 1—200，按一个固定键累加 ValueState<Long>，每 100ms 触发 checkpoint。首次执行在处理序号 120 前抛出受控异常；固定延迟重启策略最多允许两次重启。配置均为演示值，不适合作为生产参数。
核心处理逻辑如下，完整类型、状态初始化和失败路径在配套实验中：
Long stored = count.value();
long previous = stored == null ? 0 : stored;
if (attempt == 0 && value == 120) {
throw new IllegalStateException("controlled operator failure");
}
count.update(previous + 1);
out.collect(previous + 1);一次运行的观测摘录：
flink=2.3.0 java=21.0.12+8-LTS final_count=200
attempt=0 first_input=1 restored_count=0
attempt=1 first_input=117 restored_count=116恢复位置由实际 checkpoint 时机决定，多次运行观测到的恢复值在 115 到 119 之间，所以不断言固定编号，只断言两者的关系：首次状态为 0；重启后第一条记录读到的恢复值大于 0，且正好等于这条记录的序号减 1；最终计数为 200。为了让 checkpoint 能完成，数据源按框架支持的方式限速；在一个紧密处理循环里单纯增加休眠，不一定能形成预期的恢复点。
「恢复值 = 序号 − 1」说明算子状态和数据源的读取位置来自同一个 checkpoint：恢复后的第一条输入正好接在已经计入状态的记录之后，没有重复计数，也没有跳过。这也排除了从零处理后碰巧得到相同最后数字的可能。该实验没有外部持久化输出，收集到的最终计数也不能证明任意 sink 都有恰好一次效果。重启配置的语义见 Task Failure Recovery。
三、恢复计算不等于撤销外部副作用
设想一条记录先调用外部命令接口，再等待新的 checkpoint。接口已生效，作业随后失败；恢复后同一记录再次到达，接口可能再次执行。这是失败时序示意，实验没有实际发送设备命令。
要把内部状态保证延伸到外部结果，需要满足输出端的额外协议，例如与 checkpoint 协调的事务提交，或带稳定业务键的幂等写入。对于外部 HTTP 操作，还要处理响应丢失后如何查询结果。不能只看到配置里有 EXACTLY_ONCE 就宣称业务效果绝不重复。
| 边界 | 要约定的对象 |
|---|---|
| 输入可重放 | 保存哪个位置，保留多久，重放是否得到相同记录 |
| 算子状态 | 哪个恢复点、状态版本、恢复失败怎么办 |
| 外部输出 | 事务或幂等键、重复请求、部分成功和结果查询 |
| 在线读者 | 版本何时可见、能接受多旧、失败时采用什么值 |
消息端的重复和提交顺序可对照 Kafka 的投递语义；接口返回「已接收」与业务真正完成之间的契约，见异步受理。
四、历史上发生过，和当时能看到，是两个时间条件
计算结果对在线服务有用，还需要知道它属于哪个时间截面。下面完全虚构的特征记录，时间单位和时钟域相同：
| 特征值 | 事件时间 | 平台可用时间 |
|---|---|---|
| old | 5 | 8 |
| late | 9 | 12 |
重建时间 10 的历史决策时，只按 event_time <= 10 选择最新记录，会选到 late；加上 available_at <= 10，才得到当时平台已经有的 old。这是一个说明两种时间条件的例子，不是实验结果，也不是推荐效果评测。
生产系统还要定义「平台可用」究竟是接入、计算完成还是对在线存储成功发布；不同系统没有天然共享的一个时间戳。迟到事件、修订、回填和特征定义升级，应带着相应版本处理。否则离线评估使用了当时尚不存在的信息，得到的结果无法代表真实在线决策。
checkpoint 保存处理进度，不替业务定义上述时间。类似地，watermark 用于事件时间推进，也不是记录已经对所有读者可见的承诺。发布模型与特征时，应关联定义版本、数据截点和在线生效版本，约定缺失、过期和回滚行为。
若结果要下发到设备，命令还需有稳定标识、有效期、目标状态、执行确认与失联策略；重复投递是否重做，不能仅由消息到达次数决定。这些是设计要点，本文没有验证设备协议或边缘控制。
下一次做恢复演练，可以同时记录：从哪个输入位置恢复、第一条记录看到的状态、外部结果是否重放，以及在线读者拿到的版本。只记录「作业变绿」会漏掉后三类问题。
配套实验
- codesphere-labs/distributed/checkpoint-state-recovery：Flink 2.3.0、JDK 21.0.12：本地环境中的 checkpoint、受控算子失败、恢复值与数据源位置一致、最终计数 200；不包含独立进程或多机恢复（验证记录）
参考资料