业务数据处理方法和装置与流程

本申请涉及业务数据处理技术领域，特别涉及一种业务数据处理方法和装置。

背景技术：

随着业务量的不断增长，现有业务系统的交易调用量也日益增加。面对一些客户在短时间内大量循环调用交易的情况下，系统性能压力激增，导致交易处理阻塞。更为严重的是，交易阻塞期间，将会带来成倍数增长的重复和调整交易，最终形成雪崩效应，造成大面积的系统瘫痪。

针对上述问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请实施例提供了一种业务数据处理方法和装置，以解决现有技术中业务量不断增长造成系统交易处理阻塞的问题。

本申请实施例提供了一种业务数据处理方法，应用于业务数据处理系统，该方法包括：接收业务数据处理请求，其中，业务数据处理请求中携带有业务类型标识；根据业务类型标识，确定业务数据处理请求的优先级；基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中，其中，交易队列包括第一交易队列和第二交易队列，高优先级的业务数据处理请求被存放至第一交易队列，低优先级的业务数据处理请求被存放至第二交易队列；利用第一交易处理模块从第一交易队列中读取业务数据处理请求并执行对应的业务数据处理；利用第二交易处理模块从第二交易队列中读取业务数据处理请求并执行对应的业务数据处理；其中，第一交易处理模块与第二交易处理模块为业务数据处理系统中不同的交易处理模块。

在一个实施例中，业务数据处理系统中的交易处理模块以容器化方式部署；相应的，该方法还包括：采集第一交易处理模块和第二交易处理模块执行业务数据处理时生成的交易处理信息以及第一交易队列和第二交易队列中待处理的业务数据处理请求的数量；利用交易处理信息和待处理的业务数据处理请求的数量，计算业务数据处理系统的负载系数，其中，负载系数用于表征业务数据处理系统的负载程度；基于业务数据处理系统的负载系数和业务数据处理系统的容器实例数量，对业务数据处理系统进行弹性横向伸缩。

在一个实施例中，基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中，包括：确定令牌容器中剩余的令牌数量是否小于预设数量；在确定令牌容器中剩余的令牌数量不小于预设数量的情况下，从令牌容器获取预设数量的令牌，并基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中；在确定令牌容器中剩余的令牌数量小于预设数量的情况下，对业务数据处理请求进行限流处理。

在一个实施例中，该方法还包括：获取业务数据处理系统的负载系数；根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率；基于令牌补充速率向令牌容器添加令牌。

在一个实施例中，在根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率之后，还包括：确定令牌补充速率是否小于预设速率；在确定令牌补充速率小于预设速率的情况下，对业务数据处理系统进行横向扩容，以降低业务处理系统的负载系数。

在一个实施例中，根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率，包括：按照以下公式计算令牌容器中的令牌补充速率：

r＝i/l；

其中，r为令牌补充速率，i为预设补充速率，l为负载系数。

在一个实施例中，业务数据处理请求中还携带有请求参数，该方法还包括：将业务数据处理请求的请求参数和业务数据处理请求对应的处理结果关联存储至预设缓存中；在接收到目标业务数据处理请求之后，在预设缓存中查询是否存在目标业务数据处理请求中的请求参数；在查询到存在目标业务数据处理请求中的请求参数的情况下，将查找到的请求参数对应的处理结果确定为目标业务数据处理请求对应的处理结果。

本申请实施例还提供了一种业务数据处理装置，应用于业务数据处理系统，该装置包括：请求接收模块，用于接收业务数据处理请求，其中，业务数据处理请求中携带有业务类型标识；优先级确定模块，用于根据业务类型标识，确定业务数据处理请求的优先级；请求存放模块，用于基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中，其中，交易队列包括第一交易队列和第二交易队列，高优先级的业务数据处理请求被存放至第一交易队列，低优先级的业务数据处理请求被存放至第二交易队列；数据处理模块，用于利用第一交易处理模块从第一交易队列中读取业务数据处理请求并执行对应的业务数据处理；利用第二交易处理模块从第二交易队列中读取业务数据处理请求并执行对应的业务数据处理；其中，第一交易处理模块与第二交易处理模块为业务数据处理系统中不同的交易处理模块。

本申请实施例还提供一种计算机设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现上述任意实施例中所述的业务数据处理方法的步骤。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现上述任意实施例中所述的业务数据处理方法的步骤。

