CN110928746B

CN110928746B - 可调配的业务处理系统、方法、装置及可存储介质

Info

Publication number: CN110928746B
Application number: CN201911112572.8A
Authority: CN
Inventors: 裘力俊; 卢晓飞; 张元元; 蔡荣
Original assignee: Hangzhou Tiankuan Technology Co ltd
Current assignee: Hangzhou Tiankuan Technology Co ltd
Priority date: 2019-11-14
Filing date: 2019-11-14
Publication date: 2023-10-24
Anticipated expiration: 2039-11-14
Also published as: CN110928746A

Abstract

本申请公开了一种可调配的业务处理系统、方法、装置及可存储介质，包括：业务系统获取单元，用于获取业务办理请求，调用业务处理框架接口并将业务逻辑处理回调方法传递给业务处理框架单元；业务处理框架单元，用于在收到业务流后，根据配置调用业务系统回调方法对业务流进行相应处理；其中，所述业务处理框架单元包括：同步处理单元，对业务办理请求进行实时处理；异步处理单元，将业务办理请求存储至业务流中，根据实时的处理速度对业物流中的任务提取并进行处理在本申请实施例中，运维人员可以通过业务的实际办理情况分配系统资源，无需开发人员介入；当活动进入尾声或者业务办理量非常小时可以通过业务处理框架回收资源而无需调整代码逻辑。

Description

可调配的业务处理系统、方法、装置及可存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种可调配的业务处理系统、方法、装置及可存储介质。

背景技术

目前大多数业务系统在处理业务时都是采用同步处理机制。在一些特殊场景，如：充值、转账等业务时采用了异步处理机制。此类特殊业务由于流水量大，并且即时性不高，所以可以通过异步处理机制完成。业务处理模式在程序设计时就已经设定好，后续如需调整处理模式则需要调整代码。

现有技术的主要缺陷在于：

(1)同步处理即时性高，但是会严重消耗服务器资源。

(2)异步处理机制，虽然能够降低服务器资源的损耗，但是会影响用户的体验。当业务流水增大时，会大大的减缓业务处理效率。

(3)想调整业务处理模式需要修改代码。

发明内容

为了解决上述技术问题，本申请实施例提供一种可调配的业务处理系统、方法、装置及可存储介质。

本申请实施例第一方面提供了一种可调配的业务处理系统，可包括：

业务系统获取单元，用于获取业务办理请求，调用业务处理框架接口并将业务逻辑处理回调方法传递给业务处理框架单元；

业务处理框架单元，用于在收到业务流后，根据配置调用业务系统回调方法对业务流进行相应处理；

其中，所述业务处理框架单元包括：

同步处理单元，对业务办理请求进行实时处理；

异步处理单元，将业务办理请求存储至业务流中，根据实时的处理速度对业物流中的任务提取并进行处理。

进一步地，所述同步处理单元包括：

业务系统获取单元在收到用户办理请求后，将业务流以及业务处理回调方法传给业务处理框架单元；业务处理框架单元在收到业务流后，会调用业务系统的回调方法完成业务办理。

进一步地，所述异步处理单元包括：

存入阶段：业务系统获取单元收到用户办理请求后，将业务流以及业务处理回调方法传给业务处理框架单元；业务处理框架单元在收到业务流后，将业务流存入业务流队列；

读取阶段：处理线程循环处理业务流，从业务队列中获取业务流，调用业务系统的回调方法完成业务办理，办理完成后更新业务处理框架流水表中的处理状态。

进一步地，所述异步处理单元包括如下步骤：

业务系统调用业务处理框架，传递业务流数据及回调方法；

从redis存储形式的事务响应通道中根据业务流获取业务流配置信息、业务流队列；

将业务流数据保存到mysql中流水表中；

将业务流保存到对应的业务流队列中；

子线程有序读取业务流队列中业务流；

调用业务系统的回调方法处理业务；

将业务系统返回的操作结果更新到业务处理框架数据库流水表中。

进一步地，所述异步处理单元还包括：

补偿单元，获取异步处理业务时失败任务，预设重新处理尝试次数，在该次数范围内重试该任务。

进一步地，所述补偿单元包括：

查询mysql流水表中的失败记录，作为需要补偿的对象；

查询这些记录重试处理次数，若大于设置的重试处理次数则不再处理；

调用业务系统对应的处理接口重新处理失败数据；

处理成功：更新流水表；处理失败：更新重试次数。

本申请实施例第二方面提供了一种可调配的业务处理方法，包括：

创建业务流监听线程，获取业务办理请求，将业务形成业务流队列；

将数据库改成redis存储，作为事务响应通道，监听业务流处理设置是否发生改变；

不断获取设置内容，若无改动，按照预设内容分配系统资源；若改动，按照新的配置调整系统资源。

进一步地，当业务流监听线程监听到业务流处理设置发生改变时：

从redis存储中读取业务流对应的处理线程对象，并终止处理线程；根据配置重新创建处理线程。

