CN106921712A

CN106921712A - 一种业务处理方法及装置

Info

Publication number: CN106921712A
Application number: CN201510998966.3A
Authority: CN
Inventors: 曹列忠
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced Nova Technology Singapore Holdings Ltd
Priority date: 2015-12-28
Filing date: 2015-12-28
Publication date: 2017-07-04
Anticipated expiration: 2035-12-28
Also published as: CN106921712B

Abstract

本申请实施例提供一种业务处理的方法及装置，该方法通过中间设备在接收到终端发送的业务请求后，判断在中间设备本地保存的历史请求中，是否存在该业务请求，若是，则不对该业务请求进行后续处理，若否，则将该业务请求作为历史请求存储在中间设备的本地，并将该业务请求发送至主库或备库，使得主库或备库在接收到该业务请求后，对其进行处理。上述方法由于是通过中间设备来对业务请求进行幂等操作的，因此，即使出现主库发生宕机而通过备库来对业务请求进行处理的情况时，主库在恢复正常后，也不会对该业务请求再进行一次处理，相对于现有技术而言，可保证业务请求的幂等性，提高了业务处理结果的准确性。

Description

一种业务处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务处理方法及装置。

背景技术

随着网络技术的快速发展，如今的网络能够使人们摆脱传统的线下方式，在网上即可完成对一些业务的处理，极大的方便了用户在处理这些业务时的便利性。

在实际应用中，业务处理结果的准确性通常是极其重要的，为了能够有效的保证这些业务处理结果的准确性，现有技术中通常利用幂等操作来对其进行保证，其中，一个幂等操作的特点是其任意多次执行相同的请求，所产生的影响都是相同的，其主要意义在于：当操作没有达到预期的目标时，用户可以不停的重试，但不会对资源产生副作用。

例如，用户想要进行一项业务时，可通过所使用的终端向数据主库发送业务请求，数据主库在接收到该业务请求后，将判断该业务请求是否为重复请求，若是重复请求，则不对该业务请求进行处理，若否，则对该业务请求进行处理，从而保证了数据主库对业务进行处理时的准确性。

然而，在实际应用中，若用户通过终端将业务请求发送给数据主库后，数据主库出现宕机，则***会启用数据备库来继续接收用户发送过来的业务请求，并暂停数据主库对业务请求的接收工作。而此时，由于误操作、忘记自己是否已发送过该业务请求等情况，用户又重复发送了一次相同的业务请求，则数据备库将会接收用户重复发送过来的业务请求，其中，该业务请求之前并没有在数据备库中出现过，因此，数据备库将会对该业务请求进行处理。但是，当数据备库完成对该业务请求的处理后，数据主库恢复了正常的运行，则数据主库会对先前接收到的业务请求继续执行处理，从而使得数据主库和数据备库对一个业务请求进行了两次处理，进而无法有效的保证对一个业务请求进行处理的幂等性。

发明内容

本申请实施例提供一种业务处理的方法及装置，用以解决现有技术在对一个业务请求进行处理时，无法有效保证其幂等性的问题。

本申请实施例提供的一种业务处理的方法，包括：

中间设备接收终端发送的业务请求；

在所述中间设备本地保存的历史请求中，判断是否存在所述业务请求；

若是，则不对所述业务请求进行处理；

若否，则将所述业务请求作为历史请求存储在本地，并将所述业务请求发送给主库或备库进行处理。

本申请实施例提供的一种业务处理的方法，包括：

客户端生成业务请求；

在数据分库本地保存的历史请求中，判断是否存在所述业务请求；

若是，则不对所述业务请求进行处理；

若否，则将所述业务请求发送到中间设备，使得中间设备在接收到所述业务请求后，当确定所述中间设备本地保存的历史请求中存在所述业务请求时，不对所述业务请求进行处理，当确定所述中间设备本地保存的历史请求中不存在所述业务请求时，将所述业务请求作为历史请求存储在所述中间设备本地，并将所述业务请求发送给主库或备库进行处理。

本申请实施例提供的一种业务处理的装置，包括：

接收模块，用于接收终端发送的业务请求；

