一种交易信息处理方法、系统及计算机可读存储介质与流程

1.本发明涉及一种券商交易系统中的处理交易信息的方法及系统。特别是将突发的交易消息转换为串行的消息队列的交易方法和系统。


背景技术：

2.券商交易系统的功能，主要涉及资金方面的处理业务，比如客户入金后，在交易市场中做股票、期权、数字货币、外汇等交易。交易中数据的安全性非常重要，券商交易系统中，会存在多路数据访问的情况，那么为了保证数据的访问安全，避免访问冲突，保证数据的唯一性和准确性，通常做法是在处理业务时，基于db锁进行控制，也就是同一时刻只允许一路操作进行访问，其他路的访问操作必须等待，这种做法会导致并发效率低，不利于团队协作的问题，严重影响交易系统的处理效率和处理能力，也存在模块耦合度高，导致模块之间的协作效率低的问题。另外，现有交易系统基于db操作，存在io开销大的问题，导致交易延时大，根本不满足高速交易的业务需求。


技术实现要素：

3.本发明提出了一种交易信息处理方法，接收交易消息并进行处理；将所述处理后的所述交易消息发送至交易引擎队列进行处理以输出串行的交易消息队列；交易引擎接收交易引擎队列输出的所述串行的交易消息队列，并对所述交易消息队列中的交易消息进行处理。
4.在进一步的方案中，所述交易引擎接收交易引擎队列输出的所述串行的交易消息队列并对所述交易消息队列中的交易消息进行处理包括：根据所述交易消息对内存中的微账本进行读写操作，以实现账户查询、记录的功能，所述微账本包含总账本的部分数据，所述微账本的字段数量低于所述总账本的字段的数量。
5.在进一步的方案中，所述微账本包括现金账户信息、公共账户信息以及保证金信息。
6.在进一步的方案中，设置对微账本进行备份的数据库，以对内存中的微账本数据进行备份存储。
7.在进一步的方案中，所述交易引擎接收交易引擎队列输出的所述串行的交易消息队列并对所述交易消息队列中的交易消息进行处理还包括淘汰处理步骤，用于对最近一段时间没有发生交易的账户，从内存中移除对应的微账本；并用于在当该账户间隔一段时间后，再次发生交易时，从数据库中加载微账本数据到内存中。
8.在进一步的方案中，所述交易引擎接收交易引擎队列输出的所述串行的交易消息队列并对所述交易消息队列中的交易消息进行处理还包括账户分级处理步骤，所述交易引擎具有多个，将微账本按照账户资金规模和活跃度进行区分，并分发到不同的交易引擎中进行处理，使得交易引擎的负载均衡。
9.在进一步的方案中，所述交易引擎具有多个，并具有多个对应的内存，所述交易引
擎接收交易引擎队列输出的所述串行的交易消息队列并对所述交易消息队列中的交易消息进行处理还包括容灾处理步骤，当其中一个所述交易引擎发生故障后，通过监听kafka consumer的rebalance事件，发送给所述一个交易引擎的交易消息被转发到另一个交易引擎中，并清除对应于所述一个交易引擎的内存中的微账本，并从数据库中重新加载微账本到对应于所述一个交易引擎的内存。
10.在进一步的方案中，所述交易引擎接收交易引擎队列输出的所述串行的交易消息队列并对所述交易消息队列中的交易消息进行处理还包括故障消息处理步骤：为账户设置隔离状态或正常状态，将该账户的隔离状态或正常状态记载在所述微账本中；并且对于隔离状态下的账户，将发送队列中的新的交易消息转发到错误队列中排队进行隔离；从错误队列回流到发送队列的消息进行正常处理；并且当账户从正常转为隔离状态后，所述微账本记录上述转发到所述错误队列中的第一条消息在所述错误队列中的偏移量，作为后续回流消息的起点；当账户在隔离状态下，所述微账本跟踪记录最近一次隔离消息在发送队列中的偏移量；恢复程序从起点开始扫描错误队列消息，将相关账户的消息回流到发送队列再次处理；当回流消息的原始发送队列的偏移量等于微账本记录的最近一次隔离消息的发送队列的偏移量，说明错误队列中的消息已经全部回流处理完毕，则将账户恢复成正常状态。
11.在进一步的方案中，所述交易引擎队列采用kafka平台来实现，用于将突发的并行的上述交易消息转换为串行消息序列，所述kafka平台按照shardingkey进行分发消息的特性，交易引擎使用账户号码作为shardingkey，保证账户业务消息被同一个所述交易引擎消费处理。
12.在进一步的方案中，所述接收交易消息并进行处理包括以下步骤中的一者或多者：接收及处理资产管理业务信息，并将该资产管理业务信息发送至所述交易引擎队列进行汇总；接收及处理交易所反馈回的fix格式的交易反馈信息，进行协议处理，并将所述交易反馈信息发送至所述交易引擎队列进行汇总；接收及处理客户的交易请求消息，并将所述交易请求消息发送至所述交易引擎队列进行汇总。
13.还提出了一种交易信息处理系统，包括：交易消息接收处理模块，接收交易消息并进行处理；交易引擎队列模块，用于对所述交易消息接收处理模块发送的交易消息进行处理并输出串行的交易消息队列；交易引擎，用于接收交易引擎队列模块输出的串行的交易消息队列，并对所述交易消息队列中的交易消息进行处理。
14.还提出了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现上述方法。
15.本发明利用消息队列的方式来处理各个突发的交易消息，将突发的并行的交易信息转换为串行的消息队列，由交易引擎进行处理，借助kafka消息队列对系统进行解耦，提高了消息处理效率，解决了db锁加锁导致不能并行处理，交易处理效率低的问题，
附图说明
16.图1为本发明的交易系统的硬件结构框图；
17.图2为本发明的交易系统的功能模块框图；
18.图3为本发明的微账本的数据结构示意图；
19.图4为本发明中kafka队列的故障消息处理机制的功能模块框图；
20.图5为图4中发送引擎处理故障消息的流程图；
21.图6是本发明故障消息处理中的恢复程序流程图。
具体实施方式
22.图1为本发明的交易系统的硬件结构框图。包括服务器1、智能移动终端2、pc机3、以及各大交易所交易系统4。服务器1中运行有本发明如图2所示的交易系统，服务器1分别与智能移动终端2、pc机3、以及各大交易所交易系统4连接，通过通信接口进行数据通信，服务器1能够通过通信接口从智能移动终端2、pc机3接收交易指令、查询指令等，对交易指令进行处理，并根据交易指令反馈交易信息或者根据查询指令返回查询的信息。
23.实施例一
24.图2为本发明的交易系统的功能模块框图。为了解决db锁加锁导致不能并行处理，交易处理效率低的问题，本发明利用消息队列的方式来处理各个突发的交易消息，按模块进行划分，借助kafka消息队列对系统进行解耦。交易引擎所需的数据由各个模块通过kafka送入到交易引擎中，将并发的交易消息转换为顺序执行的交易消息队列，从而实现了无锁化的设计。
25.如图2所示，本发明的交易引擎214通过kafka平台的交易引擎队列212来接收外部消息，通过kafka输出数据。
26.kafka是一个开源流处理平台，由scala和java编写。kafka的目的是通过hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。提供消息的持久化，这种结构对于即使数以tb的消息存储也能够保持长时间的稳定性能。本发明借助kafka平台来处理交易的指令和消息，可按照shardingkey进行分发消息的特性，交易引擎使用账户号码(accountnumber)作为shardingkey，保证账户业务消息被同一个交易引擎消费处理，这样保证了同账户的消息是按序处理，达到串行的目的，从而不需要锁，提高了处理效率。
27.如图2所示，送入交易引擎214的交易消息来源有：
28.a.资产管理消息：客户的出入金、账务、转仓、风控授信等业务信息。图2中资产管理模块211用于接收出入金、账务、转仓、风控授信等等资产管理业务信息，并通过kafka消息队列转换为串行信息流，进而发送至交易引擎队列212汇总。资产管理模块211具体包括出入金、账务、转仓消息接收处理模块、风控授信计算模块、kafka消息队列模块、以及资产管理模块。
29.b.fix引擎(fix-engine)消息：主要涉及交易所反馈回的交易反馈信息，包括证券交易成功、失败等消息，交易信息采用fix(financialinformationexchange)协议来传输。图2中fix引擎模块213对接全球各大交易所3，路由和传输各大交易所的客户交易数据。fix引擎模块213包括fix-引擎用于向交易机构(例如证券交易所)提交交易请求小；并接收交易机构反馈的fix格式的交易信息，例如交易成功、失败的信息er，并将信息发送至交易引擎队列212进行汇总。fix引擎模块213还包括采用kafka平台的fix消息队列模块，接收交易引擎214发出的交易请求消息并转换为消息队列发送至fix引擎，fix引擎进行协议处理，通过金融领域的fix协议格式将交易请求消息发送至证券交易机构3。
30.c.订单服务(orderservice)消息：包括客户的下单、撤单等交易请求消息。图2中的订单服务模块215用于从客户端2、3发出的下单消息，例如股票、期货交易等，客户端2、3包括图1中的智能移动终端2、pc机3等设备；另外订单服务模块215还接收策略下单/撤单的交易请求，例如组合交易策略订单。订单服务模块215在收到突发的交易请求消息之后，将交易请求消息送入交易引擎队列212进行汇总，以形成串行的消息流序列。订单服务模块215在收到交易请求消息之后，还发消息至营销佣金管理模块，用于营销佣金的管理；以及将交易请求消息以只读形式发送至订单数据库(订单db)。
31.d.其他消息：包括风控其他控制消息，以及账户消息。
32.如图2所示，交易引擎214输出的数据有客户的资金变化、订单变化、变更日志、交易请求消息等消息，下游模块基于这些数据做客户的持仓变更、资金清算、订单成交登记、消息推送到app端、以及fix引擎模块213交易请求消息提交至交易所进行交易等操作。
33.具体而言，kafka交易引擎队列214接收以上交易消息，并转换为消息队列输出给交易引擎214。
34.交易引擎214从kafka交易引擎队列模块214顺序接收交易消息并进行处理和输出：将交易请求信息通过fix队列发送至各大交易所进行交易，交易引擎214根据交易所返回的交易消息、资产管理消息对内存216中的账本信息进行读写操作，以更新账本信息；将资金变化、订单变化、变更日志等信息发送至资金队列模块，进而后续的持仓变更、资金清算、订单成交登记、以及将消息推送到app端。具体地，资金队列中的订单变化消息发送至订单维护模块，以对订单数据库进行写操作，以进行订单成交登记；资金队列中的资金变化消息发送至资金维护模块，以对资金数据库进行更新；资金队列中的资金变化消息还发送至清算队列和清算服务模块，以进行资金清算；资金队列中的消息还送到实时计算引擎，进而通过实时资产消息队列将消息推送到app端1、2。
35.对于交易引擎而言，还需要一些外部数据，这些数据分为两类：
36.(1)变化非常频繁的数据，类似行情报价。对于这类数据，数据存储在redis中，通过接口直接从redis中读取，也非常高效。
37.(2)数据相对固定的数据，比较典型的数据有：标的数据、保证金率、交易日历等，借助推送系统，交易引擎214接收到数据后，保存到内存216中。交易引擎214中直接访问内存216，非常高效。
38.实时计算引擎能够接收报价服务(例如市场行情)，形成策略下单和策略撤单(比如买卖组合订单)，送入策略下单/撤单队列，进而发送至订单服务模块215。实时计算引擎还将报价信息通过实时资产消息队列实时发送到客户端2、3，从而使得客户端的信息被更新。
39.以上交易引擎队列、fix消息队列等含有队列的模块，均可采用kafka平台来实现，以将突发的并行数据转换为串行消息序列。
40.如上可知，本发明的交易系统主要具有以下特点：
41.1、无锁化设计：
42.如图2所示，本发明的交易引擎通过kafka来接收外部消息，通过kafka输出数据。借助kafka可按照shardingkey进行分发消息的特性，交易引擎使用账户号码(accountnumber)作为shardingkey,保证账户业务消息被同一个交易引擎消费处理，这样
保证了同账户的消息是按序处理，达到串行的目的，从而不需要锁。
43.2、读写分离：
44.从图2的业务流程图中可以看出，数据是单向流动。举个例子：
45.下单(写)：账户交易请求—》订单服务215(orderservice)—》kafka交易引擎队列212—》交易引擎214(engine)—》fix消息队列以及fix引擎(fixgw)—》kafka交易引擎队列212—》交易引擎214(engine)—》资金队列(assetsbus)—》订单维护(orderpersist)。
46.查询(读)：订单维护(orderpersist)持久化到订单db后，账户从订单db中查询即可，数据量上升到一定量级后，订单数据会加载的到搜索引擎中，提供给账户做查询。
47.实施例二
48.现有的交易系统中，基于db操作，也就是每个交易都需要对数据库(例如mysql)进行读写io(inputoutput)，导致输入输出开销大，交易延时大，无法不满足高速交易的业务需求。
49.通常，一个账户具有非常庞大的数据项目，对于交易引擎来说，在交易中并不需要处理账户中的所有数据项目，交易中只涉及一些基本信息的处理，因此本发明出于性能考虑，本发明在一个实施例中，设计了微账本，简称小帐，采用了交易引擎小账的设计，在小账中包含了交易中用到的部分基本账户信息，从而精简了数据量，降低了io的开销。
50.如图3所示，为本发明中微账本的数据结构示意图。小账的主要结构如下：主要包括现金账户信息、公共账户信息以及保证金信息这三类基本信息，对于每一类信息，也仅包含了交易所用到的基本的数据信息项目，小账包含了总账本的部分数据，是总账本的精简版本，小账的字段数量低于总账本的字段的数量。
51.其中，现金账户信息包括现金(cash)的已结算资金信息和未结算资金信息两类。已结算资金信息包括以下数据项目：账户id、币种、已结算金额、入金授信金额、日初可提现金额、冻结金额、在途入金、atw1等；未结算资金信息包括：账户id、币种、品类、t+1未结算金额、t+2未结算金额、used已结算金额、usedt+1未结算金额、usedt+2未结算金额等。
52.公共账户信息包括主订单、子订单、子订单执行订单、持仓、公共属性这五类数据信息。其中、主订单信息包括：主订单id、订单策略(json)、订单类型、未成交子订单id列表、clientrefid等；子订单信息包括子订单id、主订单id、币种、品类、side、status、instrid、leaveqty、type、bpprice、execorderid、replaceorderid、execorderstatus等；子订单-执行订单信息包括：执行订单id、子订单id、主订单id等；持仓信息包括：instrid、币种、品类、qty、avgprice、todayopenqty、dtflag等；公共属性信息包括：账户类型、日切日期、offset、交易限制等。
53.保证金账户信息包括保证金(margin)的控制属性信息和资金信息两类。其中，控制属性信息包括：前4日dt次数(数组)、当天dt次数、日内保证金率、维持保证金率、regt保证金率、综合可提现金额(不含融资)、综合可提现金额(含融资)等数据项。资金信息包括：账户id、币种、现金、入金授信金额、冻结金额、在途入金、sma1、atm1-不融资、atw1-融资等数据项。
54.根据账户类型不同，为不同账户的小账设计不同的属性数据。在小帐中只保留客户的挂单(不维护账户挂单数据)，始终保持账户小帐数据精简。
55.另外，小帐还有一些特性：
56.1、二级缓存：为了防止由于服务器异常导致内存216中的小账数据丢失，小帐存储会分为二级存储，也就是小账数据会分别存到内存216以及另外的数据库(例如mongodb)中，交易引擎214优先从内存216中读取小帐，再次从mongodb中读取小帐，小账数据在内存216和mongodb中通过间断的备份机制进行备份，保障了数据安全并且减少数据读写量。交易引擎账户数据串行化处理，单点写入，保证大部分情况都是从内存216中读取小帐信息。
57.2、淘汰策略：由于账户数据非常多，但实际参与交易的客户相对较少，交易引擎设置了冷数据移除策略，对于最近一段时间没有发生交易的账户，从内存216中移除对应的小帐，减少了交易引擎的内存216消耗。当该账户间隔一段时间后，再次发生交易，此时从数据库(db)中加载小帐数据，保存到内存216中。
58.3、账户分级：按照账户资金规模和活跃度进行区分，分摊到不同的交易引擎中，防止一个交易引擎中聚集了大量大客户，导致交易引擎负载过大，使得交易引擎的负载均衡
59.4、容灾机制：假设当前有2个交易引擎，其中一个交易引擎发生故障后，通过监听kafkaconsumer的rebalance事件，账户的业务消息会转发到另外一个交易引擎中，从而实现24h服务不间断。这里有一个特别注意的事项：由于小帐数据采用两级缓存设计，当发生kafkarebalance后，必须清除内存216中的小帐信息，从db中重新加载小帐到内存216中，防止数据被污染。
60.实施例三
61.图4为本发明中kafka队列的故障消息处理机制的功能模块框图。
62.图4中的附图标记说明：41新消息、42不可正常处理、43隔离转发、44回流消息、45回流消息、46可正常处理；4001kafka消息发送队列(txbus)、4002发送引擎(txengine)、4003错误消息队列(errorbus)。
63.为了处理故障消息，本发明中在kafka消息发送队列4001(txbus)之外设置错误消息队列4003(errorbus)，用于对故障消息进行隔离，如果一个账户处于隔离状态，则该账户相关的新消息41在经过kafka消息发送队列4001(txbus)发送至发送引擎4002(txengine)时(如信号线42)，会被隔离，即转发至错误消息队列4003(errorbus)排队进行处理(如信号线43)。kafka消息发送队列4001(txbus)可以是图2中的任何一个kafka队列，例如可以是交易引擎队列、fix引擎队列、或资金队列等，发送引擎4002(txengine)可以是图2中与上述kafka队列对应的计算引擎，例如交易引擎214、fix引擎、或实时计算引擎等。
64.具体方法包括：
65.(1)账户有隔离与正常两种状态，记录在小账中；
66.(2)隔离状态下，txbus中的新消息41不能直接处理，要经过“隔离审查
”––
转到errorbus去排队(如信号线43)；而从errorbus回流到txbus的消息可以正常处理(如信号线45、46)；
67.(3)账户从正常转为隔离状态后，小账需记录其隔离的第一条消息在errorbus中的偏移量offset，作为后续回流消息的起点；
68.(4)隔离状态下，小账需跟踪记录最近一次隔离消息的在发送队列中的偏移量(txbusoffset)；
69.(5)恢复程序从起点开始扫描errorbus消息，将相关账户的消息回流到txbus再次处理；
70.(6)当回流消息的原始发送队列偏移量(txbusoffset)＝＝小账记录的最近一次隔离消息的发送队列偏移量(txbusoffset)，说明errorbus中的消息已经全部回流处理完毕，则将账户恢复成正常状态；
71.(7)在恢复过程中回流消息处理再次出现错误是常见的情况，此时应该中断本次恢复任务；
72.(8)回流到txbus的消息会有一个新的offset，此时应该用其原始的offset进行业务判断，而不是这个新的offset。采用原始offset判断的另一个巨大好处是：往txbus回流消息时不用进行去重处理了。
73.实施例四
74.图5为图4中发送引擎4002处理故障消息的流程图。发送引擎4002处理故障消息的具体步骤包括：
75.s51、发送引擎4002从消息发送队列4001(txbus)获取消息，转至s52；
76.s52、判断是否是隔离命令，如果否则转到s53；如果是隔离命令，则判断账户是否处于正常状态？如果否表明账户已经处于隔离状态则结束处理，如果不处于隔离状态则将账户设置为已隔离，结束处理；
77.s53、判断是否是恢复命令，如果否则转至s54；如果是恢复命令，则判断账户是否处于已隔离状态，如果否则结束处理，如果是则判断隔离消息是否为空，如果否则记录恢复批次id并结束处理，如果隔离消息起点为空，则将账户设置为正常，并给errorbus发送成功消息(带恢复批次id)；
78.s54、判断账户是否已经隔离；如果已经隔离则转到s55，如果否则转到s59；
79.s55、判断消息是否是errorbus回流消息，如果是回流消息则转至s56；如果不是回流消息，表明该消息是应当被隔离的新消息，则将该新消息转发至errorbus，并更新最近隔离消息的txbusoffset，并判断隔离消息起点是否为空，如果否则结束处理，如果是则更新隔离起点消息，并结束处理；
80.s56、如果s55中判断判断消息是errorbus的回流消息，则判断消息回复批次的id是否等于小账恢复批次id，如果否则结束处理；如果是则转到s57；
81.s57、更新隔离消息起点为消息errorbus的偏移量(offset)；并转到s58；
82.s58、将消息offset替换成消息原始txbusoffset；转至s59；
83.s59、正常处理消息；并转至s5a；
84.s5a、判断抛出指定异常请求隔离？如果是则转到s5b，如果否则判断账户是否处于已隔离状态，如果否则结束处理，如果是则判断消息原始txbus的offset是否等于小账最近隔离消息的txbusoffset，如果否则结束处理，如果是则将账户设置为正常，并给errorbus发送成功消息(带恢复批次id)；
85.s5b、判断账户是否处于已隔离状态？如果是则转到s5c；否则将消息转发至errorbus，更新最近隔离消息的txbusoffset，将账户设置为已隔离；
86.s5c、重置恢复批次id，忽略后续同批次回流消息，并结束处理。
87.实施例五
88.图6是本发明故障消息处理的恢复程序流程图。图4中恢复程序模块4004执行恢复程序，包括以下步骤：
89.s61、判断是否有同账户的恢复程序在运行？如果否则转至s62；如果是则结束处理；
90.s62、x＝errorbus最大offset+1，恢复批次id＝uuid；转至s63；
91.s63、判断账户是否处于已隔离状态？否的话结束处理，是的话转至s64；
92.s64、判断小账隔离消息起点是否为空？否的话转至s65，是的话将起点设置为x，并转至s65；
93.s65、向txbus发送恢复命令消息(带恢复批次id)；转至s66；
94.s66、从起点开始扫描errorbus中该账户的消息；转至s67；
95.s67、判断是否是成功消息？否的话转至s68；是的话判断恢复批次id匹配？匹配的话结束处理，不匹配的话转至s70；
96.s68、给消息打上回流标记，带上恢复批次id、errorbusoffset、原始txbusoffset；转至s69；
97.s69、将消息转发至txbus；转至s70；
98.s70、等待下一条消息，转至s67。
99.以上描述仅为本技术的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本技术中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本技术中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。