一种采用无锁方式的订单管理系统和方法技术方案

本申请涉及一种订单管理系统，包括：数据接入模块，被配置为接收来自不同渠道的业务订单，并且将所述业务订单的处理结果返回给所述业务订单的发起者；线程池模块，包括多个线程，每个线程配备有相应的消息队列；数据处理模块，被配置为根据所述业务订单的订单ID号生成对应的哈希代码，并通过将所述哈希代码与线程池中的线程数量取模来从所述线程池模块中选择用于处理所述业务订单的所述消息的线程，并将所述业务订单的所述消息放入所选的线程所配备的消息队列中；消息处理器，被配置用于处理所述业务订单的所述消息；以及数据持久化模块，被配置用于将消息的数据持久化保存到数据库中，或从所述数据库中查询和读取所保存的数据。据。据。

【技术实现步骤摘要】
一种采用无锁方式的订单管理系统和方法


[0001]本申请涉及订单管理系统，特别是一种采用无锁方式的订单管理系统和方法。

技术介绍

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

技术实现思路

[0015]本申请涉及一种采用无锁方式的订单管理系统和方法。
[0016]根据本申请的第一方面，提供了一种订单管理系统，包括：
[0017]数据接入模块，被配置为接收来自不同渠道的业务订单，并且将所述业务订单的处理结果返回给所述业务订单的发起者；
[0018]线程池模块，包括多个线程，每个线程配备有相应的消息队列，所述消息队列用于存放和处理放入其中的所述业务订单的消息；
[0019]数据处理模块，被配置为根据所述业务订单的订单ID号生成对应的哈希代码，并通过将所述哈希代码与线程池中的线程数量取模来从所述线程池模块中选择用于处理所述业务订单的所述消息的线程，并将所述业务订单的所述消息放入所选的线程所配备的消息队列中；
[0020]消息处理器，被配置用于处理所述业务订单的所述消息；以及
[0021]数据持久化模块，被配置用于将消息的数据持久化保存到数据库中，或从所述数据库中查询和读取所保存的数据。
[0022]根据本申请的第二方面，提供了一种一种订单管理方法，包括：7.一种订单管理方法，包括：
[0023]a)启动订单管理系统以进行初始化；
[0024]b)接收来自不同渠道的业务订单；
[0025]c)根据所述业务订单的订单ID号生成对应的哈希代码，并将所述哈希代码与线程池中的线程数量取模来从线程池中选择用于处理所述业务订单的消息的线程，并将所述业务订单的消息放入所选的线程所负责的消息队列中；
[0026]d)根据消息队列中所述消息的消息类型，选择与所述消息类型相对应的消息处理器处理所述消息；
[0027]e)将所述消息的处理数据缓存到内存的集合中，再异步持久存储到数据库中；
[0028]f)将所述处理数据返回给该业务订单的发起者；以及
[0029]g)判断在所述消息队列中是否还存在其他消息，
[0030]如果存在，则返回到步骤d以执行对下一个消息的处理；
[0031]如果不存在，则所述线程等待新的业务消息进入所述消息队列。
[0032]提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。
附图说明
[0033]为了描述可获得本专利技术的上述和其它优点和特征的方式，将通过参考附图中示出的本专利技术的具体实施例来呈现以上简要描述的本专利技术的更具体描述。可以理解，这些附图只描绘了本专利技术的各典型实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释本专利技术，在附图中：
[0034]图1示出了一种现有的单线程的订单管理系统的示意图。
[0035]图2示出了一种现有的多线程的订单管理系统的示意图。
[0036]图3示出了根据本申请的一个实施例的一种采用无锁方式的订单管理系统的示例结构图。
[0037]图4示出了根据本申请的一个实施例的一种采用无锁方式的订单管理方法的示例
流程图。
具体实施方式
[0038]针对现有技术中存在的所述缺陷和问题，在构思本申请的订单管理系统时，引入了一种新的设计思路，所述设计思路主要考虑了下述几点改进：
[0039]1)系统启动时给线程池预分配好固定线程并且每个线程配备队列。
[0040]2)每笔业务订单(例如询价单/回价/订单/交易)等数据都会按它的订单ID号生成hashCode(哈希代码)，通过hashCode％threadSizeInPool这种取模方式来决定由哪个线程处理，然后将数据放进此线程负责的消息队列中。
[0041]3)线程监控队列中是否有消息，若有则根据消息类型调用指定的类型的消息处理器来处理消息。
[0042]4)因为一笔业务订单对应的所有业务消息数据拥有同一个订单ID，这样就可以保障同一线程有序地处理这笔业务订单的所有数据，也不用考虑各种加锁保障一致性。
[0043]5)订单ID是自增长并且唯一的，这保障了每个线程处理的业务订单数量都是均等的，可以有效发挥系统的并发性。
[0044]6)订单状态变动后直接更新到首层内存缓存中，多级缓存API会通过异步方式将订单状态一层层更新下去。
[0045]为了实现上述改进，本申请提供了一种采用无锁方式的订单管理系统。
[0046]在图3中公开了根据本申请的一个实施例的一种采用无锁方式的订单管理系统。
[0047]如图所示，所述订单管理系统包括下述几个模块：数据接入模块302、线程池模块304、数据处理模块306、消息处理器3本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种订单管理系统，包括：数据接入模块，被配置为接收来自不同渠道的业务订单，并且将所述业务订单的处理结果返回给所述业务订单的发起者；线程池模块，包括多个线程，每个线程配备有相应的消息队列，所述消息队列用于存放和处理放入其中的所述业务订单的消息；数据处理模块，被配置为根据所述业务订单的订单ID号生成对应的哈希代码，并通过将所述哈希代码与线程池中的线程数量取模来从所述线程池模块中选择用于处理所述业务订单的所述消息的线程，并将所述业务订单的所述消息放入所选的线程所配备的消息队列中；消息处理器，被配置用于处理所述业务订单的所述消息；以及数据持久化模块，被配置用于将消息的数据持久化保存到数据库中，或从所述数据库中查询和读取所保存的数据。2.如权利要求1所述的订单管理系统，其特征在于，所述数据持久化模块进一步被配置为先将所述消息的处理数据缓存到内存的集合中，随后再异步持久存储到数据库中。3.如权利要求1所述的订单管理系统，其特征在于，所述数据持久化模块进一步被配置有统一的封装接口，包括：初始化方法，持久化方法，反向恢复方法，释放资源方法。4.如权利要求2所述的订单管理系统，其特征在于，所述数据持久化模块进一步被配置为在数据恢复时，先从所述内存的缓存中查找数据，如果找不到再从数据库中查找所述数据并将所述数据恢复到所述内存中。5.如权利要求1所述的订单管理系统，其特征在于，其中所述线程池模块中的各线程实时监控其消息队列中是否有消息，若有则根据消息类型将其转发至指定类型的消息处理器来处理消息。6.如权利要求1所述...

【专利技术属性】
技术研发人员：刘国强，朱志忠，赵星焱，汪宏斌，秦菀，
申请(专利权)人：上海中汇亿达金融信息技术有限公司，
类型：发明
国别省市：