如何使用Binance的depth_snap与depth_update构建BTCUSDT本地orderbook

问题1：如何结合depth_snap和depth_update构建正确订单簿 #

两类数据ID无重叠的问题，基本是因为没有按Binance官方的ID匹配逻辑操作，而非数据本身问题，按以下步骤处理即可：

• 先做基础数据预处理：将所有depth_update记录按时间戳正序排序，确认每条增量记录的pu（前一批增量的最终ID）等于上一条增量的u（当前批增量的最终ID），保证增量本身的连续性
• 取任意一份depth_snap的lastUpdateId记为S，不需要找和S完全相等的增量ID，而是从排序后的增量中定位第一条满足U ≤ S + 1 且 u ≥ S + 1的增量记录，这就是需要应用到快照上的第一条增量
• 从定位到的第一条增量开始，逐批将增量的挂单数据更新到快照订单簿中：对应价格档位的数量为0时直接删除该档位，数量不为0时直接覆盖该档位的现有数量
• 如果遇到增量整体ID区间和快照ID完全跨段的情况，可取相邻的两份快照S1、S2，对应ID分别为S1_id、S2_id，筛选出所有U ≥ S1_id + 1且u ≤ S2_id的增量应用到S1，最终和S2的订单簿做一致性校验即可

问题2：是否可以仅用连续的depth_snap构建订单簿 #

可以，但有明确的适用前提：

• 已校验所有快照的lastOrderId和pu连贯，即后一份快照的pu严格等于前一份快照的lastUpdateId，说明快照之间没有订单更新的断档，此时每份快照对应时间点的订单簿状态都是精准的
• 仅当业务场景能接受相邻快照40分钟的时间精度时，才适合只用快照构建：这种方式只能拿到每40分钟一个时间点的订单簿状态，无法还原两个快照之间的订单簿变化过程，如果需求需要秒级甚至毫秒级的订单簿序列，还是必须结合增量数据实现

内容的提问来源于stack exchange，提问作者KyuSang Jang