第三方面，本申请实施例提供了一种处理装置，包括存储器和处理器，所述存储器上存储有计算机可执行指令，所述处理器运行所述存储器上的计算机可执行指令时实现第一方面的系统。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现上述第一方面的系统。

在本申请实施例中，运维人员可以通过业务的实际办理情况分配系统资源，无需开发人员介入；当活动进入尾声或者业务办理量非常小时可以通过业务处理框架回收资源而无需调整代码逻辑。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1：业务处理框架接入调用流程；

图2：业务处理框架同步、异步处理流程；

图3：处理线程初始化创建流程图；

图4：调整处理线程流程图；

图5：一种处理装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

本系统整体上可以由两部分组成：

其中，业务处理框架单元包括：

同步处理单元，对业务办理请求进行实时处理；

作为一个具体的实施例，业务处理框架单元可以理解成一个集群化的业务处理管理平台。在业务处理框架上，可以对每一个业务流进行可视化的设置。包括：处理模式设置、补偿机制设置、处理速率设置等等。

在业务处理框架单元中，考虑到目前互联网项目多为分布式系统，并且也是出于解耦考虑。业务系统在接入业务处理框架时与业务处理框架并没有业务逻辑上的关联。业务系统在收到业务办理请求后，调用业务处理框架接口并将业务逻辑处理回调方法传递给业务处理框架。业务处理框架在收到业务流时，根据配置调用业务系统回调方法对业务流进行相应处理。也就是说业务处理框架并不包含业务系统的业务逻辑。如：图1。

业务处理框架提供两种处理模式：同步处理模式和异步处理模式，即上述所述的同步处理单元和异步处理单元。

同步处理：业务系统在收到用户办理请求后，将业务流以及业务处理回调方法传给业务处理框架。业务处理框架在收到业务流后，会调用业务系统的回调方法完成业务办理。(对于同步处理来说，操作虽然有些波折，但是为了实现处理模式的实时切换，这一步必不可少)

异步处理：业务系统收到用户办理请求后，将业务流以及业务处理回调方法传给业务处理框架。业务处理框架在收到业务流后，将业务流存入业务流队列。(不同的业务可以分配不同的业务流队列，也可以放在一个业务流队列中处理)可以根据业务办理情况分析。当业务流成功进入业务流队列时就可以告知客户办理成功。实际上业务还未处理，需要排队等候。异步处理分为存和取，前面完成的只是存，接下来是取。不同的业务流处理速率不同，这取决于实际的业务办理量。例如：新上线的业务，办理量大，实时性高，那就需要调高处理速率(需要更多处理线程去处理)。处理线程会循环处理业务流，它会从业务队列中获取业务流。然后调用业务系统的回调方法完成业务办理，办理完成后更新业务处理框架流水表中的处理状态。至此，一条以异步处理模式处理的业务就实际办理完成了。

(1)业务系统调用业务处理框架(传递业务流数据及回调方法)

(2)从redis中根据业务流获取业务流配置信息、业务流队列

(3)将业务流数据保存到mysql中流水表中

(4)将业务流保存到对应的ActiveMQ队列(业务流队列)中

(5)子线程有序读取ActiveMQ队列(业务流队列)中业务流

(6)调用业务系统的回调方法处理业务

(7)将业务系统返回的操作结果更新到业务处理框架数据库流水表中(可配置补偿机制)

补偿机制：补偿机制一般只针对异步处理的业务。在异步处理业务时，会出现失败的情况，但是在用户办理时已提示办理成功。若现在改变业务办理状态显然是不合适的，所以这时就需要补偿机制。补偿机制与业务办理大致类似。根据配置中设置的补偿模式，由业务处理框架重新发起，重新处理尝试次数默认为三次，可根据实际情况自行调整。

(1)查询mysql流水表中的失败记录(需要补偿)

(2)查询这些记录重试处理次数

(3)若大于设置的重试处理次数则不再处理

(4)调用业务系统对应的处理接口重新处理失败数据

(5)处理成功：更新流水表

(6)处理失败：更新重试次数

作为另外一个方面，本申请还提出一种可调配的业务处理方法，用于在集群环境下业务流处理设置调整。

现有技术中在集群环境下无论是修改基本设置，还是切换同步处理和异步处理都是比较复杂的难题。在集群环境下修改设置后，如果需要即时生效，就必须获取新的设置并且加载。较为简单的方案是将设置保存到mysql数据库中，然后在主线程中监听数据库中数据的变化，如果发生变化则刷新内存中的设置，并且重新分配系统资源。此方案需要主线程时刻查询数据库，效率相对较低。

所以本申请在设计时为了调高效率，将数据库改成了redis存储。这里redis相当于是一个事务响应通道，业务流处理设置的读写都在这个通道中完成。主线程就类似于一个监听器，一直监听所有业务流处理设置的变化。对于发生变化的业务流处理设置，需要在不影响监听器的情况下，及时处理。

具体步骤为：

1)创建业务流监听线程：接收业务系统业务流。将业务流分发到业务流队列(保存到ActiveMQ中)。

2)监听业务流处理设置是否发生改变(读取redis中的配置)