判断处理模块，用于在所述装置本地保存的历史请求中，判断是否存在所述业务请求；若是，则不对所述业务请求进行处理；若否，则将所述业务请求作为历史请求存储在本地，并将所述业务请求发送给主库或备库进行处理。

本申请实施例提供的一种业务处理的装置，包括：

请求生成模块，用于生成业务请求；

判断发送模块，用于在数据分库本地保存的历史请求中，判断是否存在所述业务请求；若是，则不对所述业务请求进行处理；若否，则将所述业务请求发送到中间设备，使得中间设备在接收到所述业务请求后，当确定所述中间设备本地保存的历史请求中存在所述业务请求时，不对所述业务请求进行处理，当确定所述中间设备本地保存的历史请求中不存在所述业务请求时，将所述业务请求作为历史请求存储在所述中间设备本地，并将所述业务请求发送给主库或备库进行处理。

本申请实施例提供一种业务处理的方法及装置，该方法通过中间设备在接收到终端发送的业务请求后，判断在中间设备本地保存的历史请求中，是否存在该业务请求，若是，则不对该业务请求进行后续处理，若否，则将该业务请求作为历史请求存储在中间设备的本地，并将该业务请求发送至主库或备库，使得主库或备库在接收到该业务请求后，对该业务请求进行处理。上述方法由于是通过中间设备来对业务请求进行幂等操作的，而非主库或备库，因此，即使出现主库发生宕机而通过备库来对业务请求进行处理的情况时，主库在恢复正常后，也不会对该业务请求再进行一次处理，相对于现有技术中的通过主库或备库来保证业务请求的幂等性而言，可有效保证业务请求的幂等性，提高了业务处理结果的准确性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的业务处理的过程；

图2为本申请实施例提供的另一种业务处理的过程；

图3为本申请实施例提供的业务处理的***示意图；

图4为本申请实施例提供的业务处理的详细过程；

图5为本申请实施例提供的一种业务处理装置的结构示意图；

图6为本申请实施例提供的另一种业务处理装置的结构示意图。

具体实施方式

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

图1为本申请实施例提供的业务处理的过程，具体包括以下步骤：

S101：中间设备接收终端发送的业务请求。

在实际应用中，当人们想要完成一些业务时，可通过诸如电脑、智能手机、平板电脑等智能终端来执行这些业务，通常情况下，终端可先将与这些业务相对应的业务请求发送给主库或备库，使得主库或备库在接收到该业务请求后，完成对用户所需业务的处理。

而为了解决现有技术中主库宕机时，无法保证处理业务请求的幂等性的问题，本申请实施例在用户终端和主库或备库之间增加了中间设备，由中间设备来接收终端发送过来的业务请求，并对该业务请求进行幂等操作，即，当用户要执行业务时，可先使用终端向中间设备发送业务请求，使得中间设备在接收到该业务请求后，通过后续步骤S102～S104来对该业务请求进行幂等操作。其中，该中间设备可以是任何具有转发功能的设备，而由于在实际应用中，中间设备需要接收多个用户发送的业务请求，因此，本申请实施例提供的中间设备可以是分布式缓存。

S102：在所述中间设备本地保存的历史请求中，判断是否存在所述业务请求，若是，则执行步骤S103，若否，则执行步骤S104。

S103：不对所述业务请求进行处理。

S104：将所述业务请求作为历史请求存储在本地，并将所述业务请求发送给主库或备库进行处理。

当中间设备接收到用户终端发送过来的业务请求时，可将该业务请求与中间设备本地保存的历史请求进行逐项匹配，判断在该中间设备的本地中是否存在与该业务请求相同的业务请求，若是，则确定该业务请求为重复请求，因此中间设备不对该业务请求进行后续的处理，若否，则确定该业务请求不是重复请求，中间设备可将该业务请求作为历史请求存储在本地中，并将该业务请求发送至主库或备库，使得主库或备库在接收到该业务请求后，可对该业务请求进行处理，得到业务处理结果，进而完成整个的业务处理过程。后续的，如果中间设备再次接收到与该业务请求相同的业务请求，由于之前已将该业务请求作为历史请求存储在了本地，因此，可判断出再次接收到的业务请求为重复请求，进而不对这一业务请求进行后续的处理。

