芝商所 MDP 3.0（行情数据平台）

协议承载什么

• 增量刷新消息：按价位（MBP）和按委托（MBO）的订单簿变化、成交摘要，以及时段高低、结算和未平仓量这类统计量。
• 合约定义：每只合约的身份和参数，包括最小跳动和撮合算法。
• 合约状态：开盘、盘前、暂停或预留，比如在速度逻辑触发的暂停期间。
• 行情恢复：周期性的快照，消费方可以据此在丢数据之后重建订单簿。

它怎么被交付

消息用 Simple Binary Encoding 编码，这是一种为快速解码而设计的定长布局二进制格式，然后被打进编号的数据包，经由 UDP 组播发送。

每条通道会被发布两遍，一份走 A 源、一份走 B 源，这样消费方可以用其中一份去补另一份丢掉的包。数据包的序列号让消费方能检测到任何缺口；如果两份源都丢了同一个包，那就只能从快照或者回放里恢复。这套设计说明了一件事：丢包是被当成常态来处理的，而不是异常。

算例

一张 25 手的主动买单，吃到 5,000.25 上来自两张挂单的 15 手，和 5,000.50 上来自一张挂单的 10 手。交易所把这件事发布为一个成交摘要事件，里面有两个价位条目——5,000.25 上 15 手、5,000.50 上 10 手——各自带着挂单笔数，并标明主动方是买方，同时还有把这些流动性移走的订单簿更新。

一个平台最终为这件事显示几笔成交，取决于数据商怎么把这个事件变成成交记录：可能是 2 笔（按价位）、3 笔（按被动订单）或者 1 笔（按主动订单聚合）。同一个市场事件，三种计数都不算错，但它们会让「大单」的统计给出不同的结果。

为什么交易者该知道这个名字

许多决定足迹图能显示什么的性质，都从这里开始：主动方一侧是不是显式给出的、一张主动订单怎么被拆成几笔成交、隐含价格怎么发布、暂停怎么被告知。数据商可以把这些逐项保留、聚合或者丢掉。

所以当两个平台在同一只合约上显示不同的足迹图时，有意义的问题不是「谁对」，而是「这条数据链在哪一步做了取舍」。知道协议的名字，是能把这个问题问清楚的前提。

在 Senzoukria 里

软件从来不自己连 MDP 3.0。它的芝商所数据经由 Rithmic 的 R | Protocol 或者 Databento 到达，而 Databento 的芝商所数据集就以这个协议命名为 GLBX.MDP3；Databento 模块要求在这个数据集上有实时许可，足迹图和热力图的数据源开关才会放开。每一个数据源保留了交易所数据源的哪些细节，是那个数据源自己的性质，不是软件的性质。

常见错误

• 以为每一个芝商所数据产品都交付交易所的全部细节。
• 在两家对成交摘要做了不同聚合的数据商之间比较成交笔数。
• 把数据源的丢包恢复当成软件的 bug——协议本身就假设会丢包。