CN110868395B - 一种基于收发单框架的大并发业务处理方法、设备及介质 - Google Patents
一种基于收发单框架的大并发业务处理方法、设备及介质 Download PDFInfo
- Publication number
- CN110868395B CN110868395B CN201910910668.2A CN201910910668A CN110868395B CN 110868395 B CN110868395 B CN 110868395B CN 201910910668 A CN201910910668 A CN 201910910668A CN 110868395 B CN110868395 B CN 110868395B
- Authority
- CN
- China
- Prior art keywords
- order
- time
- processing
- effective
- orders
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/567—Integrating service provisioning from a plurality of service providers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明提供一种基于收发单框架的大并发业务处理方法,包括:1、配置发单间隔时间和开始时刻、发单数量和订单有效时间;2、订单提交方提交订单给收单端;3、收单端收到订单后,校验其合法性;4、发单端判断当前时刻是否需要提取订单,否则不处理;是则发单端从数据库中找出有效的订单,根据发单数量提取有效的订单并发送;5、业务处理端收到有效的订单后进行订单业务逻辑处理,再将订单状态插入到订单回调表中;6、定时从订单回调表中提取订单状态返回给订单提交方。本发明还提供一种计算机设备和一种计算机可读存储介质,通过收、发单端的协调配合在保证系统运行稳定的同时最大限度的处理尽可能多的订单。
Description
技术领域
本发明涉及一种业务处理方法,尤其涉及一种基于收发单框架的大并发业务处理方法、设备及介质。
背景技术
随着IT行业业务的不断扩大,后端服务程序也面临着诸多问题,在业务高峰期如何在保证生产系统能够稳定运行的同时又能应对短时间的流量洪峰成了急需解决的问题。
对于上述的问题,大多数企业通常在技术层面上对系统进行优化以满足业务并发,如在操作系统的选择上基本是选用安全、稳定的linux操作系统,在程序方面使用效率更高、支持更多并发连接的epoll技术、在数据库方面选用支持大数据操作的oracle、在系统集成方面协调各个模块以满足系统能随时进行扩容等。
现有的技术主要缺陷在于意识形态认知方面,传统模式是接收到一条订单就创建一个进程或者线程开始处理业务,主线程返回继续接单,如图1所示。来多少订单处理多少订单,能处理过来万事大吉,处理来不及可能就系统卡顿或者宕机。现有的技术方案在技术上进行优化的空间已经显得捉襟见肘,业务高峰期订单剧增同时也伴随着系统运行缓慢,如果系统还有跟外围系统对接有可能外围系统处理也变慢,那么对自有系统更是雪上加霜,因此,本发明就结合技术上的改进以及业务逻辑上的分析故提出了增加收、发单端的方法。
在2018年12月04日申请的申请号为2018114750073的中国发明,该发明公开了一种基于Linux内核的epoll大并发数据通信接系统,所述基于Linux内核的epoll大并发数据通信接系统包括设备层、通信层和核心处理层。以解决现有技术处理大量并发数据易阻塞的问题。该发明主要在技术层面上对业务大并发情况下进行技术优化改进,但是在业务高峰期时仅在程序效率上的精益求精往往不够,此时的数据库负载、操作系统的压力都很大,常常会出现系统整体处理速度变慢甚至无法正常处理业务。而本发明除了在技术上追求高效率的同时在业务流程方面独创性的增加了收单端用于控制业务流量,一个业务请求所消耗的时间往往在后端业务逻辑处理上,故若后端的业务逻辑处理跟不上,前置并发再大也无济于事,该流程的改进不仅能够保证业务高峰期系统的稳定运行同时也起到限流、截流的作用。
发明内容
本发明要解决的技术问题之一,在于提供一种基于收发单框架的大并发业务处理方法,本发明在前端增加了一个收单端主要用于接收订单入库但是不处理,然后等待发单端智能调度,一个业务的完整执行所消耗的时间主要是在业务逻辑处理、数据库交互以及第三方外部系统响应方面,通过收单端与发单端的协调配合在保证系统运行稳定的同时最大限度的处理尽可能多的订单。
本发明的问题之一,是这样实现的:
一种基于收发单框架的大并发业务处理方法,包括如下步骤:
步骤1、根据系统运行状况配置发单间隔时间和开始时刻、每次提取的订单数量和订单有效时间;
步骤2、订单提交方提交复数个订单给收单端;
步骤3、收单端收到该订单后,对每个订单的合法性进行校验,若校验的结果为合法,则将合法的订单存入到数据库中并记录订单入库时间;若校验的结果为非法,则不存入数据库中;同时,将校验的结果响应给订单提交方;
步骤4、发单端实时根据发单间隔时间和开始时刻判断当前时刻是否需要提取订单,若否,则不做任何处理;若是,则发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出有效的订单,再根据每次提取的订单数量定时提取出对应数量的有效的订单,并发送到业务处理端;
步骤5、业务处理端接收到有效的订单后,对该有效的订单进行订单业务逻辑处理,处理完成后将订单状态组织成报文插入到订单回调表中;
步骤6、定时从订单回调表中提取订单状态返回给订单提交方,若订单提交方作出响应,则说明通知成功,若未响应,则说明通知失败,至少重发一次订单状态给订单提交方。
进一步地,所述步骤6之后还包括:
步骤7、发单端实时统计业务处理端处理一批订单所需消耗的时间和统计第三方外部系统响应的平均时间,并根据统计的结果对发单间隔时间和开始时刻及每次提取的订单数量进行调整。
进一步地,所述步骤4之后还包括:
步骤41、发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出超时失效的订单,对于超时失效的订单不予处理并异步下发回调通知给订单提交方。
进一步地,所述步骤5中对该有效的订单进行订单业务逻辑处理,若处理过程中需要采用第三方外部系统,则直接调用第三方外部系统的调用接口对该有效的订单进行订单业务逻辑处理。
进一步地,所述步骤4的再根据每次提取的订单数量提取出对应数量的有效的订单,并发送到业务处理端中,所述有效的订单是通过http请求发送到业务处理端。
进一步地,所述步骤6具体为:定时从订单回调表中提取订单状态,并通过http请求返回给订单提交方。
进一步地,所述步骤2具体为:收单端采用epoll的IO多路复用技术,通过复数个线程与订单提交方进行并发连接,订单提交方通过复数个线程提交复数个订单给收单端,收单端通过复数个线程接收复数个订单。
本发明要解决的技术问题之二,在于提供一种计算机设备。
本发明的问题之二,是这样实现的:
一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上述中任一项所述的一种基于收发单框架的大并发业务处理方法。
本发明要解决的技术问题之三,在于提供一种计算机可读存储介质。
本发明的问题之三,是这样实现的:
一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述中任一项所述的一种基于收发单框架的大并发业务处理方法。
本发明的优点在于:
1、前端增加收单端来接收大并发的订单并存储于数据库中暂不处理,用于等待后端发单端智能调度后处理;
2、发单端根据业务处理速度灵活控制发单间隔时间和开始时刻及每次提取的订单数量(发单数量);
3、本发明在业务流程上对业务高峰期时流量的控制,将所有订单通过收单端存入数据库中,然后由发单端根据流量情况控制发单间隔时间和发单数量,使得在业务高峰期间系统整体运行不再出现异常、系统能够结合业务受理端处理的速度以及第三方外部系统的响应情况适时调整发单间隔时间以及发单数量保证在现有硬件资源前提下保证系统稳定运行,同时可根据用户的不同需求调整订单处理的策略以满足高实时性或者高成功率。
附图说明
下面参照附图结合实施例对本发明作进一步的说明。
图1为现有技术的执行流程图。
图2为本发明一种基于收发单框架的大并发业务处理方法的执行流程图。
图3为本发明一种基于收发单框架的大并发业务处理方法的交互过程图。
图4为本发明中收单端的执行流程图。
图5为本发明中发单端与业务受理端的执行流程图。
具体实施方式
为使得本发明更明显易懂,现以一优选实施例,并配合附图作详细说明如下。
如图2至图5所示,本发明的一种基于收发单框架的大并发业务处理方法,包括如下步骤:
步骤1、根据系统运行状况配置发单间隔时间和开始时刻、每次提取的订单数量和订单有效时间;
步骤2、订单提交方提交复数个订单给收单端;具体为:收单端采用epoll的IO多路复用技术,通过复数个线程与订单提交方进行并发连接,订单提交方通过复数个线程提交复数个订单给收单端,收单端通过复数个线程接收复数个订单;
步骤3、收单端收到该订单后,对每个订单的合法性进行校验,若校验的结果为合法,则将合法的订单存入到数据库中并记录订单入库时间;若校验的结果为非法,则不存入数据库中;同时,将校验的结果响应给订单提交方,若订单合法,则响应订单提交方“订单提交成功,等待订单受理”,若订单非法,则响应订单提交方“订单提交失败,订单未受理”;由于该步骤只是将订单存入数据库中,并没有直接做订单业务逻辑处理,故该步骤消耗时间可忽略不计,订单入库后等待发单端的调度;
步骤4、发单端实时根据发单间隔时间和开始时刻判断当前时刻是否需要提取订单,若否,则不做任何处理;若是,则发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出有效的订单,再根据每次提取的订单数量定时从数据库中提取出对应数量的有效的订单,并通过http请求发送到业务处理端;发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出超时失效的订单,对于超时失效的订单不予处理并异步下发回调通知给订单提交方;该步骤主要功能就是发送订单,核心功能就是完成业务处理端的智能调度;
步骤5、业务处理端接收到有效的订单后,马上响应发单端,之后才对该有效的订单进行订单业务逻辑处理,如扣款、业务校验、数据库交互等,若处理过程中需要采用第三方外部系统,则直接调用第三方外部系统的调用接口对该有效的订单进行订单业务逻辑处理,相比其他环节耗时更多;订单处理完成后将订单状态(订单办理成功、订单办理失败)等相关信息组织成报文插入到订单回调表中,等待回调;
步骤6、定时从订单回调表中提取订单状态,并通过http请求返回给订单提交方,若订单提交方作出响应,则说明通知成功,若未响应,则说明通知失败,至少重发一次订单状态给订单提交方,从而完成一笔订单的生命周期;
步骤7、发单端实时统计业务处理端处理一批订单所需消耗的时间和统计第三方外部系统响应的平均时间,并根据统计的结果对发单间隔时间和开始时刻及每次提取的订单数量进行调整。
本发明的一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如下步骤:
步骤1、根据系统运行状况配置发单间隔时间和开始时刻、每次提取的订单数量和订单有效时间;
步骤2、订单提交方提交复数个订单给收单端;具体为:收单端采用epoll的IO多路复用技术,通过复数个线程与订单提交方进行并发连接,订单提交方通过复数个线程提交复数个订单给收单端,收单端通过复数个线程接收复数个订单;
步骤3、收单端收到该订单后,对每个订单的合法性进行校验,若校验的结果为合法,则将合法的订单存入到数据库中并记录订单入库时间;若校验的结果为非法,则不存入数据库中;同时,将校验的结果响应给订单提交方,若订单合法,则响应订单提交方“订单提交成功,等待订单受理”,若订单非法,则响应订单提交方“订单提交失败,订单未受理”;由于该步骤只是将订单存入数据库中,并没有直接做订单业务逻辑处理,故该步骤消耗时间可忽略不计,订单入库后等待发单端的调度;
步骤4、发单端实时根据发单间隔时间和开始时刻判断当前时刻是否需要提取订单,若否,则不做任何处理;若是,则发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出有效的订单,再根据每次提取的订单数量定时从数据库中提取出对应数量的有效的订单,并通过http请求发送到业务处理端;发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出超时失效的订单,对于超时失效的订单不予处理并异步下发回调通知给订单提交方;该步骤主要功能就是发送订单,核心功能就是完成业务处理端的智能调度;
步骤5、业务处理端接收到有效的订单后,马上响应发单端,之后才对该有效的订单进行订单业务逻辑处理,如扣款、业务校验、数据库交互等,若处理过程中需要采用第三方外部系统,则直接调用第三方外部系统的调用接口对该有效的订单进行订单业务逻辑处理,相比其他环节耗时更多;订单处理完成后将订单状态(订单办理成功、订单办理失败)等相关信息组织成报文插入到订单回调表中,等待回调;
步骤6、定时从订单回调表中提取订单状态,并通过http请求返回给订单提交方,若订单提交方作出响应,则说明通知成功,若未响应,则说明通知失败,至少重发一次订单状态给订单提交方,从而完成一笔订单的生命周期;
步骤7、发单端实时统计业务处理端处理一批订单所需消耗的时间和统计第三方外部系统响应的平均时间,并根据统计的结果对发单间隔时间和开始时刻及每次提取的订单数量进行调整。
本发明的一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如下步骤:
步骤1、根据系统运行状况配置发单间隔时间和开始时刻、每次提取的订单数量和订单有效时间;
步骤2、订单提交方提交复数个订单给收单端;具体为:收单端采用epoll的IO多路复用技术,通过复数个线程与订单提交方进行并发连接,订单提交方通过复数个线程提交复数个订单给收单端,收单端通过复数个线程接收复数个订单;
步骤3、收单端收到该订单后,对每个订单的合法性进行校验,若校验的结果为合法,则将合法的订单存入到数据库中并记录订单入库时间;若校验的结果为非法,则不存入数据库中;同时,将校验的结果响应给订单提交方,若订单合法,则响应订单提交方“订单提交成功,等待订单受理”,若订单非法,则响应订单提交方“订单提交失败,订单未受理”;由于该步骤只是将订单存入数据库中,并没有直接做订单业务逻辑处理,故该步骤消耗时间可忽略不计,订单入库后等待发单端的调度;
步骤4、发单端实时根据发单间隔时间和开始时刻判断当前时刻是否需要提取订单,若否,则不做任何处理;若是,则发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出有效的订单,再根据每次提取的订单数量定时从数据库中提取出对应数量的有效的订单,并通过http请求发送到业务处理端;发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出超时失效的订单,对于超时失效的订单不予处理并异步下发回调通知给订单提交方;该步骤主要功能就是发送订单,核心功能就是完成业务处理端的智能调度;
步骤5、业务处理端接收到有效的订单后,马上响应发单端,之后才对该有效的订单进行订单业务逻辑处理,如扣款、业务校验、数据库交互等,若处理过程中需要采用第三方外部系统,则直接调用第三方外部系统的调用接口对该有效的订单进行订单业务逻辑处理,相比其他环节耗时更多;订单处理完成后将订单状态(订单办理成功、订单办理失败)等相关信息组织成报文插入到订单回调表中,等待回调;
步骤6、定时从订单回调表中提取订单状态,并通过http请求返回给订单提交方,若订单提交方作出响应,则说明通知成功,若未响应,则说明通知失败,至少重发一次订单状态给订单提交方,从而完成一笔订单的生命周期;
步骤7、发单端实时统计业务处理端处理一批订单所需消耗的时间和统计第三方外部系统响应的平均时间,并根据统计的结果对发单间隔时间和开始时刻及每次提取的订单数量进行调整。
1、收单端:收单端是基于epoll的IO多路复用技术,可支持上万个并发连接,收单端对订单进行简单的合法性判断后即入库并同步响应,在网络正常的情况下该交互消耗的时间极短。订单入库后数据库存有该订单入库的时间以及订单的完整信息,订单入库时间用于后续发单端智能调度的判断依据,收单端不涉及业务逻辑处理可以弹性扩容、可部署多套应用。
2、发单端:发单端根据发单间隔时间从数据库中捞取订单发往后端业务受理端进行业务办理,发单端在多个方面判断可以实现智能调度的目的;
I:发单间隔时间和开始时刻可配置;
II:每次提取的订单数量可配置;
III:订单有效时间可配置(用于入库时间的时效性判断)。
发单端可实时统计后端业务处理一批订单消耗的时间、统计第三方外部系统响应的平均时间,以此为依据对发单间隔时间、发单数量进行调整,如果后端业务处理的速度变慢有可能是本地的数据库负载过高sql执行变慢、cpu占用率过高程序运行变慢或者是第三方外部系统响应变慢,那么适当加大发单间隔时间或者减少单次发单数量,反之则缩短发单间隔时间或者加大单次发单数量。同时,系统设置有订单有效时间根据订单的入库时间与有效时间做比较,对于超时失效的订单不予处理并异步下发回调通知“业务繁忙请稍后再试”,如:当前时刻为14:30,订单有效时间为10分,则订单入库时间在14:20之前的订单为超时失效的订单,订单入库时间在14:20~14:30的订单为有效的订单;订单有效时间也可以灵活修改,对于实时响应要求较高的用户可缩短订单有效时间及时返回用户订单处理结果,对于实时响应要求不高但是对成功率要求更高的用户可适当加长订单有效时间以保证订单尽可能得到成功处理,发单端对于牺牲成功率获得更高实时性或者降低实时性获取更高成功率的需求都满足。
3、业务受理端:业务受理端是业务逻辑处理中心也是消耗时间最大的一个环节,业务处理环节还负责与第三方外部系统对接,由于第三方外部系统的不确定,增加了一条订单处理完成消耗时间的不确定性,且逻辑部分常与数据库交互受到数据库负载的影响,所以业务受理端是整个系统不确定因素最高的一个环节,本发明在该环节前面分别加了收单端和发单端,把不确定因素转变为确定因素,极大的增加了人为对系统的可控制性,在网络不稳定、系统cpu占用率高、第三方外部系统响应迟缓的情况下可减少订单的处理或者丢弃部分订单以保证系统在有限资源情况下处理部分订单、对于无法受理的订单我们也可以很友好的返回“系统繁忙请稍后再试”,大大增强了用户的体验。
虽然以上描述了本发明的具体实施方式,但是熟悉本技术领域的技术人员应当理解,我们所描述的具体的实施例只是说明性的,而不是用于对本发明的范围的限定,熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化,都应当涵盖在本发明的权利要求所保护的范围内。
Claims (9)
1.一种基于收发单框架的大并发业务处理方法,其特征在于:包括如下步骤:
步骤1、根据系统运行状况配置发单间隔时间和开始时刻、每次提取的订单数量和订单有效时间;
步骤2、订单提交方提交复数个订单给收单端;
步骤3、收单端收到该订单后,对每个订单的合法性进行校验,若校验的结果为合法,则将合法的订单存入到数据库中并记录订单入库时间;若校验的结果为非法,则不存入数据库中;同时,将校验的结果响应给订单提交方;
步骤4、发单端实时根据发单间隔时间和开始时刻判断当前时刻是否需要提取订单,若否,则不做任何处理;若是,则发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出有效的订单,再根据每次提取的订单数量定时提取出对应数量的有效的订单,并发送到业务处理端;
步骤5、业务处理端接收到有效的订单后,对该有效的订单进行订单业务逻辑处理,处理完成后将订单状态组织成报文插入到订单回调表中;
步骤6、定时从订单回调表中提取订单状态返回给订单提交方,若订单提交方作出响应,则说明通知成功,若未响应,则说明通知失败,至少重发一次订单状态给订单提交方。
2.如权利要求1所述的一种基于收发单框架的大并发业务处理方法,其特征在于:所述步骤6之后还包括:
步骤7、发单端实时统计业务处理端处理一批订单所需消耗的时间和统计第三方外部系统响应的平均时间,并根据统计的结果对发单间隔时间和开始时刻及每次提取的订单数量进行调整。
3.如权利要求1所述的一种基于收发单框架的大并发业务处理方法,其特征在于:所述步骤4之后还包括:
步骤41、发单端根据当前时刻、订单有效时间和订单入库时间从数据库中找出超时失效的订单,对于超时失效的订单不予处理并异步下发回调通知给订单提交方。
4.如权利要求1所述的一种基于收发单框架的大并发业务处理方法,其特征在于:所述步骤5中对该有效的订单进行订单业务逻辑处理,若处理过程中需要采用第三方外部系统,则直接调用第三方外部系统的调用接口对该有效的订单进行订单业务逻辑处理。
5.如权利要求1所述的一种基于收发单框架的大并发业务处理方法,其特征在于:所述步骤4的再根据每次提取的订单数量提取出对应数量的有效的订单,并发送到业务处理端中,所述有效的订单是通过http请求发送到业务处理端。
6.如权利要求1所述的一种基于收发单框架的大并发业务处理方法,其特征在于:所述步骤6具体为:定时从订单回调表中提取订单状态,并通过http请求返回给订单提交方。
7.如权利要求1所述的一种基于收发单框架的大并发业务处理方法,其特征在于:所述步骤2具体为:收单端采用epoll的IO多路复用技术,通过复数个线程与订单提交方进行并发连接,订单提交方通过复数个线程提交复数个订单给收单端,收单端通过复数个线程接收复数个订单。
8.一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现如权利要求1-6中任一项所述的一种基于收发单框架的大并发业务处理方法。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求1-6中任一项所述的一种基于收发单框架的大并发业务处理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910910668.2A CN110868395B (zh) | 2019-09-25 | 2019-09-25 | 一种基于收发单框架的大并发业务处理方法、设备及介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910910668.2A CN110868395B (zh) | 2019-09-25 | 2019-09-25 | 一种基于收发单框架的大并发业务处理方法、设备及介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110868395A CN110868395A (zh) | 2020-03-06 |
CN110868395B true CN110868395B (zh) | 2021-09-07 |
Family
ID=69652193
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910910668.2A Active CN110868395B (zh) | 2019-09-25 | 2019-09-25 | 一种基于收发单框架的大并发业务处理方法、设备及介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110868395B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112905335B (zh) * | 2021-02-02 | 2023-11-10 | 北京思特奇信息技术股份有限公司 | 调用多套系统相同服务的切换方法及业务处理系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102255735A (zh) * | 2011-07-05 | 2011-11-23 | 青岛海信传媒网络技术有限公司 | 一种订单的处理方法及装置 |
CN107767236A (zh) * | 2017-11-14 | 2018-03-06 | 北京小度信息科技有限公司 | 一种订单推送方法、装置、服务器和计算机可读存储介质 |
CN109583980A (zh) * | 2017-09-28 | 2019-04-05 | 中国移动通信集团浙江有限公司 | 订单处理的方法、系统、电子设备和存储介质 |
CN110083653A (zh) * | 2019-04-29 | 2019-08-02 | 广州虎牙信息科技有限公司 | 一种订单数据的操作方法、装置、计算机设备和存储介质 |
CN110135925A (zh) * | 2018-02-08 | 2019-08-16 | 北京京东尚科信息技术有限公司 | 订单处理系统、方法和装置 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9639885B2 (en) * | 2012-12-31 | 2017-05-02 | T-Mobile Usa, Inc. | Recovery of e-commerce orders |
-
2019
- 2019-09-25 CN CN201910910668.2A patent/CN110868395B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102255735A (zh) * | 2011-07-05 | 2011-11-23 | 青岛海信传媒网络技术有限公司 | 一种订单的处理方法及装置 |
CN109583980A (zh) * | 2017-09-28 | 2019-04-05 | 中国移动通信集团浙江有限公司 | 订单处理的方法、系统、电子设备和存储介质 |
CN107767236A (zh) * | 2017-11-14 | 2018-03-06 | 北京小度信息科技有限公司 | 一种订单推送方法、装置、服务器和计算机可读存储介质 |
CN110135925A (zh) * | 2018-02-08 | 2019-08-16 | 北京京东尚科信息技术有限公司 | 订单处理系统、方法和装置 |
CN110083653A (zh) * | 2019-04-29 | 2019-08-02 | 广州虎牙信息科技有限公司 | 一种订单数据的操作方法、装置、计算机设备和存储介质 |
Non-Patent Citations (2)
Title |
---|
单元物料订单分拣轮询控制系统研究;冉文学;《中国博士学位论文全文数据库信息科技辑》;20141115;全文 * |
跨境电商保税仓库拣货策略研究;王华东等;《计算机工程与应用》;20181120;全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN110868395A (zh) | 2020-03-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2014005535A1 (zh) | 物联网消息处理方法、装置及系统 | |
CN111459575B (zh) | 调用请求的处理方法、装置和计算机存储介质 | |
CN106843170A (zh) | 基于令牌的任务调度方法 | |
CN111078426A (zh) | 一种后端微服务架构下的高并发解决方法 | |
CN111813573B (zh) | 管理平台与机器人软件的通信方法及其相关设备 | |
CN114357495B (zh) | 基于区块链的预言机链下聚合方法、装置、设备和介质 | |
CN104899274A (zh) | 一种内存数据库高效远程访问方法 | |
CN102750368B (zh) | 一种数据库集群数据高速导入方法 | |
CN107341062A (zh) | 一种数据推送方法、装置、设备以及存储介质 | |
CN110868395B (zh) | 一种基于收发单框架的大并发业务处理方法、设备及介质 | |
CN101321089A (zh) | 一种电信网管系统中性能数据的入库方法 | |
CN103258389B (zh) | 自助终端上传文件的方法、系统和自助终端 | |
CN104408110A (zh) | 数据请求的方法、装置及系统 | |
CN111563124A (zh) | 基于区块链的作业处理方法、装置及系统 | |
CN103123575A (zh) | 一种数据写入方法 | |
CN102055606B (zh) | 一种业务支撑系统中的业务处理方法、系统及设备 | |
CN116821433A (zh) | 充电桩充电功率查询方法、装置、设备及介质 | |
CN111405037A (zh) | 区块同步方法、设备和存储介质 | |
CN107229424B (zh) | 一种分布式存储系统数据写入方法及分布式存储系统 | |
CN107122246B (zh) | 智能数值模拟作业管理与反馈方法 | |
CN103391257A (zh) | 一种报文存储、转发方法、装置及系统 | |
CN114328638A (zh) | 一种基于数据库轮询的业务消息推送系统 | |
CN114296831A (zh) | 区块链共识算法动态加载方法、装置、系统及存储介质 | |
CN104735097A (zh) | 信息的收集方法和系统 | |
CN116996450B (zh) | 一种管理数据处理方法、装置及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |