订单簿采用两个红黑树（std::map）分别维护买盘（价格降序）和卖盘（价格升序），每档价格对应一个fifo队列（如std::deque），以支持价格优先、时间优先的高效撮合与高频增删。
撮合引擎核心结构用什么数据结构
订单簿（Order Book）不是简单用 std::map 或 std::unordered_map 存一下价格和数量就行。真实场景下，你得同时支持：按价格优先、时间优先的匹配；高频插入/删除；快速取最高买价/最低卖价。所以主流实现都用两个红黑树（std::map）分别存买盘和卖盘，键是价格（升序卖盘、降序买盘），值是该价格下的订单队列（std::deque 或自定义链表）。
容易踩的坑：
- 用
std::unordered_map存价格档位 → 无法 O(log n) 找到最优价格，每次撮合要遍历哈希桶或额外维护最大/最小堆，反而更慢 - 把所有订单塞进一个
std::multiset按价格+时间排序 → 插入 O(log n)，但同价位订单无法批量处理，且删除单个订单时需遍历定位，实际性能差 - 忽略价格精度问题：交易所价格常为固定小数位（如 BTC/USDT 精度 2 位），直接用
double当 key 会导致std::map键比较出错，必须转成整型（如乘以 100 后用int64_t）
限价单撮合逻辑怎么写才不漏单
撮合不是“拿新订单扫一遍对手盘”，而是严格按价格优先、时间优先逐档消耗。比如新来一笔买单价 100 的限价单，卖盘有 [98@10, 99@5, 100@3, 101@20]，只应匹配 98 和 99 档（因它们价格 ≤ 100），100 档虽价格相等但属于“可成交但非最优”，是否匹配取决于业务规则（多数交易所允许匹配等于委托价的挂单）。
实操建议：
- 卖盘用
std::map<float std::deque>></float>时，必须用lower_bound找第一个 ≥ 新买单价格的档位，然后反向遍历（从低价到高价）直到价格 > 委托价 —— 别正向遍历，否则顺序错 - 每档匹配完要检查剩余量：若当前档订单全部成交，用
erase删除该档；若部分成交，只 pop_front 当前订单，保留队列继续处理下一档 - 记得在匹配循环中实时检查新订单是否已完全成交，一旦
order->remaining_qty == 0就 break，避免无谓遍历
如何避免多线程下单时的数据竞争
订单到达、撮合执行、成交回报这三步不能串行化成一把大锁，否则吞吐直接归零。典型做法是：每个价格档位（price level）配一个细粒度锁，或者用无锁队列 + 单线程撮合器（event loop 模式）。
更稳妥的路径是「读写分离 + 单写线程」：
- 所有订单入口（新增/撤单）写入一个无锁环形缓冲区（如
boost::lockfree::spsc_queue），由单独的撮合线程消费 - 订单簿数据结构本身不暴露给外部，只提供
add_order()、cancel_order()等线程安全接口，内部由撮合线程串行调用 - 查询接口（如获取盘口深度）走只读快照：撮合线程每轮撮合完成后生成一份轻量级快照（仅价格档位头指针+数量），供行情服务异步读取
别碰 std::shared_mutex 做读多写少优化——在微秒级延迟要求下，共享锁的 acquire 开销和 cache line bouncing 反而比单线程 event loop 更不可控。
为什么回测时结果和实盘对不上
最常被忽略的是时间语义：回测用的是“消息时间戳”，实盘看的是“系统处理时间”。比如两笔订单时间戳相同，回测可能按文件顺序处理，而实盘中它们进入撮合队列的顺序取决于网络延迟、内核调度、锁争用——这直接决定谁先成交。
调试要点：
- 实盘必须记录每笔订单的
recv_time（网卡收包时间）、queue_time（入撮合队列时间）、match_time（开始匹配时间），三者差值超过 100μs 就要查路径瓶颈 - 回测引擎里禁止用
std::chrono::system_clock模拟时间推进，改用离散事件驱动（event-driven），每个事件带显式 timestamp，并按 timestamp 排序后处理 - 测试用例要覆盖“临界价格档位并发”场景：比如买一和卖一价格刚好相等时，同时来一笔买单和卖单，二者是否能互相撮合？很多实现漏掉这个判断，只做“新单 vs 对手盘”，忘了新单之间也可能立即成交
真正难的从来不是写出能跑的撮合逻辑，而是让每一笔订单的生命周期（从抵达、排队、匹配、到生成成交记录）全程可观测、可复现、可对齐硬件时间戳。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