在本申请实施例中，提供了一种业务数据处理方法，可以接收业务数据处理请求，根据业务数据处理请求中携带的业务类型标识，确定业务数据处理请求的优先级，将高优先级的业务数据处理请求存放至第一交易队列，将低优先级的业务数据处理请求存放至第二交易队列，可以利用第一交易处理模块从第一交易队列中读取业务数据处理请求并执行对应的业务数据处理，利用第二交易处理模块从第二交易队列中读取业务数据处理请求并执行对应的业务数据处理，其中，第一交易处理模块与第二交易处理模块为业务数据处理系统中不同的交易处理模块。上述方案中，根据业务类型确定业务数据处理请求的优先级，将不同优先级的请求存放至不同的交易队列中，并利用不同的交易处理模块从对应的交易队列中读取请求并执行业务数据处理，对于高低优先级交易的分类处理，每个交易处理模块仅会处理高优先级或低优先级的交易，不会同时处理优先级水平不同的交易，可以保证低优先级的交易不会阻塞高优先级交易处理，实现交易分流，缓解交易处理阻塞，可以有效提高交易处理效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，并不构成对本申请的限定。在附图中：

图1示出了本申请一实施例中业务数据处理方法的流程图；

图2示出了本申请一实施例中通过令牌容器进行交易限流的方法的示意图；

图3示出了本申请一实施例中的交易结果缓存的流程图；

图4示出了本申请一实施例中的业务数据处理装置的示意图；

图5示出了本申请一实施例中的计算机设备的示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本申请公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域的技术人员知道，本申请的实施方式可以实现为一种系统、装置设备、方法或计算机程序产品。因此，本申请公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

本申请实施例提供了一种业务数据处理方法，应用于业务数据处理系统。图1示出了本申请一实施例中业务数据处理方法的流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例描述及附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至分布式处理环境)。

具体地，如图1所示，本申请一种实施例提供的业务数据处理方法可以包括以下步骤。

步骤s101，接收业务数据处理请求。

本实施例中的业务数据处理方法可以应用于业务数据处理系统。其中，业务数据可以包括各种银行业务数据。业务数据处理系统可以接收客户端发送的业务数据处理请求。其中，业务数据处理请求中携带有业务类型标识。业务类型标识可以表示业务数据处理请求对应的数据处理的类型。例如，业务类型标识可以包括查询类业务标识、财务处理类业务标识等。

步骤s102，根据业务类型标识，确定业务数据处理请求的优先级。

在接收到业务数据处理请求之后，可以根据业务数据处理请求中的业务类型标识，确定业务数据处理请求的优先级。例如，可以将携带有查询类业务标识的业务数据处理请求的优先级确定为高优先级，将携带有财务处理类业务标识的业务数据处理请求的优先级确定为低优先级。

又例如，业务数据处理系统中存储有优先级关系表，优先级关系表中存储有业务类型标识与优先级之间的对应关系。可以通过查询优先级关系表来确定业务数据处理请求的优先级。

步骤s103，基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中。

在确定业务数据处理请求的优先级之后，可以基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中。其中，交易队列包括第一交易队列和第二交易队列。可以将高优先级的业务数据处理请求存放至第一交易队列，将低优先级的业务数据处理请求存放至第二交易队列。第一交易队列与第二交易队列是两个不同的交易队列。

步骤s104，利用第一交易处理模块从第一交易队列中读取业务数据处理请求并执行对应的业务数据处理；利用第二交易处理模块从第二交易队列中读取业务数据处理请求并执行对应的业务数据处理。

可以利用第一交易处理模块从第一交易队列中读取高优先级的业务数据处理请求，并执行该业务数据处理器请求对应的业务数据处理。可以利用第二交易处理模块从第二交易队列中读取低优先级的业务数据处理请求，并执行该业务数据处理请求对应的业务数据处理。其中，第一交易处理模块与第二交易处理模块为业务数据处理系统中不同的交易处理模块。即，第一交易队列可以对应一个或多个第一交易处理模块，第二交易队列可以对应一个或多个第二交易处理模块。第一交易处理模块仅用于处理高优先级的业务数据处理请求。第二交易处理模块仅用于处理低优先级的业务数据处理请求。

上述实施例中，根据业务类型确定业务数据处理请求的优先级，将不同优先级的请求存放至不同的交易队列中，并利用不同的交易处理模块从对应的交易队列中读取请求并执行业务数据处理，对于高低优先级交易的分类处理，每个交易处理模块仅会处理高优先级或低优先级的交易，不会同时处理优先级水平不同的交易，可以保证低优先级的交易不会阻塞高优先级交易处理，实现交易分流，缓解交易处理阻塞，可以有效提高交易处理效率。

