1. 课程导入
在证券、期货、外汇与数字资产等金融业务中，行情与交易数据一旦出现缺口、乱序或延迟，轻则导致策略信号失真，重则引发风控误判与资金损失。实时数据回放与补数链路，正是保障数据"可追溯、可重放、可修复"的关键基础设施。本章作为全课程导入，先建立业务背景、核心概念与整体链路框架，为后续30章的工程实现打下认知基础。
一、业务背景：为什么需要回放与补数
金融实时数据链路通常由行情源、采集网关、消息中间件、实时计算引擎、存储与下游消费端组成。生产环境中，以下场景几乎不可避免：
- 网络抖动与断线重连：采集端与行情源之间短暂断开，重连后中间时段的数据缺失。
- 上游推送异常：交易所或数据商偶发漏推、重复推送或时间戳错乱。
- 下游消费滞后：策略服务重启、消费位点回退，需要从历史时点重新消费。
- 合规与审计要求：监管要求交易与行情数据可完整回溯，支持事后核查。
- 策略回测与仿真：需要以真实历史逐笔数据驱动回测，验证策略在真实微观结构下的表现。
这些需求共同指向两个能力：回放（Replay）——按时间顺序重新投递历史数据；补数（Backfill）——识别缺口并从可靠源补齐缺失区间。二者往往协同工作：先补数修复数据完整性，再回放驱动下游重算。
核心判断：回放解决"顺序与重演"，补数解决"完整与一致"。任何一条实时链路，只要具备可回放与可补数能力，就具备了可恢复性。
二、核心概念与整体链路框架
在进入工程细节前，需要统一几个关键概念：
| 概念 | 含义 | 关键属性 |
|---|---|---|
| 事件时间 | 数据在源头产生的时刻 | 用于排序与窗口计算 |
| 处理时间 | 系统实际处理该数据的时刻 | 用于监控延迟 |
| 水位线 | 对"事件时间已到齐"的进度估计 | 决定窗口触发时机 |
| 序列号 | 上游为每条消息分配的单调编号 | 缺口检测的核心依据 |
| 位点 | 消费者在分区中的消费位置 | 回放起点的定位锚 |
| 幂等写入 | 同一数据重复写入不产生副作用 | 补数安全的前提 |
整体链路可以抽象为"采集—缓冲—检测—补数—回放—消费"六段式。下图以数据流与状态标注的方式，展示各环节的职责与关键参数：
从图中可见，缺口检测与补数服务构成"修复闭环"，回放引擎与下游消费构成"重演闭环"。两个闭环共享同一份存储与位点信息，因此位点管理和幂等写入是整个链路的稳定基石。
三、典型场景：从缺口发现到回放完成
以一个期货行情采集链路为例，说明端到端流程：
- 采集网关为每条行情消息附加单调递增序列号，写入 Kafka 对应分区。
- 缺口检测任务按分区扫描序列号，发现
seq=1001与seq=1005之间缺失 1002~1004。 - 补数服务根据缺失区间的事件时间范围，向历史数据源（如交易所历史文件或备份 Topic）发起回补请求。
- 回补数据经校验后写入主存储，并记录补数批次与校验结果。
- 回放引擎按事件时间顺序，从指定位点重新投递数据到下游策略服务。
- 下游以幂等方式消费，完成指标重算与状态修复。
# 缺口检测伪代码
for partition in partitions:
last_seq = load_checkpoint(partition)
for msg in consume(partition):
if msg.seq != last_seq + 1:
gap = (last_seq + 1, msg.seq - 1)
emit_backfill_task(partition, gap, msg.event_time)
last_seq = msg.seq
save_checkpoint(partition, last_seq)
实践提示：缺口检测应同时关注序列号连续性与事件时间单调性。仅看序列号可能漏掉"序号连续但时间戳跳变"的隐性缺口。
四、常见误区与复盘要点
- 误区一：把补数当成简单重传。补数必须处理重复、乱序与幂等，否则会污染下游状态。
- 误区二：回放时忽略水位线。若回放不推进水位线，窗口计算可能永远不触发或提前触发。
- 误区三：位点与业务状态不同步。位点提交与状态写入若不在同一事务语义下，重启后会出现重复或丢失。
- 误区四：缺少补数审计。没有批次记录与校验日志，事后无法判断某段数据是否可信。
复盘结论：回放与补数的难点不在"搬运数据"，而在"保证顺序、完整与幂等三者同时成立"。任何一环缺失，链路都不可信。
五、学习目标
完成本课程后，你应当能够：
- 描述金融实时数据回放与补数链路的整体架构与关键组件职责。
- 设计基于序列号与水位线的缺口检测方案，并处理乱序与重复。
- 实现幂等补数写入与可审计的补数批次管理。
- 构建按事件时间排序的回放引擎，并正确管理位点与状态。
- 针对断线重连、上游漏推、下游重启等场景给出可落地的修复策略。