4. 增量更新与全量重建：增量快照的生成策略、全量重建的触发条件、快照与增量的合并逻辑

好，咱们接着聊订单簿重建。前面几章我们把延迟的源头、数据流、还有序列化的问题都捋了一遍。现在要进入一个核心环节——增量更新与全量重建。

说实话，这个主题我当年踩过不少坑。刚做高频交易系统那会儿，我天真地以为只要把每一笔订单的变动发出去就行了。结果呢？网络丢包一次，整个订单簿就废了。后来我才明白，增量 + 快照的组合拳才是王道。

4.1 增量快照的生成策略

先说说增量快照。增量快照，说白了就是「从上次快照到现在，订单簿发生了什么变化」。它不包含完整的订单簿状态，只包含增、删、改的操作。

我个人习惯把增量快照分成三种类型：

• 增量更新（Incremental Update）：只包含新增、修改、删除的订单条目
• 增量快照（Incremental Snapshot）：包含某个时间窗口内的所有变化
• 差异快照（Diff Snapshot）：与上一个快照的差异集合

你可能会问：「这三种有啥区别？」嗯，区别大了去了。我举个例子：

我在项目中遇到过一种情况：某个交易所的行情推送频率极高，每秒上万笔变动。如果用增量更新，客户端根本来不及处理。后来我们改成了定时增量快照，每50ms生成一次，效果立竿见影。

生成策略上，我建议遵循几个原则：

1. 按时间窗口打包：固定时间间隔（如50ms、100ms）生成一次增量快照
2. 按变动数量打包：当变动数量达到阈值（如500笔）时立即生成
3. 按优先级打包：大额订单、关键价位的变动优先打包

4.2 全量重建的触发条件

全量重建，就是重新发送一份完整的订单簿快照。什么时候需要触发？我总结了几种情况：

触发条件	说明	优先级
客户端首次连接	新客户端加入，需要获取完整状态	高
增量序列号不连续	检测到丢包或乱序，需要重建	高
定时重建	每隔N秒/分钟强制重建一次	中
异常检测	订单簿数据校验失败	高
手动触发	运维人员手动发起重建	低

我曾经踩过一个坑：定时重建的间隔设得太短（比如1秒一次），结果全量快照和增量更新互相冲突，客户端收到两份数据，订单簿直接乱套了。后来我改成每30秒一次全量快照，并且在全量快照生成期间暂停增量更新，问题才解决。

4.3 快照与增量的合并逻辑

合并逻辑，说白了就是客户端拿到全量快照后，怎么把后续的增量更新应用上去。这个过程看似简单，但细节决定成败。

我画了一张流程图，帮你理清思路：

合并逻辑的核心代码，我习惯这样写：

// 伪代码：快照与增量合并
class OrderBookReconstructor {
    // 全量快照
    Snapshot latestSnapshot;
    // 增量缓存，按序列号排序
    map<uint64_t, IncrementalUpdate> pendingUpdates;
    // 当前序列号
    uint64_t currentSeqNo = 0;
    
    void onSnapshotReceived(Snapshot snap) {
        // 1. 校验快照完整性
        if (!snap.verifyChecksum()) {
            requestResend();  // 请求重发
            return;
        }
        
        // 2. 重建订单簿
        rebuildOrderBook(snap);
        currentSeqNo = snap.seqNo;
        
        // 3. 应用缓存的增量
        applyPendingUpdates();
    }
    
    void onIncrementalUpdate(IncrementalUpdate update) {
        if (update.seqNo <= currentSeqNo) {
            // 已经应用过的增量，直接丢弃
            return;
        }
        
        if (update.seqNo == currentSeqNo + 1) {
            // 连续的增量，直接应用
            applyUpdate(update);
            currentSeqNo = update.seqNo;
            
            // 检查缓存中是否有后续增量
            applyPendingUpdates();
        } else {
            // 非连续，缓存起来
            pendingUpdates[update.seqNo] = update;
            
            // 如果序列号差距过大，触发全量重建
            if (update.seqNo - currentSeqNo > MAX_GAP) {
                requestFullSnapshot();
            }
        }
    }
    
    void applyPendingUpdates() {
        while (pendingUpdates.count(currentSeqNo + 1)) {
            auto update = pendingUpdates[currentSeqNo + 1];
            applyUpdate(update);
            currentSeqNo = update.seqNo;
            pendingUpdates.erase(currentSeqNo);
        }
    }
}

这段代码看起来简单，但有几个细节要注意：

• 序列号连续性检查：增量更新必须按序列号顺序应用，跳号说明丢包了
• 缓存大小限制：缓存不能无限增长，我一般设1000条上限，超过就触发全量重建
• 重复增量处理：同一个序列号的增量可能收到多次，要幂等处理

4.4 实战中的合并策略选择

不同的场景，合并策略也不同。我根据经验总结了几种：

策略	适用场景	优点	缺点
全量优先	低延迟、高可靠性场景	简单、不易出错	带宽消耗大
增量优先	高吞吐、低带宽场景	带宽利用率高	丢包后恢复慢
混合策略	大多数实际场景	平衡带宽和可靠性	实现复杂

我个人推荐混合策略：平时用增量更新，每30秒发一次全量快照作为「保底」。这样即使增量丢了，最多30秒就能恢复。嗯，这个方案我在多个项目中验证过，效果不错。

好了，关于增量更新与全量重建，核心内容就这些。记住一句话：增量保效率，全量保可靠。两者配合好，订单簿重建的延迟问题就能解决大半。