上述方法中，由于在终端和主库或备库之间增加了用于保证业务请求幂等性的中间设备，使得终端在向主库或备库发送业务请求时，该业务请求需先经过中间设备幂等判断，而只有当中间设备确定该业务请求为非重复请求时，中间设备才会进一步的将该业务请求发送至主库或备库来进行处理，因此，即使出现了主库宕机的情况，备库也不会接收到之前主库已经接收到的业务请求，相对于现有技术中的通过主库或备库来保证业务请求的幂等性而言，可有效保证业务请求的幂等性，提高了业务处理结果的准确性。

在本申请实施例中，中间设备在判断本地保存的历史请求中是否已存在接收到的业务请求时，可通过该业务请求中所包含的业务请求标识来对各历史请求进行匹配，其中，该业务请求标识可以是终端在生成该业务请求时相应生成的一个业务ID，如，交易流水号，支付流水号等，也可以终端或中间设备根据算法以及业务请求的内容来确定的一个业务请求标识，即，只要保证其唯一性即可。

例如，终端或中间设备可根据业务请求中的用户账号信息、业务单号等内容，通过预设的MD5算法，确定出该业务请求的一个唯一的业务请求标识，其中，不同的业务请求所包含的内容都不尽相同，因此，对于两个相同的业务请求来说，终端或中间设备分别确定出的业务请求标识也是一定相同的，因此，中间设备可通过业务请求标识，有效的区分出各业务请求，进而可在后续过程中准确的判断出该业务请求是否已存在于中间设备本地中。

在实际应用中，考虑到中间设备的存储空间有限，无法存储大量的业务请求，并且，若中间设备存储了大量的业务请求，则可能会增加自身的运行负担，降低运行效率，因此，本申请实施例中还提供了一个用于存储中间设备过期业务请求的数据分库，其中，当中间设备中存储的历史请求的存储时间超出了预设的存储时间时，中间设备可将超出预设存储时间的历史请求作为过期的业务请求，发送至预先增设的数据分库来进行存储，从而使得中间设备的存储空间得到很好的释放，可有效保证后续的工作效率。在此基础上，本申请实施例还提供了另一种业务处理的方法，如图2所示。

图2为本申请实施例提供的另一种业务处理的过程，具体包括以下步骤：

S201：客户端生成业务请求。

在实际应用中，当人们想要执行业务时，可通过诸如电脑、智能手机、平板电脑等智能终端上安装的客户端来执行这些业务，通常情况下，用户可根据客户端在终端界面上向用户提供的业务处理界面，来执行相应的操作，而客户端可根据用户执行的业务操作，来生成相应的业务请求，进而可将该业务请求向外进行发送。

S202：在数据分库本地保存的历史请求中，判断是否存在所述业务请求，若是，则执行步骤S203，若否，则执行步骤S204。

S203：不对所述业务请求进行处理。

S204：将所述业务请求发送到中间设备，使得中间设备在接收到所述业务请求后，当确定所述中间设备本地保存的历史请求中存在所述业务请求时，不对所述业务请求进行处理，当确定所述中间设备本地保存的历史请求中不存在所述业务请求时，将所述业务请求作为历史请求存储在所述中间设备本地，并将所述业务请求发送给主库或备库进行处理。