在本申请一些实施例中，业务数据处理系统中的交易处理模块可以以容器化方式部署；相应的，该方法还可以包括：采集第一交易处理模块和第二交易处理模块执行业务数据处理时生成的交易处理信息以及第一交易队列和第二交易队列中待处理的业务数据处理请求的数量；利用交易处理信息和待处理的业务数据处理请求的数量，计算业务数据处理系统的负载系数，其中，负载系数用于表征业务数据处理系统的负载程度；基于业务数据处理系统的负载系数和业务数据处理系统的容器实例数量，对业务数据处理系统进行弹性横向伸缩。

具体地，业务数据处理系统包括多个交易处理模块。多个交易处理模块可以以容器化方式进行部署，并可以通过集群化方式管理。可以采集各交易处理模块执行业务数据处理时生成的交易处理信息以及各交易队列中待处理的业务数据处理请求的数量。其中，交易处理信息可以包括交易处理模块生成的交易处理时效和吞吐量等信息。之后，可以利用交易处理信息和待处理的业务数据处理请求的数量，计算业务数据处理系统的负载系数。其中，负载系数用于表征业务数据处理系统的负载程度，负载系数越大，表明业务数据处理系统的负载越高。负载系数与待处理的业务数据处理请求的数量成反比。在计算出系统的负载系数之后，可以根据系统负载系数得知当前系统负载情况，通过对比当前系统负载情况和当前系统容器实例数量，对业务数据处理系统进行弹性横向伸缩，即进行弹性横向扩容或缩容。

在一个实施方式中，可以将交易处理信息、交易队列堆积量等系统负载信息存放至缓存模块中。可以利用交易处理信息采集模块定时采集由交易处理模块生成的交易处理时效，吞吐量等信息。可以利用交易队列堆积量采集模块定时采集各交易队列中待处理的交易数量。可以定时触发系统负载情况分析模块，通过综合分析交易处理信息和交易队列堆积量来量化计算出系统负载系数l，并存放在缓存模块中。可以利用交易处理集群控制模块将交易处理模块以容器化方式部署，并通过集群化方式管理。通过读取缓存模块中的负载系数l，对应当前容器实例个数n，根据预设的负载系数的上阈值t和下阈值b进行弹性的扩容或缩容。当l>nt时，认为当前实例个数n不足以处理负载系数为l的交易请求，需对集群进行扩容，新增k个实例以满足l<＝(n+k)t。当l<nb时，认为当前系统负载系数l对于当前n个实例处理有性能冗余，需对集群进行缩容，销毁k个实例以满足l>＝(n-k)b。通过上述方式，能够保证在高负载场景下，通过扩容，提升交易处理能力来保证服务的可用；同时，在普通负载场景下，也可通过缩容，避免浪费不必要的计算资源。

在本申请一些实施例中，基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中，包括：确定令牌容器中剩余的令牌数量是否小于预设数量；在确定令牌容器中剩余的令牌数量不小于预设数量的情况下，从令牌容器获取预设数量的令牌，并基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中；在确定令牌容器中剩余的令牌数量小于预设数量的情况下，对业务数据处理请求进行限流处理。

具体地，可以设置令牌容器，用于储存一定量的令牌，具有最大容量n。当容器中令牌数量等于其容量n时，无法再向其中添加令牌。业务数据处理请求在进入系统前，会先尝试从令牌容器中获取c个令牌，若令牌容器中令牌余量r大于等于c个，从容器中移除c个令牌，并基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中。若令牌容器中令牌余量r不足c个，则该请求被限流处理，容器中令牌数量不变。上述方式，在令牌容器中的令牌数目较少时，对交易请求进行限流处理，降低系统处理压力，防止交易处理发生阻塞。

在本申请一些实施例中，所述方法还可以包括：获取业务数据处理系统的负载系数；根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率；基于令牌补充速率向令牌容器添加令牌。

具体地，可以定时触发通过读取缓存中存储的当前系统的负载系数，根据负载系数确定令牌容器中的令牌补充速率，并基于令牌补充速率向令牌容器添加令牌。其中，令牌补充速率可以与系统的当前负载系数成反相关，即负载越大，令牌补充速率越小，对业务数据处理请求的限流越强。相比于传统令牌容器的令牌恢复速率是恒定的，本实施例可以根据系统的动态负载情况动态调整令牌补充速率，从而能够对业务数据交易请求进行动态限流，避免系统数据处理压力过大。

在本申请一些实施例中，在根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率之后，还可以包括：确定令牌补充速率是否小于预设速率；在确定令牌补充速率小于预设速率的情况下，对业务数据处理系统进行横向扩容，以降低业务处理系统的负载系数。

