一种采用无锁方式的订单管理系统和方法与流程

1.本技术涉及订单管理系统，特别是一种采用无锁方式的订单管理系统和方法。


背景技术：

2.代客订单管理系统是一种通过接入来自不同渠道的订单并对所述订单进行集中处理的系统。随着业务的不断发展，所述代客订单管理系统需要处理的订单数量也越来越大、频率越来越高。
3.一般对订单的处理有两个基本要求：1)高效，以及2)同一个订单消息的处理应该保证是顺序的。
4.目前的代客订单管理系统主要采用下述两种传统方案：
5.方案一(单线程)：如图1所示，将订单的各类消息放到统一的一个队列内，由独立的单线程处理以保证顺序，并通过诸如oracle等关系型数据库(db)进行实时订单数据持久化存储。
6.方案二(多线程)：如图2所示，将订单的各类消息放到包含多个线程的线程池内处理，通过给每笔订单按订单号加锁来保障状态一致性以及最小化锁的范围，并通过诸如oracle等关系型数据库进行实时订单数据持久化存储。
7.但上述两种方案都存在各自的缺陷，例如：
8.方案一：
9.单线程的缺点：所有订单消息直接放进一个队列，由独立的单线程来处理。虽然这样保障了订单的次序，并且异步在一定程度上提高了订单处理效率。但是，当订单数量巨大，频率很高时，单线程处理无法发挥系统的所有性能，处理的订单量有限。
10.持久化的缺点：将订单的变动直接持久化到数据聚db，复杂的订单持久化耗时会比较长，这样会影响当前业务线程处理的效率。
11.方案二：
12.线程池的缺点：所有订单消息直接交给一个不固定并且会自动释放闲置线程的线程池处理，在系统处理快以及订单操作不频繁时不会有任务问题，但是一旦对订单进行多次快速操作，可能同时就会对同一订单进行不同的操作，这样无法保障原子性。
13.持久化的缺点：将订单的变动直接持久化到数据库db，复杂的订单持久化耗时会比较长，这样会影响当前业务线程处理的效率。
14.由此可见，现有的代客订单管理系统都无法很好地处理大量、高频的订单业务情况，因此，存在一种需求希望能够提供一种高效、快捷的订单管理系统以克服现有技术的这些缺陷。


技术实现要素：