由于增设了数据分库，因此，客户端在向中间设备发送业务请求之前，需先从数据分库中调取数据分库本地保存的历史请求，来对判断在这些历史请求中是否已经存在了该业务请求，此举的目的在于，在实际应用中，客户端可能不清楚中间设备本地保存的历史请求是否已经转移至了数据分库进行存储，若直接将业务请求发送至中间设备，则可能会出现中间设备已将在此之前接收到的相同的业务请求转移至数据分库进行存储的情况，从而会造成中间设备再接收到该业务请求后，将无法有效保证其幂等性的问题。因此，客户端可从数据分库中调取各历史请求，判断将要发送的业务请求是否已存在于调取的这些历史请求中，其中，具体的判断方式也可通过上述步骤S102中所提到的业务请求标识来判断，即，从该业务请求中提取出业务请求标识，并根据该业务请求标识，来对调取的各历史请求进行逐一匹配，若这些历史请求中不存在与该业务请求标识相匹配的历史请求，则客户端可将该业务请求发送至中间设备，使得中间设备在接收到该业务请求后，当确定中间设备本地保存的历史请求中存在该业务请求时，不对该业务请求进行处理，当确定中间设备本地保存的历史请求中不存在该业务请求时，将该业务请求作为历史请求存储在中间设备本地，并将该业务请求发送给主库或备库进行处理，若这些历史请求中不存在与该业务请求标识相匹配的历史请求，则客户端将不对该业务请求进行后续处理，即，不会将该业务请求发送至中间设备中。

需要说明的是，在上述说明的判断过程中，若客户端调取数据分库中本地保存的全部历史请求，则会极大降低终端的运行速度，因此，客户端在从数据分库中调取历史请求的过程中，可只调取与该业务请求中用户标识相匹配的各历史请求，如，通过该业务请求中所包含的用户账号信息，来从数据分库中调取该用户账户信息下的历史请求，从而可极大的节省终端的运行空间，提高终端的运行速度。

上述步骤S102中，中间设备在判断本地保存的历史请求中，是否存在上述业务请求的过程中，若从该业务请求中所提取出的业务请求标识与本地保存的全部历史请求逐一进行匹配，则可能会增加中间设备的运行负担，降低中间设备的运行效率，因此，在本申请实施例中，中间设备也采用与上述步骤S202中相同的方法，即，可先从该业务请求中提取出诸如用户账号等信息的用户标识，并从本地中调取出该用户标识下的历史请求，进而极大了节省了对该业务请求的判断时间，提高了中间设备的处理效率。

在上述步骤S202中，当客户端发现将要发送的业务请求已存在于数据分库本地保存的历史请求中时，客户端可向用户进行提示，即，提示用户该业务请求在此之前已经发送过，无须再次发送。同样的道理，在步骤S102中，当中间设备接收终端发送的业务请求后，发现在本地保存的历史请求中已存在该业务请求，则可向终端发送该业务请求已存在或已处理的提示，使得终端在接收到该提示后，将该提示显示给用户，用户在查看到该提示后，即可知道刚刚发送的业务请求为重复发送的业务请求，中间设备未对该业务请求进行处理。

以上为本申请实施例提供的两种业务处理的方法，基于上述两种方法，本申请实施例还提供了一个业务处理的***，如图3所示。

图3为本申请实施例提供的业务处理的***示意图。

在图3所示的业务处理***中包含有一个中间设备，其中，该中间设备可分别接收各终端发送过来的业务请求，并对各业务请求进行幂等操作，若中间设备判断出接收到的业务请求为新的业务请求时，则可根据实际情况，将该业务请求发送至主库或备库进行处理，其中，当主库运行正常时，则将业务请求发送至主库中，若主库出现宕机时，则可将业务请求发送至***启动的备库中进行处理。而各终端在向中间设备发送业务请求之前，需先从***中设置的数据分库中调取数据分库中存储的历史请求，来判断所要向中间设备发送的业务请求是否为重复请求，具体过程已在上述方法中进行详细说明，在此就不进行详细赘述。

基于上述说明的业务处理***，本申请实施例还提供了一个业务处理的详细过程，如图4所示。

图4为本申请实施例提供的业务处理的详细过程，具体包括以下步骤：

S401：客户端生成业务请求。

S402：在数据分库本地保存的历史请求中，判断是否存在所述业务请求，若是，则执行步骤S403，若否，则执行步骤S404。

S403：不对所述业务请求进行处理。

S404：将所述业务请求发送到中间设备。

S405：中间设备判断在中间设备本地保存的历史请求中，是否存在所述业务请求，若是，则执行步骤S406，若否，则执行步骤S407。

S406：不对所述业务请求进行处理。

S407：将所述业务请求作为历史请求存储在本地，并将所述业务请求发送给主库或备库进行处理。

