注:本文是普及金融市场交易的基础知识,不是为了鼓励大家去炒股炒币。相反,通过学习证券知识,理解衍生品原理,可以更好地认识市场风险,自觉放弃杠杆赌博暴富等不切实际的幻想,避免落入各种理财、带单、空气币等诈骗套路。本文一切内容均不构成任何投资意见或建议。
在证券交易系统中,撮合引擎是实现买卖盘成交的关键组件。本文我们将分析撮合引擎的工作原理,并以最简化的Java代码设计并实现一个撮合引擎。
在证券市场中,撮合交易是一种微观价格发现模型,它允许买卖双方各自提交买卖订单并报价,按价格优先,时间优先的顺序,凡买单价格大于等于卖单价格时,双方即达成价格协商并成交。在A股身经百战的老股民对此规则应该非常熟悉,这里不再详述。
我们将讨论如何从技术上来实现它。对于撮合引擎来说,它必须维护两个买卖盘列表,一个买盘,一个卖盘,买盘按价格从高到低排序,确保报价最高的订单排在最前面;卖盘则相反,按照价格从低到高排序,确保报价最低的卖单排在最前面。
下图是一个实际的买卖盘:
对于买盘来说,上图的订单排序为2086.50,2086.09,2086.06,20860,2085.97,……
对于卖盘来说,上图的订单排序为2086.55,2086.75,2086.77,2086.90,2086.99,……
不可能出现买1价格大于等于卖1价格的情况,因为这意味着应该成交的买卖订单没有成交却在订单簿上等待成交。
对于多个价格相同的订单,例如2086.55,很可能张三卖出1,李四卖出3,累计数量是4。当一个新的买单价格≥2086.55时,到底优先和张三的卖单成交还是优先和李四的卖单成交呢?这要看张三和李四的订单时间谁更靠前。
有了以上规则,我们先设计一个最简单的订单类Order
:
1 | public class Order { |
虽然订单的成交规则遵循价格优先、时间优先的原则,但我们并不会比较两个订单的下单时间,而是给接收到的所有订单依次赋予一个递增的序列号,序列号越小的自然时间越早,因此排在前面。时间本身实际上是订单的一个普通属性,不参与业务排序。
订单方向用枚举Direction
实现,它仅有BUY
和SELL
两个值:
1 | public enum Direction { |
价格和数量以BigDecimal
表示。不用float
或double
的原因在于计算机无法进行精确的浮点数运算,而金融交易的价格、数量是不允许有误差的,因此,必须用BigDecimal
作为定点数运算。
下一步是实现订单簿OrderBook
的表示。一个直观的想法是使用List<Order>
,并对订单进行排序。但是,在证券交易中,使用List
会导致两个致命问题:
- 插入新的订单时,必须从头扫描
List<Order>
,以便在合适的地方插入Order
,平均耗时O(N); - 取消订单时,也必须从头扫描
List<Order>
,平均耗时O(N)。
更好的方法是使用红黑树,它是一种自平衡的二叉排序树,插入和删除的效率都是O(logN),对应的Java类是TreeMap
。
所以我们定义OrderBook
的结构就是一个TreeMap<OrderKey, Order>
,它的排序根据OrderKey
决定。由业务规则可知,负责排序的OrderKey
只需要sequenceId
和price
即可:
1 | public class OrderKey { |
因此,OrderBook
的核心数据结构就可以表示如下:
1 | public class OrderBook { |
有的童鞋注意到TreeMap
的排序要求实现Comparable
接口或者提供一个Comparator
。我们之所以没有在OrderKey
上实现Comparable
接口是因为买卖盘排序的价格规则不同,因此,编写两个Comparator
分别用于排序买盘和卖盘:
1 | private static final Comparator<OrderKey> SORT_SELL = new Comparator<>() { |
这样,OrderBook
的TreeMap
排序就由Direction
指定:
1 | public OrderBook(Direction direction) { |
这里友情提示Java的BigDecimal
比较大小的大坑:比较两个BigDecimal
是否值相等,一定要用compareTo()
,不要用equals()
,因为1.2
和1.20
因为scale
不同导致equals()
返回false
。
在Java中比较两个BigDecimal的值只能使用compareTo(),不能使用equals()!
再给OrderBook
添加插入、删除和查找首元素方法:
1 | public Order getFirst() { |
现在,有了买卖盘,我们就可以编写撮合引擎了。定义MatchEngine
核心数据结构如下:
1 | public class MatchEngine { |
一个完整的撮合引擎包含一个买盘、一个卖盘和一个最新成交价(初始值为0)。撮合引擎的输入是一个Order
实例,每处理一个Order
,就输出撮合结果MatchResult
,核心处理方法定义如下:
1 | public MatchResult processOrder(Order order) { |
下面我们讨论如何处理一个具体的Order
。对于撮合交易来说,如果新订单是一个买单,则首先尝试在卖盘中匹配价格合适的卖单,如果匹配成功则成交。一个大的买单可能会匹配多个较小的卖单。当买单被完全匹配后,说明此买单已完全成交,处理结束,否则,如果存在未成交的买单,则将其放入买盘。处理卖单的逻辑是类似的。
我们把已经挂在买卖盘的订单称为挂单(Maker),当前正在处理的订单称为吃单(Taker),一个Taker订单如果未完全成交则转为Maker挂在买卖盘,因此,处理当前Taker订单的逻辑如下:
1 | public MatchResult processOrder(Order order) { |
根据价格匹配,直到成交双方有一方完全成交或成交条件不满足时结束处理,我们直接给出processOrder()
的业务逻辑代码:
1 | MatchResult processOrder(Order takerOrder, OrderBook makerBook, OrderBook anotherBook) { |
可见,撮合匹配的业务逻辑是相对简单的。撮合结果记录在MatchResult
中,它可以用一个Taker订单和一系列撮合匹配记录表示:
1 | public class MatchResult { |
撮合记录则由成交双方、成交价格与数量表示:
1 | public class MatchRecord { |
撮合引擎返回的MatchResult
包含了本次处理的完整结果,下一步需要把MatchResult
发送给清算系统,对交易双方进行清算即完成了整个交易的处理。
我们可以编写一个简单的测试来验证撮合引擎工作是否正常。假设如下的订单依次输入到撮合引擎:
1 |
|
经过撮合后最终买卖盘及市场价如下:
1 | 2088.02 3 |
如果我们仔细观察整个系统的输入和输出,输入实际上是一系列按时间排序后的订单(实际排序按sequenceId),输出是一系列MatchResult
,内部状态的变化就是买卖盘以及市场价的变化。如果两个初始状态相同的MatchEngine
,输入的订单序列是完全相同的,则我们得到的MatchResult
输出序列以及最终的内部状态也是完全相同的,因此,可以轻易地使用两个独立的MatchEngine
作为集群,将同一组订单序列分别输入给不同的MatchEngine
,取任意一个MatchEngine
的输出结果都是正确的。
小结
本文讨论并实现了一个可工作的撮合引擎核心。实现撮合引擎的关键在于将业务模型转换为高效的数据结构。只要保证核心数据结构的简单和高效,撮合引擎的业务逻辑编写是非常容易的。