3. 快照与增量更新时序错乱引发重建偏差

在高频订单簿重建中，快照（Snapshot）负责提供某一时刻的"基准底稿"，增量（Delta/Update）负责在此之后逐笔叠加变化。二者一旦在时序上错位——例如快照版本号与增量序列号没有严格对齐，或增量在快照应用之前就被消费——重建出的订单簿就会出现价格档位缺失、数量漂移、买卖盘交叉等偏差。这类问题往往不会立刻报错，而是以"盘口看起来差不多但成交判断总差一点"的形式潜伏，排查成本极高。本节聚焦版本号与序列号的对齐规则，并给出可落地的时序校验与回滚重放策略。

一、错乱是怎么发生的：三类典型时序缺陷

先明确参照约定：本文中"版本号"指快照携带的、标识其覆盖到的最后一条增量序号（记为 snapshot_seq）；"序列号"指增量消息自带的单调递增序号（记为 update_seq）。对齐规则要求：快照应用后，只接受 update_seq == snapshot_seq + 1 的增量，并连续递增消费。任何偏离都意味着时序错乱。

第一类是快照滞后于增量：重建线程先收到并缓存了若干增量，随后才拿到快照，但快照的 snapshot_seq 小于已缓存的增量起点，导致中间一段增量被"跳过"或重复应用。第二类是快照超前于增量：快照的 snapshot_seq 大于当前增量流的最大序号，说明快照来自更新的通道，后续增量无法衔接，必须等待或重新拉取。第三类是乱序与重复：网络多路复用或重连导致增量乱序到达、重复投递，若消费端只做"追加"而不校验序号连续性，就会把旧增量叠加到新状态上。

二、对齐规则的形式化表达

设快照版本号为 S，增量序列号集合为 {u₁, u₂, …}。正确的重建状态机应满足：应用快照后，期望的下一个序号 expected = S + 1；对每条到达的增量 u：若 u == expected，应用并令 expected += 1；若 u < expected，判定为重复或过期，丢弃；若 u > expected，判定为缺口，进入等待或回滚流程。这个"期望序号"就是整个校验机制的核心游标。

下面是一段可直接参考的校验逻辑（示例参数，非实测）：

class OrderBookRebuilder:
    def __init__(self):
        self.expected_seq = None   # 快照应用后置为 snapshot_seq + 1
        self.book = {}
        self.pending = {}          # 缺口期间暂存的增量

    def apply_snapshot(self, snapshot):
        self.book = snapshot.levels
        self.expected_seq = snapshot.seq + 1
        self.pending.clear()

    def on_update(self, upd):
        if self.expected_seq is None:
            return "WAIT_SNAPSHOT"          # 快照未到，先缓存
        if upd.seq < self.expected_seq:
            return "DROP_DUPLICATE"         # 重复/过期，丢弃
        if upd.seq == self.expected_seq:
            self._apply(upd)
            self.expected_seq += 1
            self._drain_pending()           # 尝试消费暂存缺口
            return "APPLIED"
        # upd.seq > expected_seq：出现缺口
        self.pending[upd.seq] = upd
        return "GAP_DETECTED"

其中 _drain_pending 在每次成功应用后检查 pending 中是否存在 expected_seq，若存在则连续消费，从而在短暂乱序后自动追平。这段逻辑把"对齐规则"变成了可执行的游标推进，是后续校验与回滚的基础。

三、时序校验：三道防线

第一道：锚点校验。快照到达时，检查 snapshot_seq 是否落在当前增量流已观测到的序号区间内。若 snapshot_seq > max_observed_seq，说明快照超前，应等待增量追平或主动重新订阅；若 snapshot_seq < min_buffered_seq - 1，说明快照过旧，缓冲的增量已无法衔接，必须重新拉取快照。

第二道：连续性校验。消费过程中持续比对 update_seq 与 expected_seq，一旦出现 u > expected 即记录缺口区间 [expected, u-1]，并启动一个短时等待窗口（例如 200ms，示例值）。窗口内若缺口被补齐则继续；超时则判定为真实丢包。

第三道：状态一致性校验。周期性对重建结果做轻量自检：买一价是否小于卖一价（无交叉）、各档数量是否非负、总档位数是否在合理范围。这类校验不依赖序号，能兜住序号正确但应用逻辑出错的情况。

四、回滚重放策略：从"卡住"到"自愈"

当缺口在等待窗口内无法补齐时，有两种处理路径，选择取决于快照获取成本与偏差容忍度。

路径 A：回滚重放。保留最近一次成功应用的快照副本（或定期做状态检查点），将订单簿回滚到 snapshot_seq 对应的状态，然后从 snapshot_seq + 1 开始，用本地已缓存的增量序列重新连续应用。这条路径的前提是增量缓存足够完整。实现上，检查点不必每笔都存，可按固定间隔（例如每 1000 条增量，示例值）做一次深拷贝，回滚时取最近的检查点即可，兼顾内存与恢复速度。

路径 B：重拉快照。若增量缓存已不完整（例如重连后历史增量不可得），回滚重放无从谈起，只能重新订阅快照，并以新快照的 snapshot_seq 重置游标。这条路径简单可靠，但会引入一次快照传输延迟，对延迟敏感的做市策略需要评估这段"盲区"的影响。

工程上通常组合使用：先尝试短窗口等待，超时后优先回滚重放（成本低、无网络依赖），回滚也失败（缓存缺失）才降级为重拉快照。整个决策链应记录日志，包含缺口区间、等待时长、所选路径与恢复耗时，便于后续复盘定位是网络抖动还是上游序号生成异常。

五、一个可复用的校验清单

把上述规则固化为上线前的检查项，能显著降低时序类故障的复发率：

• 快照是否携带 snapshot_seq，且该字段与增量序列号同源、同单调性；
• 重建状态机是否以 expected_seq 游标驱动，而非"来一条应用一条"；
• 是否区分了"重复丢弃"与"缺口等待"两种分支，避免把乱序当丢包；
• 等待窗口是否有明确超时值，超时后是否有回滚或重拉兜底；
• 是否保留可回滚的检查点，检查点间隔与内存占用是否经过评估；
• 是否周期性做盘口一致性自检（无交叉、数量非负），作为序号校验之外的补充；
• 缺口、回滚、重拉事件是否全部落日志，字段包含序号区间与恢复耗时。

需要强调的是，时序校验的价值不在于"发现错乱"，而在于"错乱发生后系统能确定性地恢复到一致状态"。游标、等待窗口、检查点三者配合，才能让重建过程从脆弱的线性假设，变成可观测、可自愈的稳健流程。