java交易撮合怎么实现_现代化的 Java （二十）——撮合节点的实现

今天我做了一些整合工作，把撮合、行情、状态、下单、定序整体在测试环境里跑了起来。那么这个项目算不算写完了呢？

我个人觉得并没有。没有测试代码来验证整个工作流程确实生效。

现在行情只做了深度，并且只是记录了日志，这离一个完整的行情服务还有不小的距离，我们还有一些有趣的实践值得尝试

现在每次更新项目，我是纯手工处理，那么对于一个正式的Java项目，有没有一些自动化的措施可用呢？其实也是有的

不过现在这个时间，代码都已经可以假装自己长大成人一般的运行起来。可以花几篇讨论一下撮合和行情的逻辑了。甚至我想对于熟悉 Akka 和 Clojure 的工程师，抢在我前面完成那些工作，也是很正常的。

缘起

动笔写这个系列，始于上半年我还在火币的时候，那时刚从医院出来，戴着一个略蒸汽朋克的骨骼支具，跟现在主持火币撮合引擎的张淞老师有过一些交流。他认为撮合是个很紧凑很典型的逻辑，很适合当作练习项目，建议我们几个都自己实现一个撮合引擎试试。

所以我夏天在家里的时候，就基于 Akka 和 Clojure 以及 Java ，做了一些实验，从头用新的技术架构实现交易所相关的各种逻辑，现在演示的这个教学项目，有一些来自于六七月份的实验项目，这也是项目代码中有些冗余内容，不够精简的原因之一，为了我们这个教程不至于太过发散，我去掉了夏天实现的一部分逻辑，例如撮合引擎对开盘收盘和集合竞价的支持，这里我们假设它总是7x24小时工作。

撮合本身，用张淞老师的话说，应该是几百行逻辑能够实现的，当然这个语境在于火币的撮合引擎是个纯 Clojure 项目，有完整的上下游服务支撑。我自己写的这个引擎呢，因为想要尝试各种感兴趣的技术，写起来就没有那么紧凑，特别是 Java 代码的表达能力，比 Clojure 还是差不少。但是通过 Java ，我们使我们的项目有了一个高质量的分布式框架支撑，Akka 给这个项目架构带来的潜力，又是纯 Clojure 项目不能比的。总的来说，我个人觉得这次实验非常有收获，很开心，这也是现在拿出来跟大家分享这些东西的动力。

撮合逻辑

在有了周边代码的支撑之后，撮合节点的逻辑就非常简单了，我们要在actor里维护这样一组内存状态：交易对名 symbol

最后一个处理的订单标识 latest order id

卖单列表 asks

买单列表 bids

当然我们前面的章节也说过，这里我们对交易做了简化，假设总是有足够的限价单 ，使得市价单永远都会被立刻完全成交，实际上虽然“盘口击穿”确实是交易所极力避免的事情，但是并非没有出现这种情况的可能，特别是数字加密货币市场本身就很小。如果从程序上能够处理这种情况，我们应该加入两个列表，专用于维护未完成的市价单，并且在新的订单进入时，优先(按下单时序)撮合。

但是支持这样的逻辑会带来一些新的复杂性，例如盘口的某个方向已经被击穿，此时对向的市价单进入时，按什么样的价格撮合两个市价单？在有足够市场深度的前提下，我们就不需要考虑这种问题，每个市价单只会与对手方向的市价单进行撮合，这使得整个逻辑简单清晰。

有兴趣的同行也可以尝试自行实现这个逻辑。

相对来说限价单的撮合实现要清晰一些，它总是尝试在对手方向成交，剩下的部分称为 dash 的一部分。</