3)判断设置是否发生改变，发生改变则根据新的配置调整系统资源

4)循环监听

异步处理过程中处理线程数的调控：当业务流的处理模式从同步调整为异步，或者异步处理模式的速率发生了变化。就需要创建子线程或者重新创建子线程。由于业务流设置在发生变化时，业务流尚在处理过程中。所以如果是调整了异步处理模式，则需要在子线程处理完业务后才能将其终止，而不能直接将子线程终止。如图4所示，根据业务流设置从reids中获取到所有对应的子线程对象，将这些子线程终止。然后再根据设置重新创建新的子线程，并将对象保存到redis中。至此新的线程又可以正常的处理业务流。

1)主线程监听到业务流处理设置改变

2)从redis中读取业务流对应的处理线程对象

3)终止处理线程

4)根据配置重新创建处理线程

图5是本申请实施例提供的一种处理设备的结构示意图。该对象检测设备4000包括处理器41，还可以包括输入装置42、输出装置43和存储器44。该输入装置42、输出装置43、存储器44和处理器41之间通过总线相互连接。

存储器包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read至only memory，ROM)、可擦除可编程只读存储器(erasable programmable readonly memory，EPROM)、或便携式只读存储器(compact disc read至only memory，CD至ROM)，该存储器用于相关指令及数据。

输入装置用于输入数据和/或信号，以及输出装置用于输出数据和/或信号。输出装置和输入装置可以是独立的器件，也可以是一个整体的器件。

处理器可以包括是一个或多个处理器，例如包括一个或多个中央处理器(centralprocessing unit，CPU)，在处理器是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。处理器还可以包括一个或多个专用处理器，专用处理器可以包括GPU、FPGA等，用于进行加速处理。

存储器用于存储网络设备的程序代码和数据。

处理器用于调用该存储器中的程序代码和数据，执行上述方法实施例中的步骤。具体可参见方法实施例中的描述，在此不再赘述。

可以理解的是，图5仅仅示出了对象检测设备的简化设计。在实际应用中，动作识别装置还可以分别包含必要的其他元件，包含但不限于任意数量的输入/输出装置、处理器、控制器、存储器等，而所有可以实现本申请实施例的动作识别装置都在本申请的保护范围之内。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。所显示或讨论的相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者通过该计算机可读存储介质进行传输。该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是只读存储器(read至onlymemory，ROM)，或随机存储存储器(random access memory，RAM)，或磁性介质，例如，软盘、硬盘、磁带、磁碟、或光介质，例如，数字通用光盘(digital versatile disc，DVD)、或者半导体介质，例如，固态硬盘(solid state disk，SSD)等。

以上详细描述了本发明的优选实施方式，但是本发明并不限于上述实施方式中的具体细节，在本发明的技术构思范围内，可以对本发明的技术方案进行多种等同变换(如数量、形状、位置等)，这些等同变换均属于本发明的保护。

Claims

1.一种可调配的业务处理系统，其特征在于，包括：

其中，所述业务处理框架单元包括：

同步处理单元，对业务办理请求进行实时处理；

异步处理单元，将业务办理请求存储至业务流中，根据实时的处理速度对业物流中的任务提取并进行处理；

业务处理系统的数据库均采用redis存储作为事务响应通道，业务流处理设置的读写均在事务响应通道中完成；主线程作为监听器，一直监听所有业务流处理设置的变化，对于发生变化的业务流处理设置，在不影响监听器的情况下进行及时处理；

所述异步处理单元包括：

读取阶段：处理线程循环处理业务流，从业务队列中获取业务流，调用业务系统的回调方法完成业务办理，办理完成后更新业务处理框架流水表中的处理状态；

所述异步处理单元包括如下步骤：

业务系统调用业务处理框架，传递业务流数据及回调方法；

将业务流数据保存到mysql中流水表中；

将业务流保存到对应的业务流队列中；

子线程有序读取业务流队列中业务流；

调用业务系统的回调方法处理业务；

将业务系统返回的操作结果更新到业务处理框架数据库流水表中；

所述异步处理单元还包括：

2.根据权利要求1所述的可调配的业务处理系统，其特征在于，

所述同步处理单元包括：

3.根据权利要求2所述的可调配的业务处理系统，其特征在于，

所述补偿单元包括：

查询mysql流水表中的失败记录，作为需要补偿的对象；

调用业务系统对应的处理接口重新处理失败数据；

处理成功：更新流水表；处理失败：更新重试次数。

4.一种可调配的业务处理方法，其特征在于，包括：

不断获取设置内容，若无改动，按照预设内容分配系统资源；若改动，按照新的配置调整系统资源；

当业务流监听线程监听到业务流处理设置发生改变时：

5.一种处理装置，其特征在于，包括存储器和处理器，所述存储器上存储有计算机可执行指令，所述处理器运行所述存储器上的计算机可执行指令时实现权利要求1-3任意一项所述的系统。

6.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，该计算机程序被处理器执行时，实现上述权利要求1-3任意一项所述的系统。