增量更新逻辑：订单簿的“实时手术”
各位同学，今天我们来聊聊订单簿增量更新的核心逻辑。说白了，就是当市场上有新订单进来、有人撤单、或者成交了，我们的订单簿该怎么“动刀子”。
我个人习惯把订单簿比作一个活着的数据库。它不是在静态地等你查询，而是每时每刻都在被修改。你想想看，如果每次有变化都重建整个订单簿，那性能肯定扛不住。所以，增量更新才是王道。
四种核心操作：增、删、改、撮
订单簿的增量更新，本质上就四种操作。我在项目中遇到过不少新手，把这四种搞混，结果订单簿数据对不上，那叫一个头疼。
| 操作类型 | 触发场景 | 对订单簿的影响 |
|---|---|---|
| 新增订单 | 交易员提交限价单或市价单 | 在对应价格队列中插入新节点 |
| 撤销订单 | 交易员主动取消未成交订单 | 从价格队列中移除指定订单 |
| 成交撮合 | 买卖双方价格匹配，部分或全部成交 | 减少或移除队列中的订单数量 |
| 修改订单 | 交易员更改价格或数量 | 先撤销旧订单，再新增新订单 |
1. 新增订单：插入的艺术
新增订单是最常见的操作。当一个限价买单进来，比如买100股，价格10.01元，系统要做什么？
首先，找到10.01元这个价格档位。如果这个价格档位还不存在，就新建一个。然后，把订单插入到该价格队列的尾部。为什么是尾部？因为价格优先、时间优先原则。同一价格，先来的先成交。
嗯，这里要注意一个细节：价格档位的排序。买盘是从高到低排列，卖盘是从低到高排列。我建议你在内存里维护一个有序的Map，比如TreeMap，key是价格，value是订单队列。这样插入和查找都是O(log n)的复杂度。
2. 撤销订单：精准定位与删除
撤销订单，说白了就是“反悔”。交易员说我不买了，把单子撤回来。
这时候，系统需要根据订单ID，找到它所在的价格队列，然后从队列中移除这个订单。我曾经在项目中遇到过一个坑：订单ID是全局唯一的，但如果你用链表实现队列，删除一个节点需要遍历整个队列，性能很差。
我的解决方案是：使用双向链表 + 哈希表。哈希表存储订单ID到链表节点的映射，这样删除操作就是O(1)的。你想想看，如果每秒有几千笔撤单，O(n)的遍历会直接拖垮系统。
3. 成交撮合：最复杂的逻辑
成交撮合，是订单簿更新的核心。当一个新的市价单或限价单进来，系统会尝试与对手盘匹配。
举个例子：卖盘最优价格是10.00元，有200股。现在进来一个市价买单，要买300股。系统会怎么做？
- 从卖盘最优价格（10.00元）开始，吃掉200股。
- 这个价格档位的订单全部成交，队列清空。
- 继续看下一个卖盘价格，比如10.01元，有100股。
- 再吃掉100股，满足300股的需求。
- 如果10.01元的队列还有剩余，就保留。
你看，成交撮合本质上是一个循环匹配的过程。每次匹配，都会从对手盘的价格队列中移除订单（部分或全部）。
4. 修改订单：先撤后增
修改订单，其实是一个组合操作。交易员说，我把价格从10.00改成10.01，或者把数量从100改成200。
我个人习惯的处理方式是：先撤销旧订单，再新增一个新订单。为什么？因为修改价格会改变订单在价格队列中的位置，直接修改会导致排序错乱。
举个例子：一个买单在10.00元队列里，现在改成10.01元。如果直接改价格，它应该被移到10.01元的队列。但10.01元可能已经有其他订单了，时间顺序怎么保证？所以，先撤后增是最稳妥的。
不过，如果只是修改数量（不改变价格），可以原地修改。但要注意：减少数量没问题，增加数量需要重新检查是否立即成交。比如，一个买单从100股改成200股，多出来的100股可能直接与卖盘匹配。
核心流程图：增量更新的完整链路
下面我用一张SVG图，把整个增量更新的流程串起来。你一看就明白了。
性能优化：增量更新的关键
增量更新虽然比全量重建快，但如果不注意性能，照样会出问题。我总结了几条经验：
- 数据结构选择：价格档位用TreeMap或SkipList，订单队列用双向链表+哈希表。别用ArrayList，删除操作太慢。
- 批量处理：如果同时有多个事件，可以攒一批再处理。比如每1毫秒处理一次，减少锁竞争。
- 内存管理：订单对象不要频繁创建和销毁。我用对象池来复用，GC压力小很多。
- 无锁设计：如果追求极致性能，可以用CAS（Compare-And-Swap）实现无锁队列。不过，这个难度比较大，我建议你先用锁，等性能瓶颈了再优化。
好了，这一章的内容就到这里。增量更新逻辑，说白了就是这些。你只要把数据结构选对，把并发处理好，订单簿就能跑得又快又稳。