技术领域
[0001] 本
发明属于
数字货币交易技术领域，特别是涉及一种基于内存的高可用交易撮合引擎集群。
背景技术
[0002] 采用
数据库撮合技术，撮合引擎按照挂单时间先后顺序从数据库中选举一个主动方订单，再从数据库中按照“价格优先、同价格时间优先”的顺序返回满足成交条件(即买单价格不低于卖单价格)的对手方订单进行撮合匹配。撮合引擎从数据库中查询满足成交条件的对手方订单进行撮合匹配，查询数据库需要频繁IO操作，加大了数据库的负载，消耗了带宽资源，撮合引擎吞吐率下降，整体性能较差，当出现高并发大流量下单，数据库中积累大量未成交的订单，从数据库中查询订单的时间变长，导致系统出现大量慢查询sql，撮合性能急剧下降，甚至出现数据库CPU耗尽情况，系统
雪崩。
[0003] 撮合引擎集群采用多机热备保证撮合系统的高可用，将一组撮合引擎互为备份，同一时间只有一台撮合引擎提供服务，撮合引擎基于交易对分发撮合任务。所有的撮合任务都在正常工作的撮合引擎上执行，随着交易系统交易对的不断增加，正常工作的交易引擎被分发更多的任务，撮合性能下降，无法通过横向扩展集群来确保交易引擎的高性能，同时作为备份的机器大部分情况是闲置不工作的，造成
服务器资源浪费。
[0004] 因此亟需一种基于内存的高可用交易撮合引擎集群及其撮合方法，解决
现有技术中存在的数据库负载高、高可用特性下降以及无法横向扩展集群的问题。
发明内容
[0005] 本发明的目的在于提供一种基于内存的高可用交易撮合引擎集群，以实现高速撮合匹配、提高交易引擎的高可用特性以及易扩展的目的。
[0006] 本发明所采用的技术方案是提供一种基于内存的高可用交易撮合系统，包括：
[0007] 用户客户端：用于终端用户进行委托报价与确定订单数量，生成主动方订单发送至交易平台；
[0008] 网关：用于用户登录鉴权，并安全校验；
[0009] 订单模
块：用于接收用户挂单
请求，同时接收新增用户订单；
[0010] 撮合引擎集群模块：交易系统的核心部分，用于接收订单并根据业务逻辑实现订单撮合同时生成
交易记录，随后给予用户交易结果反馈；
[0011] 撮合交易
算法模块：用于对用户所下订单进行公平合理的排列和撮合，保证撮合算法的公平、高效以及扩展性；
[0012] 异步持久化模块：撮合引擎订单撮合成交后，异步
修改订单、形成交易记录；
[0013] 内存重建模块：用于当撮合引擎接管新的撮合任务或撮合引擎重启时从数据库重建内存到撮合引擎；
[0014] zookeeper
节点注册模块：用于发现撮合引擎的异常，同时进行撮合任务动态调度的分配，确保撮合引擎的高可用性；
[0015] 数据库：用来存放交易过程中的订单和交易记录，实现数据持久化。
[0016] 进一步地，所述撮合引擎集群模块由多个相互独立执行的撮合引擎节点构成，所述撮合引擎节点为进行交易撮合的服务器节点。
[0017] 进一步地，所述撮合引擎集群模块与所述zookeeper节点注册模块配合实现撮合任务的分配，包括以下三种情形：
[0018] 情形一：当所述撮合引擎集群模块需要支持新交易对的撮合时，撮合引擎集群模块中的所有撮合引擎节点均向zookeeper节点注册模块注册交易对临时节点，所述临时节点以交易对的名称命名；运用zookeeper临时节点分布式特性，注册成功一个撮合引擎节点，并开启所述撮合引擎节点上新交易对的撮合任务；
[0019] 情形二：当一个撮合引擎节点异常下线，该撮合引擎节点之前向zookeeper节点注册模块注册成功的交易对临时节点自动删除，zookeeper节点注册模块将异常下线事件通知给其他存活的撮合引擎节点，所述存活的撮合引擎节点再次向zookeeper节点注册模块注册所有交易对临时节点。
[0020] 情形三：当横向扩展需新增一个撮合引擎节点时，所述新增的撮合引擎节点向zookeeper节点注册模块注册撮合引擎持久节点，zookeeper节点注册模块监听该注册事件，删除现有撮合引擎节点注册的交易对临时节点，并通知包括新增撮合引擎节点在内的所有撮合引擎节点发起交易对临时节点的注册，所述临时节点以交易对命名，注册临时节点成功的交易引擎节点均开启相应交易对的撮合任务，实现服务的横向扩展。
[0021] 本发明还公开了一种基于内存的高可用交易撮合系统的交易撮合方法，包括以下步骤：
[0022] S1，通过用户客户端生成委托订单，经网关登录鉴权后将订单发送至订单模块；
[0023] S2，所述订单模块接受用户订单后，同步将订单持久化到数据库，形成主动方订单；所述主动方订单是主动查找已经存在的订单，并与已经存在的订单进行撮合匹配的订单。
[0024] S3，撮合引擎节点从所述S2的数据库查询订单，并放入相应的内存队列中按照撮合引擎算法模块的
进程进行撮合交易，所述撮合交易按照“价格优先、同价格则时间优先”的原则进行；
[0025] S4，撮合引擎节点达成成交后，根据匹配结果，更新或者删除撮合引擎节点内存队列中的订单；
[0026] S5，通过异步持久化模块修改数据库订单状态，形成交易记录。
[0027] 进一步地，所述S3中的订单包括限价买单、市价买单、限价卖单和市价卖单；所述队列包括限价买单队列、市价买单队列、限价卖单队列和市价卖单队列。
[0028] 进一步地，所述S3中的撮合过程包括以下情形：
[0029] 情形一：若主动方订单是限价买单，则先到限价卖单队列查找是否存在符合价格规则的卖单；
[0030] 如果限价卖单队列不为空，且存在卖出价格小于或等于买单的价格的订单，则从限价卖单队列中弹出队首订单并达成一笔成交；
[0031] 如果限价卖单队列不为空，且不存在卖出价格小于或等于买单的价格的订单，则判断市价卖单队列是否为空：如果市价卖单队列为空，则不能成交；如果市价卖单队列不为空，则从市价卖单队列弹出队首订单并达成一笔成交；
[0032] 如果限价卖单队列为空，则判断市价卖单队列是否为空：如果市价卖单队列为空，则不能成交；如果市价卖单队列不为空，则从市价卖单队列弹出队首订单并达成一笔成交。
[0033] 如果所述限价买单不能与限价卖单队列、市价卖单队列中的订单完全成交，即限价买单的数量存在剩余，则将剩余的限价买单插入限价买单队列中；所述限价买单队列按照价格由高到低排列；
[0034] 情形二：若主动方订单是市价买单，则到限价卖单队列查找是否存在限价卖单；如果限价卖单队列不为空，则从限价卖单队列中弹出队首订单并达成一笔成交；如果所述市价买单不能与限价卖单队列中的订单完全成交，则将所述市价买单插入市价买单队列中；如果限价卖单队列为空，则所述市价买单不能成交，将所述市价买单插入市价买单队列中；
所述市价买单队列按订单时间由远到近排列；
[0035] 情形三：若主动方订单是限价卖单，则先到限价买单队列查找是否存在符合价格规则的限价买单；
[0036] 如果限价买单队列不为空，且存在买入价格大于或等于卖出价格的订单，则从限价买单队列中弹出队首订单并达成一笔成交；
[0037] 如果限价买单队列不为空，且不存在买入价格大于或等于卖出价格的订单，则判断市价买单队列是否为空：如果市价买单队列为空，则不能成交；如果市价买单队列不为空，则从市价买单队列弹出队首订单并达成一笔成交；
[0038] 如果限价买单队列为空，则判断市价买单队列是否为空：如果市价买单队列为空，则不能成交；如果市价买单队列不为空，则从市价买单队列弹出队首订单并达成一笔成交；
[0039] 如果该限价卖单不能与限价买单队列、市价买单队列中的订单完全成交，即限价卖单数量存在剩余，则将剩余的卖单数量插入限价卖单队列中；所述限价卖单队列按照价格由低到高平排列；
[0040] 情形四：若主动方订单是市价卖单，则到限价买单队列查找是否存在限价买单；如果限价买单队列不为空，则从限价买单队列中弹出对列首订单并达成一笔成交；如果所述市价卖单不能与限价买单队列中的订单完全成交，则将所述市价卖单插入市价卖单队列中；如果限价买单队列为空，则所述市价卖单不能成交，将所述市价卖单插入市价卖单队列中；所述市价卖单队列按照订单时间由远到近排列。
[0041] 进一步地，所述S4中更新或者删除撮合引擎节点内存队列中的订单过程为：
[0042] 如果订单完全成交，删除对应内存队列中的订单；如果未完全成交，修改相应内存队列中的剩余订单数量。
[0043] 进一步地，所述S5中异步持久化模块修改数据库订单状态的过程与所述S4中更新或者删除撮合引擎节点内存队列中订单过程相同，以保证从数据库恢复的内存数据与异常丢失数据的最终一致性。
[0044] 本发明的有益效果是：
[0045] 1.交易撮合引擎无需从数据中查询订单进行撮合匹配，减少与数据库的IO操作，降低数据库负载，节省带宽资源，提升吞吐率，实现高速撮合匹配，每秒可完成50万笔成交。
[0046] 2.交易引擎具备高可用特性，当集群中某一台故障或者异常时，可由正常的交易引擎库快速自动接管异常交易引擎的交易撮合任务。
[0047] 3.交易引擎具备易横向扩展特性，如果现有交易引擎集群出现性能
瓶颈，或交易系统需要支持更多交易对交易撮合，只需增加交易引擎服务器，不需要修改程序，不需要重启交易引擎。
附图说明
[0048] 为了更清楚地说明本发明
实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0049] 图1是本发明的内存队列结构图。
[0051] 图3是撮合系统的整体架构图。
具体实施方式
[0052] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0053] 名称解释：
[0054] 撮合引擎：进行交易撮合的服务器节点。
[0055] 交易对：例如欧元/美元(EUR/USD)。
[0056] 主动方订单：该订单主动去查找已经存在的订单，并与已经存在的订单进行撮合匹配。
[0057] 对手方订单：该订单被主动方订单查找，并被主动方订单撮合匹配。
[0058] 例如交易引擎已经存在了10个未成交的卖单，此时用户新增一个买单，撮合引擎选择该买单去内存队列中匹配已经存在的10个未成交的卖单，则买单为主动方订单，卖单为对手方订单。
[0059] 撮合匹配：买卖订单根据公开公平的规则进行撮合，达成一笔成交。
[0060] 一笔成交：以BTC/USD交易对为例，该订单购买100个BTC，价格为5000USD，如果订单系统拥有卖单1，数量为40，价格为4900；卖单2数量为70，价格为4995，则该买单会先与卖单1达成一笔成交(成交数量为40)，再和卖单2达成一笔成交(成交数量为60)[0061] 订单完全成交：以BTC/USD交易对为例，该订单购买100个BTC，价格为5000USD，如果订单系统拥有卖单1，数量为40，价格为4900；卖单2数量为70，价格为4995，则该买单会先与卖单1达成一笔成交(成交数量为40)，再和卖单2达成一笔成交(成交数量为60)，则该买单完全成交
[0062] 订单部分成交：以BTC/USD交易对为例，该订单购买100个BTC，价格为5000USD，如果订单系统拥有卖单1，数量为40，价格为4900；卖单2数量为20，价格为4995，则该买单会先与卖单1达成一笔成交(成交数量为40)，再和卖单2达成一笔成交(成交数量为20)，则该买单还剩余100-40-20＝40个BTC，该买单部分成交
[0063] 订单无法成交：以BTC/USD交易对为例，该订单购买100个BTC，价格为5000USD，如果订单系统拥有卖单1数量为40，价格为5100；卖单2数量为20，价格为5200，则该买单的价格低于卖单1的价格，该买单无法成交
[0064] 订单未完全成交：包括订单部分成交、订单无法成交
[0065] 1.内存队列数据结构：
[0066] 自研基于跳表的线程安全有序内存队列，队列的插入、查找时间复杂度为O(logn)，在高并发读写队列时也可保证内存数据的线程安全，并最大程度保证队列数据的高性能读写。
[0067] 2.内存订单队列：
[0068] 交易系统的重要组成部分就是买卖订单，通过对买卖订单进行交易撮合最后产生交易记录。撮合引擎算法模块是程序代码的模块划分，是运行在撮合引擎节点上的代码块，代码逻辑中实现了内存订单队列保存、更新。
[0069] 所以对无法立刻完成撮合的订单，需要有买单队列和卖单队列保存订单，买单队列和卖单队列分别包含限价、市价队列。限价队列按照“价格优先、同价格时间优先”的原则，市价队列按照“时间优先”的原则。限价买单队列按照委托价格从高到低、同价格时间优先顺序排列，市价买单队列按照时间优先顺序排列，限价卖单队列按照委托价格从低到高、同价格时间优先顺序排列，市价卖单队列按照时间优先顺序排列。下次有新的订单进入交易引擎时，可快速从队列中取出对手订单进行撮合匹配。队列结构如图1所示。
[0070] 3.交易撮合算法：
[0071] 撮合引擎算法模块是程序代码的模块划分，是运行在撮合引擎节点上的代码块，撮合任务(进程)会执行该模块的代码进行选举主动方订单、与对手单进行撮合匹配。撮合任务从数据库选举一个最新的主动方订单。具体过程如下：
[0072] S1，若主动方订单是限价买单，则先到限价卖单队列查找是否存在符合价格规则的卖单；
[0073] 如果限价卖单队列不为空，且存在卖出价格小于等于买单的价格的订单，则从限价卖单队列中弹出队首订单并达成一笔成交。
[0074] 如果限价卖单队列不为空，且不存在卖出价格小于等于买单的价格的订单，则判断市价卖单队列是否为空，如果市价卖单队列为空，则不能成交，如果市价卖单队列不为空，则从市价卖单队列弹出队首订单并达成一笔成交。
[0075] 如果限价卖单队列为空，则判断市价卖单队列是否为空，如果市价卖单队列为空，则不能成交，如果市价卖单队列不为空，则从市价卖单队列弹出队首订单并达成一笔成交。
[0076] 如果该限价买单不能与限价卖单队列、市价卖单队列中的订单完全成交，以BTC/USD交易对为例，该限价买单购买100个BTC，价格5000USD，此时限价卖单队列(符合价格规则)、市价卖单队列中所有订单总共卖出80个BTC，那么该限价买单和限价卖单、市价卖单中的订单达成多笔成交后，还会剩余20个BTC，即该限价买单未完全成交，则将该限价买单插入限价买单队列中(买入剩余数量为20)；由于限价买单队列是按照价格由高到低排序，所以新插入的订单会经过一次排序插入到限价买单队列的相应
位置。
[0077] S2，若主动方订单是市价买单，则到限价卖单队列查找是否存在限价卖单；
[0078] 如果限价卖单队列不为空，则从限价卖单队列中弹出对列首订单并达成一笔成交。如果该市价买单不能与限价卖单队列中的订单完全成交，则将该市价买单插入市价买单队列中(数量为剩余数量)。
[0079] 如果限价卖单队列为空，则该市价买单不能成交，将该市价买单插入市价买单队列中。
[0080] 由于市价买单队列是按时间由远到近排序，所以新插入的订单会经过一次排序插入到市价买单队列的相应位置。
[0081] S3，若主动方订单是限价卖单，则先到限价买单队列查找是否存在符合价格规则的限价买单；
[0082] 如果限价买单队列不为空，且存在买入价格大于或等于卖出价格的订单，则从限价买单队列中弹出队首订单并达成一笔成交。
[0083] 如果限价买单队列不为空，且不存在买入价格大于或等于卖出价格的订单，则判断市价买单队列是否为空，如果市价买单队列为空，则不能成交，如果市价买单队列不为空，则从市价买单队列弹出队首订单并达成一笔成交。
[0084] 如果限价买单队列为空，则判断市价买单队列是否为空，如果市价买单队列为空，则不能成交，如果市价买单队列不为空，则从市价买单队列弹出队首订单并达成一笔成交[0085] 如果该限价卖单不能与限价买单队列、市价买单队列中的订单完全成交，以BTC/USD交易对为例，该限价卖单卖出100个BTC，价格5000USD，此时限价买单队列(符合价格规则)、市价买单队列中所有订单总共买入80个BTC，那么该限价卖单和限价买单、市价买单中的订单达成多笔成交后，还会剩余20个BTC，即该限价卖单未完全成交，则将该限价卖单插入限价卖单队列中(卖出剩余数量为20)；由于限价卖单队列是按照价格由低到高排序，所以新插入的订单会经过一次排序插入到限价买单队列的相应位置。
[0086] S4，若主动方订单是市价卖单，则到限价买单队列查找是否存在限价买单；
[0087] 如果限价买单队列不为空，则从限价买单队列中弹出对列首订单并达成一笔成交。如果该市价卖单不能与限价买单队列中的订单完全成交，则将该市价卖单插入市价卖单队列中(数量为剩余数量)。
[0088] 如果限价买单队列为空，则该市价卖单不能成交，将该市价卖单插入市价卖单队列中。
[0089] 由于市价卖单队列是按时间由远到近排序，所以新插入的订单会经过一次排序插入到市价卖单队列的相应位置。撮合算法流程图如图2所示。
[0090] 4.内存订单重建：
[0091] 由于内存交易撮合技术将订单存放于撮合引擎内存中(java
虚拟机堆中)，当撮合引擎出现异常如断电重启，该出现断电的撮合引擎的撮合任务可立刻被其他正常工作的撮合引擎接管，断电的撮合引擎内存数据将会在正常工作的撮合引擎内存中重建。当断电的撮合引擎接通电源并重启服务时，该断电的撮合引擎可重新分配撮合任务并重建内存数据。
[0092] 即不管是正常工作的撮合引擎接管撮合任务，还是出现断电的撮合引擎重启恢复撮合任务，都需要有重建内存订单的流程，重建内存流程如下：
[0093] 用户委托订单时，订单模块同步将订单持久化到数据库。
[0094] 撮合引擎节点重启或者接管其他撮合引擎节点的撮合任务时，从订单模块的数据库查询订单，放入相应的市价、限价、买、卖内存队列中。订单模块可以直接
访问数据库中的订单表，包括新增订单、查询订单、修改订单。
[0095] 撮合引擎节点达成成交时，首先根据匹配结果，更新或者删除撮合引擎节点内存队列中的订单：如果订单完全成交，删除内存队列中的订单；如果未完全成交，修改内存队列中的剩余订单数量。
[0096] 再将订单匹配结果异步告知异步持久化模块，由该模块完成数据库中订单的更新或删除；如果订单完全成交，则删除数据库中的订单，如果订单未完全成交，则更新订单的剩余数量；从而保证从数据库恢复的内存数据与异常丢失数据的最终一致性。内存重建流程图见交易撮合系统整体架构图3。
[0097] 5.撮合引擎集群模块与zookeeper节点注册模块配合实现撮合任务分配：
[0098] 撮合引擎节点基于交易对创建撮合任务，每个交易对分配一个撮合任务(线程)，撮合引擎集群模块中的多个撮合引擎节点平均分配撮合任务。交易对为订单的属性之一，即订单是属于某个交易对的。买卖订单进行撮合匹配时，只能匹配同交易对的订单。当系统需要支持新的交易对的交易时，会通过相应的后台系统，将新增的交易对保存到数据库的交易对表中，撮合引擎节点再查询交易对表，即可知道新增了交易对。
[0099] 例如有3台撮合引擎节点，150个交易对撮合匹配任务，则每个交易引擎运行50个撮合任务。
[0100] 使用分布式协同
中间件zookeeper进行撮合引擎异常发现和撮合任务动态调度分配，当撮合引擎出现异常如断电重启时，正常工作的撮合引擎可迅速接管异常撮合引擎的撮合任务，确保交易撮合的高可用性，当交易系统动态新增交易对时，可实时创建新交易对的撮合任务，如果现有撮合引擎由于分配了过多的交易对撮合任务而出现性能瓶颈，可横向扩展新增撮合引擎点，zookeeper节点注册模块监听节点上线事件，动态重新平均分配交易任务到新的撮合引擎节点运行。
[0101] 以下是当新增交易对、撮合引擎异常重启下线、横向扩展新增撮合引擎点的撮合任务分配说明。撮合引擎集群及任务分配见交易撮合系统整体架构图3。
[0102] 当撮合引擎集群需要支持新交易对AAA/BBB撮合时，撮合引擎节点1、2、3都向zookeeper节点注册模块注册交易对临时节点，该临时节点以交易对AAA/BBB命名，运用zookeeper临时节点分布式特性，只会有一个撮合引擎节点可以注册成功，假设节点1注册成功，节点1监听到zookeeper节点注册成功回调事件，节点1开启该交易对AAA/BBB的撮合任务(线程)。
[0103] 当撮合引擎节点1异常下线时，撮合引擎节点1之前向zookeeper注册成功的交易对临时节点将会自动删除，zookeeper节点注册模块将节点1的异常下线事件通知给存活的2、3撮合引擎节点，存活的2、3撮合引擎节点再次向zookeeper集群注册所有交易对临时节点。
[0104] 例如撮合引擎节点2注册成功交易对BTC/USD，那节点2就将负责交易对BTC/USD的订单撮合；撮合引擎节点3注册成功交易对ETC/USD，那节点3就将负责交易对ETC/USD的订单撮合。即所有的撮合任务都会被随机分配到节点2、3上运行，节点1的下线不影响撮合任务的正常运行，实现服务高可用。
[0105] 当横向扩展新增撮合引擎点4时，新增的节点4向zookeeper集群注册撮合引擎持久节点，该持久节点以撮合引擎节点4的ip命名，zookeeper集群监听该注册事件，删除现有撮合引擎节点1、2、3注册的交易对临时节点，并通知所有撮合引擎节点1、2、3、4发起交易对临时节点的注册，该临时节点以交易对命名，注册临时节点成功的交易引擎节点即可开启相应交易对的撮合任务(线程)，即所有的交易对的撮合任务都会被随机分配到节点1、2、3、4上运行，实现服务横向扩展。
[0106] 以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。