15.本技术涉及一种采用无锁方式的订单管理系统和方法。
16.根据本技术的第一方面，提供了一种订单管理系统，包括：
17.数据接入模块，被配置为接收来自不同渠道的业务订单，并且将所述业务订单的处理结果返回给所述业务订单的发起者；
18.线程池模块，包括多个线程，每个线程配备有相应的消息队列，所述消息队列用于存放和处理放入其中的所述业务订单的消息；
19.数据处理模块，被配置为根据所述业务订单的订单id号生成对应的哈希代码，并通过将所述哈希代码与线程池中的线程数量取模来从所述线程池模块中选择用于处理所述业务订单的所述消息的线程，并将所述业务订单的所述消息放入所选的线程所配备的消息队列中；
20.消息处理器，被配置用于处理所述业务订单的所述消息；以及
21.数据持久化模块，被配置用于将消息的数据持久化保存到数据库中，或从所述数据库中查询和读取所保存的数据。
22.根据本技术的第二方面，提供了一种一种订单管理方法，包括：7.一种订单管理方法，包括：
23.a)启动订单管理系统以进行初始化；
24.b)接收来自不同渠道的业务订单；
25.c)根据所述业务订单的订单id号生成对应的哈希代码，并将所述哈希代码与线程池中的线程数量取模来从线程池中选择用于处理所述业务订单的消息的线程，并将所述业务订单的消息放入所选的线程所负责的消息队列中；
26.d)根据消息队列中所述消息的消息类型，选择与所述消息类型相对应的消息处理器处理所述消息；
27.e)将所述消息的处理数据缓存到内存的集合中，再异步持久存储到数据库中；
28.f)将所述处理数据返回给该业务订单的发起者；以及
29.g)判断在所述消息队列中是否还存在其他消息，
30.如果存在，则返回到步骤d以执行对下一个消息的处理；
31.如果不存在，则所述线程等待新的业务消息进入所述消息队列。
32.提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。
附图说明
33.为了描述可获得本发明的上述和其它优点和特征的方式，将通过参考附图中示出的本发明的具体实施例来呈现以上简要描述的本发明的更具体描述。可以理解，这些附图只描绘了本发明的各典型实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释本发明，在附图中：
34.图1示出了一种现有的单线程的订单管理系统的示意图。
35.图2示出了一种现有的多线程的订单管理系统的示意图。
36.图3示出了根据本技术的一个实施例的一种采用无锁方式的订单管理系统的示例结构图。
37.图4示出了根据本技术的一个实施例的一种采用无锁方式的订单管理方法的示例
流程图。
具体实施方式
38.针对现有技术中存在的所述缺陷和问题，在构思本技术的订单管理系统时，引入了一种新的设计思路，所述设计思路主要考虑了下述几点改进：
39.1)系统启动时给线程池预分配好固定线程并且每个线程配备队列。
40.2)每笔业务订单(例如询价单/回价/订单/交易)等数据都会按它的订单id号生成hashcode(哈希代码)，通过hashcode％threadsizeinpool这种取模方式来决定由哪个线程处理，然后将数据放进此线程负责的消息队列中。
41.3)线程监控队列中是否有消息，若有则根据消息类型调用指定的类型的消息处理器来处理消息。
42.4)因为一笔业务订单对应的所有业务消息数据拥有同一个订单id，这样就可以保障同一线程有序地处理这笔业务订单的所有数据，也不用考虑各种加锁保障一致性。
43.5)订单id是自增长并且唯一的，这保障了每个线程处理的业务订单数量都是均等的，可以有效发挥系统的并发性。
44.6)订单状态变动后直接更新到首层内存缓存中，多级缓存api会通过异步方式将订单状态一层层更新下去。
45.为了实现上述改进，本技术提供了一种采用无锁方式的订单管理系统。
46.在图3中公开了根据本技术的一个实施例的一种采用无锁方式的订单管理系统。
47.如图所示，所述订单管理系统包括下述几个模块：数据接入模块302、线程池模块304、数据处理模块306、消息处理器308以及数据持久化模块310。这些模块可由硬件、软件或其组合实现。并且所述订单管理系统的这些模块可以在同一设备中，也可以是分开的，彼此可通过有线或无线网络进行数据通信。所述网络包括电缆、数据线、wifi、蓝牙、蜂窝网络、局域网、广域网以及互联网等等。
48.其中，数据接入模块302，被配置为接收(接入)来自不同渠道的业务订单，并且将处理业务订单后的结果返回给该业务订单的发起者。
49.为此，所述数据接入模块302支持以各种协议方式接入外部数据。众所周知，由于例如金融系统和平台的复杂多样性，来自不同渠道的业务订单的数据协议可能彼此不同，因此，为了满足接入要求，所述数据接入模块302内置了各种数据协议以满足数据的接入和返回需求。例如，所述数据接入模块302支持下述几种常见的协议：
50.a)支持rest http方式接入询价单，撤销询价单，下订单等操作，再通过websocket方式将回价，撤销反馈，成交交易等结果返回给发起者。
51.b)支持fix api通用协议接入询价单，撤销询价单，下订单等操作，再通过fix api将回价，撤销摊销，成交交易等结果返回给发起者。
52.c)支持netty api加密方式接入询价单，撤销询价单，下订单等操作，再通过netty api将回价，撤销摊销，成交交易等结果返回给发起者；等等。
53.所述这些数据协议可以通过将相应的例如fix api、netty api、http api、dubbo api、kafka接入等协议统一封装在述数据接入模块302中来实现，在此不再详述。而且，所述这些例举的协议仅仅是出于说明的目的，而不是仅局限于这些协议，其他协议也一样适用
于本技术的方案，在此不再累述。
54.线程池模块304，包括多个线程。每个线程配备有相应的队列，用于存放和处理放入其中的消息。并且，线程池模块304中的各线程实时监控其队列中是否有消息，若有则根据消息类型将其转发至消息处理器308的指定的类型的消息处理器来处理消息。
55.数据处理模块306，被配置为根据与消息相关联的订单id号生成对应的哈希代码，并将所述哈希代码与线程池中的线程数量取模(也即hashcode％threadsizeinpool)来确定由线程池模块304中的哪个线程处理该消息，随后将该消息放入此线程负责的消息队列中以供进一步的处理。由于来自同一个订单的消息具有相同的订单id，因此，这种机制保障了同一线程有序地处理这笔业务订单的所有消息数据，无需再添加锁以保持一致性。
56.消息处理器308，被配置用于处理指定类型的消息。一个订单可以包含多个订单消息，而每个订单消息可以具有不同的类型。而不同类型的消息需要与该类型相对应的消息处理器来进行相应的处理。因此，消息处理器308实际上包含了多个分别处理不同类型的消息的消息处理器。如图所示，示例的不同消息类型包括：
57.r:request消息；
58.s:回价消息；
59.aj:拒绝询价消息；d:下单消息；
60.bn:下单反馈消息；以及
61.8:成交或者拒绝消息。
62.所述不同的消息处理器只会处理与其对应类型的消息。另外，应该理解，所述消息类型仅仅是出于示例说明的目的示出，并非要将能处理的消息类型局限于此。不同的订单可能还有其他类型的消息，这些消息类型也属于本技术的保护范畴。
63.数据持久化模块310，主要被配置用于将数据持久化保存到数据库(db，例如oracle数据库)中，或从数据库查询和读取所保存的数据。但与传统的将订单的变动直接持久化到数据库的方案相比，所述数据持久化模块310具有下述特点：
64.a)通过封装接口，达到每一级持久层都有统一的处理接口，例如包括：初始化方法，持久化方法，反向恢复方法，释放资源方法；
65.b)持久化：系统在做数据更新时只需要操作最顶层入口，数据通过异步方式逐步下沉，只要有一层失败则反向回退。这样就可以提升业务线程处理订单的效率
66.c)数据恢复：系统在服务发生切换后，在最顶层若无法找到相关数据则会逐步通过向下一层查询，直到查询到为止，然后反向向上层层恢复。
67.举例而言，数据持久化模块310接口的主方法可以包括adddata以及getdata；
68.持久化层的顶层为内存持久：
69.在该层中，adddata方法将数据缓存到集合中；缓存成功之后再继续提交给下一层。
70.在该层中，getdata方法是从缓存中查找数据，如果缓存中没有则从下一层查找数据然后恢复到内存中。
71.持久化层的底层为db(数据库)持久：
72.在该层中，adddata方法是将数据持久到db中；
73.在该层中，getdata方法是从db查询数据返回给上一层。
74.下面，通过引入具体的示例性代码来进一步说明如何实现本方案的数据持久使用的各方法：
75.76.[0077][0078]
如前所述，通过将数据持久存储进行分层逐级处理，可以提升业务线程处理订单的效率。例如，可以先在内存持久层的缓存中查询是否存在想要的业务数据，从而减轻了数据库的查询负担，特别是在处理复杂的订单的持久化时，可以利用缓存先保存到集合中，避免了将订单的变动全部直接持久化到数据库db中，从而显著提升了数据库的效率。
[0079]
在了解了本技术的采用无锁方式的订单管理系统的基本架构之后，下面结合图4来描述下根据本技术的一个实施例的一种采用无锁方式的订单管理方法的示例流程。
[0080]
如图所示，在步骤402，启动订单管理系统以进行初始化。所述初始化操作可以包括给线程池预分配好各个线程并且为每个线程配备一个对应的消息队列，以及对数据持久进行初始化。
[0081]
在完成系统初始化后，系统开始正常工作。
[0082]
在步骤404，接收来自不同渠道(客户)的业务订单。所述业务订单可能涉及多个消息。
[0083]
在步骤406，根据所述业务订单的订单id号生成对应的哈希代码，并将所述哈希代码与线程池中的线程数量取模(也即hashcode％threadsizeinpool)来从线程池中选择用于处理该业务订单的消息的线程，并将该业务订单的消息放入所选的线程所负责的消息队
列中。如前所述，由于属于同一业务订单的所有消息具有相同的订单id号，因此，上述取模后的结果也是相同的，因此，该业务订单的所有消息都会分配给同一个线程的消息队列。这种机制保障了同一线程有序地处理这笔业务订单的所有消息数据，无需再添加锁以保持一致性。
[0084]
在步骤408，根据消息队列中所述消息的消息类型，选择与消息类型相对应的消息处理器处理所述消息。
[0085]
在步骤410，将消息的处理数据先缓存到内存的集合中，再异步持久存储到数据库中。
[0086]
在步骤412，将该业务订单的处理数据(结果)返回给该业务订单的发起者。
[0087]
在步骤414，判断消息队列中是否还存在其他消息。如果存在，则返回到步骤408执行对下一个消息的处理。如果没有，至此，这个业务消息的处理流程结束，进入步骤416。
[0088]
在步骤416，线程等待新业务消息进入消息队列。
[0089]
如前所述，通过分两步将业务订单的各消息的数据先在内存缓存集中起来，随后再异步持久存储到数据库中，使得数据库的存储效率得到大大提升。
[0090]
虽然以上描述了不同的实施例，但应当理解的是它们只是作为示例而非限制。(诸)相关领域的技术人员将领会，在不偏离如所附权利要求书所定义的本发明的精神和范围的情况下，可以在形式和细节方面进行各种修改。因此，此处所公开的本发明的宽度和范围不应被上述所公开的示例性实施例所限制，而应当仅根据所附权利要求书及其等同替换来定义。