C++撮合引擎中怎么组织限价订单薄（Order Book）内存结构-C++-PHP中文网

必须用 std::map（或 std::multimap），因其天然有序，支持o(log n)最优价格查找、区间扫描和稳定遍历；哈希表无序且浮点键哈希不稳定，不满足撮合引擎“价格优先、时间优先”核心需求。

c++撮合引擎中怎么组织限价订单薄（order book）内存结构

限价订单薄用 `std::map` 还是 `std::unordered_map`？

必须用 std::map（或 std::multimap），不能用哈希表。撮合引擎的核心操作是「按价格优先、时间优先」匹配，而价格是天然有序的——买盘从高到低、卖盘从低到高。每次新订单进来都要找最优对手价（begin() 或 rbegin()），撤单/部分成交后还要快速定位相邻价格档。哈希表不支持有序遍历，也无法 O(log n) 找到最接近某个价格的档位。

常见错误是图快用 unordered_map<double orderlist></double>，结果发现：std::equal_range 失效、无法做价格区间扫描（比如市价单扫到某价位止）、回测重放时因浮点键哈希不稳定导致行为不一致。

价格键必须用整型（如以最小变动单位为单位的 int64_t），避免 double 作为 map 键带来的精度和比较问题
同一价格可能有多个订单，所以用 std::map<pricelevel std::deque>></pricelevel> 或自定义链表更稳妥，别依赖 multimap 的插入顺序保证（C++ 标准不保证同键元素的插入序）
如果追求极致性能且价格档稀疏（如加密货币 tick 很小），可考虑跳表（skiplist）替代 map，但绝大多数场景 map 足够且更易维护

订单节点该存指针还是对象？内存怎么配对释放？

订单节点必须存裸指针（Order*）或智能指针（std::unique_ptr<order></order>），不能把 Order 对象直接塞进 deque 或 list。原因很实际：订单生命周期独立于订单薄——它可能被撤单、跨多个簿（如跨合约套利）、或需记录完整生命周期日志。一旦对象被拷贝进容器，地址就失控，后续撤单时无法精准定位和移除。

典型坑是：用 std::deque<order></order> 存对象，然后在撤单函数里传入 order_id 去遍历查找——这变成 O(n) 搜索，实盘中几十万订单下直接卡死。

订单创建时统一由内存池（boost::pool 或自研 slab allocator）分配，避免频繁 new/delete；订单薄只持指针，不负责析构
撤单必须靠 order_id → Order* 的反向哈希索引（std::unordered_map<orderid order></orderid>），查表 O(1) 定位，再根据 Order::price_level 找到对应价格档的容器，用迭代器 erase()
禁止在订单薄结构里保存冗余字段（如重复存 price），所有关键字段都从 Order* 实例读取，保持单一信源

买卖盘分离还是共用一个结构？如何避免锁竞争？

买卖盘必须物理分离：两个独立的 std::map（bid_book 和 ask_book）。共用一个结构看似省事，但会强制所有操作加全局锁——下单、撤单、撮合全串行，吞吐直接归零。实盘中买卖盘更新频率差异大（如高频做市商主要挂 ask，套利者猛扫 bid），分离后可用细粒度锁甚至无锁设计。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

常见误操作是用一个 std::map<:pair price>, OrderList></:pair>，结果 Side 枚举值混在键里，导致无法单独遍历 bid 或 ask，也丧失了 bid_book.rbegin() 这种天然最优买价访问能力。

每个盘（bid_book/ask_book）配独立读写锁（std::shared_mutex），撮合线程只读，下单/撤单线程写；若用 C++17 及以上，优先考虑 std::shared_mutex 而非 pthread_rwlock
绝不允许跨盘操作时同时锁两个结构（如“先锁 bid 再锁 ask”），必须约定固定顺序（如总是先锁 bid_book 再锁 ask_book）防死锁
如果追求零锁（如 LMAX Disruptor 风格），订单薄本身只做无锁 ring buffer 的消费者，所有变更走事件队列，但复杂度陡增，中小系统不推荐

订单薄要不要持久化或快照？内存结构如何适配？

订单薄本身不存快照，快照是外部组件按需拉取的视图。内存结构必须支持高效只读遍历（const_iterator）和原子性快照——即在任意时刻能 O(1) 获取当前全部价格档列表，且不阻塞写操作。这意味着不能用带写时复制（copy-on-write）的结构（如某些封装过的 map），也不能在遍历时锁整个簿。

很多团队过早引入快照序列化逻辑，结果发现：序列化耗时占撮合周期 20%+，或快照过程中订单状态已变更，导致风控模块看到脏数据。

快照应由专用线程定时触发，调用 bid_book 和 ask_book 的 cbegin()/cend() 遍历，逐档拷贝价格和总数量（不是每个订单），生成轻量结构（如 vector<snapshotlevel></snapshotlevel>）
订单薄内部不存任何与快照相关的字段（如版本号、快照标记位），这些由快照服务自己管理
如果需要磁盘回放（如灾备），订单流本身应走 WAL（write-ahead log），而不是定期 dump 订单薄内存——因为簿是派生状态，log 才是事实来源

真正难的从来不是怎么存，而是怎么让“价格有序性”、“多线程安全”、“低延迟遍历”三者不互相拖累。多数崩塌发生在把订单薄当成通用容器来用，忘了它本质是个实时决策索引——一切设计，得先问一句：这个改动会让最优对手价的查找变慢吗？