具体地，随着负载系数不断增大，令牌补充系数持续减小，这种情况下可以设置一个最小速率，即预设速率。在令牌补充速率小于预设速率的情况下，可以通过对业务数据处理系统进行横向扩容，来提升处理能力，进而降低负载。通过上述方式，在令牌补充速率小于预设速率的情况下，通过对业务数据处理系统进行扩容来提升处理能力，从而可以保证系统正常服务。

在本申请一些实施例中，根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率，可以包括：按照以下公式计算令牌容器中的令牌补充速率：

r＝i/l；

其中，r为令牌补充速率，i为预设补充速率，l为负载系数。通过上述方式，可以计算出令牌补充速率。

请参考图2，示出了本申请一实施例中通过令牌容器进行交易限流的方法的示意图。其中，自适应令牌生成器可以根据业务数据处理系统当前的负载情况，定时自适应地向令牌容器添加令牌。自适应令牌生成器可以通过读取缓存中存储的当前系统负载情况l，根据预设的单位时间补充的令牌数量i，计算出补充令牌的速率r∝i/l，即单位时间内向令牌容器中补充r个令牌。注意当系统负载l递增时，r值会递减，为保证系统正常服务，预设有r值的最低值可接受值rmin，当r值触及rmin时，将不会继续减小。这种情况下，系统可以基于所述业务数据处理系统的负载系数和所述业务数据处理系统的容器实例数量，对所述业务数据处理系统进行横向扩展，来提升处理能力，进而降低负载。在接收到交易请求时，可以从令牌容器获取令牌。在令牌足够时，消耗令牌，交易请求被放行。在令牌不足的情况下，进行交易限流。

在本申请一些实施例中，业务数据处理请求中还携带有请求参数，该方法还可以包括：将业务数据处理请求的请求参数和业务数据处理请求对应的处理结果关联存储至预设缓存中；在接收到目标业务数据处理请求之后，在预设缓存中查询是否存在目标业务数据处理请求中的请求参数；在查询到存在目标业务数据处理请求中的请求参数的情况下，将查找到的请求参数对应的处理结果确定为目标业务数据处理请求对应的处理结果。

具体地，在交易处理模块每执行一个业务数据处理之后，可以将对应的业务数据处理请求的请求参数和该请求对应的处理结果关联存储至预设缓存中。在接收到新的目标业务数据处理请求之后，可以获取该目标业务数据处理请求的请求参数。之后，在预设缓存中查询是否存在该目标业务数据处理请求的请求参数。在查询到存在该目标业务数据处理请求的请求参数的情况下，将查找到的请求参数对应的处理结果确定为该目标业务数据处理请求对应的处理结果，并返回给客户端。

请参考图3，示出了本申请实施例中提供的交易结果缓存的流程图。当新的交易请求进入交易限流模块前，可以获取交易请求参数。可以以交易请求参数为键，在缓存中查询其对应的值。若能够查询到对应的值，则直接以该值返回用户，该交易将直接闭环。若交易参数无法在缓存中查询到对应的值，则继续进入限流模块，进行后续的正常操作。交易处理模块在处理完一笔交易后，可以将该笔交易的参数作为键，处理结果作为值，存入缓存模块中，并设置一个较短的缓存过期时间。通过利用缓存模块，可以保证在缓存过期时间内，相同参数的交易请求将实际只处理一次，其余的交易将直接从缓存中获取结果返回，进一步降低了在短时间内大量循环调用交易场景下的交易处理模块的负载。

基于同一发明构思，本申请实施例中还提供了一种业务数据处理装置，应用于业务数据处理系统，如下面的实施例所述。由于业务数据处理装置解决问题的原理与业务数据处理方法相似，因此业务数据处理装置的实施可以参见业务数据处理方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图4是本申请实施例的业务数据处理装置的一种结构框图，如图4所示，包括：请求接收模块401、优先级确定模块402、请求存放模块403和数据处理模块404，下面对该结构进行说明。

请求接收模块401用于接收业务数据处理请求，其中，业务数据处理请求中携带有业务类型标识。

优先级确定模块402用于根据业务类型标识，确定业务数据处理请求的优先级。

请求存放模块403用于基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中，其中，交易队列包括第一交易队列和第二交易队列，高优先级的业务数据处理请求被存放至第一交易队列，低优先级的业务数据处理请求被存放至第二交易队列。

数据处理模块404用于利用第一交易处理模块从第一交易队列中读取业务数据处理请求并执行对应的业务数据处理；利用第二交易处理模块从第二交易队列中读取业务数据处理请求并执行对应的业务数据处理；其中，第一交易处理模块与第二交易处理模块为业务数据处理系统中不同的交易处理模块。

