原文首发于 TechNova： 强平单优先撮合：从风控触发到撮合引擎的深度解析
承接页（解决方案）：https://technologynova.org/solution/
(Price, Time) 扩展成三元组 (Price, OrderType, Time)：同一价位内，强平单需要插队（push_front / prepend）。在杠杆交易里，强平（Liquidation）是风险控制的最后防线。普通订单可以慢一点、排队成交；强平单不行。 原文强调的核心动机很直白：延迟会把风险放大成损失。 当行情快速滑点时，强平链路里任何一个环节变慢（网络、锁、队列积压、撮合热路径抖动），都可能让平仓价更差、亏损更深。
因此，强平系统在“公平性”和“生存性”之间通常选择后者：在同价位甚至更优价位存在普通单的情况下，强平单仍可能被撮合引擎优先处理。
传统订单簿可以看作两个优先队列（买/卖），按价格维度选出 best level，再在同价位内按 FIFO 时间优先。 强平优先的落地方式通常不是重写整个撮合算法，而是对价格档位内的队列做规则扩展：
push_back（保持 FIFO）。push_front（插到队首）。
因为需求是“头插 + 尾插”，类似双端队列/链表更合适；如果用向量在头部插入会是 O(N) 搬移，极端行情下容易把撮合线程拖垮。
原文用一个很“操作系统味儿”的视角提醒：风控服务与撮合引擎如果跨主机走 TCP， 要经历用户态↔内核态拷贝、协议栈封装/解封、网卡 DMA、再拷贝回用户态——每一步都在消耗宝贵的时间窗口。
典型优化路径是：把风控计算单元尽量靠近撮合（同机甚至同进程）， 用共享内存/Unix Domain Socket/无锁环形队列等方式把投递延迟压到更低。 代价是更高耦合与更复杂的故障隔离，需要工程上额外投入。
强平至少包含两类状态变更：账户/仓位冻结与清算、以及撮合引擎里的成交执行。 用 2PC 之类强一致分布式事务能做，但往往把链路延迟拉得不可接受。
更常见的工程做法是“先锁后做”： 先把账户置为 Liquidating（冻结、禁止并发操作）→ 再提交强平单 → 成交回报后最终确认。 如果中间失败（撮合不可用/回报丢失），则依赖后台补偿任务对“冻结中”的账户重试/兜底处理。 这是在延迟与一致性之间更务实的折中。
如果你的平台在极端行情下出现“强平延迟高、撮合队列积压、穿仓风险放大”的问题，建议用三步做一次工程化体检： 1) 明确强平单的优先级语义与订单簿数据结构（同价位插队、避免 O(N) 头插）； 2) 把风控→撮合链路做短（同机/IPC/内存队列），并建立强平风暴下的限流与退化策略； 3) 设计账户冻结与补偿机制，确保失败可恢复、状态可追踪。 更系统的交易系统方案可参考： https://technologynova.org/solution/