以上为本申请实施例提供的两种业务处理的方法，基于同样的思路，本申请实施例还提供两种业务处理的装置，如图5、图6所示。

图5为本申请实施例提供的一种业务处理装置的结构示意图，具体包括：

接收模块501，用于接收终端发送的业务请求；

判断处理模块502，用于在所述装置本地保存的历史请求中，判断是否存在所述业务请求；若是，则不对所述业务请求进行处理；若否，则将所述业务请求作为历史请求存储在本地，并将所述业务请求发送给主库或备库进行处理。

所述业务请求中包含有业务请求标识；

所述判断处理模块502具体用于，判断所述装置本地保存的历史请求中，是否存在与所述业务请求标识相对应的历史请求；若是，则确定所述装置本地保存的历史请求中存在所述业务请求；若否，则确定所述装置本地保存的历史请求中不存在所述业务请求。

发送模块503，用于将存储时间超出预设存储时间的历史请求发送至数据分库进行存储。

图6为本申请实施例提供的另一种业务处理装置的结构示意图，具体包括：

请求生成模块601，用于生成业务请求；

判断发送模块602，用于在数据分库本地保存的历史请求中，判断是否存在所述业务请求；若是，则不对所述业务请求进行处理；若否，则将所述业务请求发送到中间设备，使得中间设备在接收到所述业务请求后，当确定所述中间设备本地保存的历史请求中存在所述业务请求时，不对所述业务请求进行处理，当确定所述中间设备本地保存的历史请求中不存在所述业务请求时，将所述业务请求作为历史请求存储在所述中间设备本地，并将所述业务请求发送给主库或备库进行处理。

所述判断发送模块602具体用于，根据所述业务请求中携带的用户标识，调取所述数据分库中与所述用户标识相匹配的各历史请求；根据调取的各历史请求，判断调取的各历史请求中是否存在所述业务请求。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims

1.一种业务处理的方法，其特征在于，包括：

中间设备接收终端发送的业务请求；

若是，则不对所述业务请求进行处理；

2.如权利要求1所述的方法，其特征在于，所述业务请求中包含有业务请求标识；

在所述中间设备本地保存的历史请求中，判断是否存在所述业务请求，具体包括：

判断所述中间设备本地保存的历史请求中，是否存在与所述业务请求标识相对应的历史请求；

若是，则确定所述中间设备本地保存的历史请求中存在所述业务请求；

若否，则确定所述中间设备本地保存的历史请求中不存在所述业务请求。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

将存储时间超出预设存储时间的历史请求发送至数据分库进行存储。

4.如权利要求1所述的方法，其特征在于，所述中间设备包括分布式缓存。

5.一种业务处理的方法，其特征在于，包括：

客户端生成业务请求；

若是，则不对所述业务请求进行处理；

6.如权利要求5所述的方法，其特征在于，在数据分库本地保存的历史请求中，判断是否存在所述业务请求，具体包括：

根据所述业务请求中携带的用户标识，调取所述数据分库中与所述用户标识相匹配的各历史请求；

根据调取的各历史请求，判断调取的各历史请求中是否存在所述业务请求。

7.一种业务处理的装置，其特征在于，包括：

接收模块，用于接收终端发送的业务请求；

8.如权利要求7所述的装置，其特特征在于，所述业务请求中包含有业务请求标识；

所述判断处理模块具体用于，判断所述装置本地保存的历史请求中，是否存在与所述业务请求标识相对应的历史请求；若是，则确定所述装置本地保存的历史请求中存在所述业务请求；若否，则确定所述装置本地保存的历史请求中不存在所述业务请求。

9.如权利要求7所述的装置，其特征在于，所述装置还包括：

发送模块，用于将存储时间超出预设存储时间的历史请求发送至数据分库进行存储。

10.一种业务处理的装置，其特征在于，包括：

请求生成模块，用于生成业务请求；

11.如权利要求10所述的装置，其特征在于，所述判断发送模块具体用于，根据所述业务请求中携带的用户标识，调取所述数据分库中与所述用户标识相匹配的各历史请求；根据调取的各历史请求，判断调取的各历史请求中是否存在所述业务请求。