在本申请一些实施例中，业务数据处理系统中的交易处理模块以容器化方式部署；相应的，该方法还包括：采集第一交易处理模块和第二交易处理模块执行业务数据处理时生成的交易处理信息以及第一交易队列和第二交易队列中待处理的业务数据处理请求的数量；利用交易处理信息和待处理的业务数据处理请求的数量，计算业务数据处理系统的负载系数，其中，负载系数用于表征业务数据处理系统的负载程度；基于业务数据处理系统的负载系数和业务数据处理系统的容器实例数量，对业务数据处理系统进行弹性横向伸缩。

在本申请一些实施例中，请求存放模块可以具体用于：确定令牌容器中剩余的令牌数量是否小于预设数量；在确定令牌容器中剩余的令牌数量不小于预设数量的情况下，从令牌容器获取预设数量的令牌，并基于业务数据处理请求的优先级，将业务数据处理请求存放至对应的交易队列中；在确定令牌容器中剩余的令牌数量小于预设数量的情况下，对业务数据处理请求进行限流处理。

在本申请一些实施例中，该装置还可以包括令牌补充模块，令牌补充模块可以用于：获取业务数据处理系统的负载系数；根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率；基于令牌补充速率向令牌容器添加令牌。

在本申请一些实施例中，在根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率之后，还包括：确定令牌补充速率是否小于预设速率；在确定令牌补充速率小于预设速率的情况下，对业务数据处理系统进行横向扩容，以降低业务处理系统的负载系数。

在本申请一些实施例中，根据负载系数计算业务数据处理系统的令牌容器中的令牌补充速率，包括：按照以下公式计算令牌容器中的令牌补充速率：

r＝i/l；

其中，r为令牌补充速率，i为预设补充速率，l为负载系数。

在本申请一些实施例中，业务数据处理请求中还携带有请求参数，该装置还包括：结果缓存模块，结果缓存模块具体用于：将业务数据处理请求的请求参数和业务数据处理请求对应的处理结果关联存储至预设缓存中；在接收到目标业务数据处理请求之后，在预设缓存中查询是否存在目标业务数据处理请求中的请求参数；在查询到存在目标业务数据处理请求中的请求参数的情况下，将查找到的请求参数对应的处理结果确定为目标业务数据处理请求对应的处理结果。

从以上的描述中，可以看出，本申请实施例实现了如下技术效果：根据业务类型确定业务数据处理请求的优先级，将不同优先级的请求存放至不同的交易队列中，并利用不同的交易处理模块从对应的交易队列中读取请求并执行业务数据处理，对于高低优先级交易的分类处理，每个交易处理模块仅会处理高优先级或低优先级的交易，不会同时处理优先级水平不同的交易，可以保证低优先级的交易不会阻塞高优先级交易处理，实现交易分流，缓解交易处理阻塞，可以有效提高交易处理效率。

本申请实施方式还提供了一种计算机设备，具体可以参阅图5所示的基于本申请实施例提供的业务数据处理方法的计算机设备组成结构示意图，所述计算机设备具体可以包括输入设备51、处理器52、存储器53。其中，所述存储器53用于存储处理器可执行指令。所述处理器52执行所述指令时实现上述任意实施例中所述的业务数据处理方法的步骤。

在本实施方式中，所述输入设备具体可以是用户和计算机系统之间进行信息交换的主要装置之一。所述输入设备可以包括键盘、鼠标、摄像头、扫描仪、光笔、手写输入板、语音输入装置等；输入设备用于把原始业务数据和处理这些数的程序输入到计算机中。所述输入设备还可以获取接收其他模块、单元、设备传输过来的业务数据。所述处理器可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式等等。所述存储器具体可以是现代信息技术中用于保存信息的记忆设备。所述存储器可以包括多个层次，在数字系统中，只要能保存二进制业务数据的都可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也叫存储器，如ram、fifo等；在系统中，具有实物形式的存储设备也叫存储器，如内存条、tf卡等。

在本实施方式中，该计算机设备具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

本申请实施方式中还提供了一种基于业务数据处理方法的计算机存储介质，所述计算机存储介质存储有计算机程序指令，在所述计算机程序指令被执行时实现上述任意实施例中所述业务数据处理方法的步骤。

在本实施方式中，上述存储介质包括但不限于随机存取存储器(randomaccessmemory,ram)、只读存储器(read-onlymemory,rom)、缓存(cache)、硬盘(harddiskdrive,hdd)或者存储卡(memorycard)。所述存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。

在本实施方式中，该计算机存储介质存储的程序指令具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

应该理解，以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述，在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此，本申请的范围不应该参照上述描述来确定，而是应该参照前述权利要求以及这些权利要求所拥有的等价物的全部范围来确定。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请实施例可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。