OMS 与 ME 如何协同：两条分片轴

一个生产级交易所会同时用两种方式分片，因为两类不同的状态有两个不同的一致性单元。本页是全局 地图：按用户分片的 OMS 与按 symbol 分片的撮合引擎如何组合成一个系统。随后的两页分别深入 每一条轴；请先读本页。

两层结构

• OMS 拥有按用户的状态——买力、预留、会话、open-orders index——并按用户分片。→ 按用户分片 OMS
• 撮合引擎拥有按 symbol 的订单簿，并按 symbol 分片。→ 用 actor 模式分片

为什么两条轴必须不同

你不能用同一种方式给两层分片——这是整个设计所依赖的核心洞见：

	一致性单元	分片键	为什么不能用另一个键
OMS	一个用户的账户	用户	一个用户交易多个 symbol——无法把它的余额钉在某个 symbol 分片上
撮合引擎	一个订单簿	symbol	一个订单簿天然是多用户的——撮合无法按用户分片

所以系统两者都需要，它们在 ME-bridge 处相遇：每个 OMS cluster 里有一个 leader-only 的 agent，读取订单的 symbol，并把它提交到该 symbol 的 ME cluster（symbol → ME 映射是静态配置）。

一笔订单的端到端流程

微妙之处在于成交横跨两条轴。ME 里的一次撮合（symbol 轴）会为两个用户产生成交——taker 与 maker——而他们通常位于不同的 OMS cluster（用户轴）。每一方的 OMS cluster 各自结算自己的用户。 这正是为什么 ME 必须发出以确定性 orderId 为键的生命周期事件（见 ME 契约）： 每个 OMS cluster 各自领取它所拥有那笔订单的成交。

每一层本身都是 A + B 的混合

两层都组合了actor 模式页 中的两种结构：

• 方案 A —— 多个 cluster（每个有自己的 Raft log + leader + core）→ 扩展吞吐。
• 方案 B —— 单个 cluster 内多个 actor（共享一条 log/一个 core）→ 仅提供逻辑隔离。

层	方案 A（扩展吞吐）	方案 B（逻辑隔离）
OMS	多个 OMS cluster，用 HRW 把用户分散其上	每个 cluster 内多个常驻 user-actor（LRU/TTL 缓存）
ME	每个 symbol 组一个 cluster	一个 cluster 内多个订单簿

所以「为更多用户扩容」= 增加 OMS cluster（A）；「为更多 symbol 扩容」= 增加 ME cluster （A）——彼此独立，互不影响。

两层独立扩展

两层之间唯一的耦合是静态的 symbol → ME 映射（bridge 的路由）与 ME 契约。 除此之外：

• 扩展 OMS cluster（更多用户容量）是 分批的 HRW 迁移——ME 毫无察觉。
• 扩展 ME cluster（更多 symbol 容量）涉及订单簿的放置——OMS 只需更新它的静态映射。

---

深入阅读：

• 按用户分片 OMS：带驱逐的热用户 actor —— 用户轴。
• 用 actor 模式分片 OMS —— symbol 轴。