CN109902077B - 一种业务请求处理方法、装置及设备 - Google Patents

Abstract

本说明书实施例公开了一种业务请求处理方法、装置及设备。方案包括：获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

Description

一种业务请求处理方法、装置及设备

技术领域

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

背景技术

现有技术中，随着计算机网络的普遍，网上业务处理成为人们生活中的一部分。在实际应用中，保证网上业务的处理结果的准确性在某些特殊的应用场景下，甚至会关乎人们的财产损失，比如当用户在进行某项支付操作或者转账操作时，通过终端设备向数据主库发送业务请求，数据主库在接收到该业务请求后，判断该业务请求是否为重复请求，若是重复请求，则不对该业务请求进行处理，若否，则对该业务请求进行处理，从而保证了数据主库对业务进行处理时的准确性。

但是，若用户通过终端将业务请求发送给数据主库后，数据主库出现宕机，则系统会启用逻辑备库，具体采用故障切换库，其中，逻辑备库切换包括故障切换(failover，简称fo)和普通切换(Switchover)，将数据主库中的业务请求切换到fo库继续处理，但是在切换瞬间，由于没有一个全局控制器，当用户误操作或者忘记自己是否已发送过该业务请求等情况时，用户可能会重复发送多次相同的业务请求，这时，可能会出现同一请求在主库和fo库切换瞬间造成主库和fo库均处理的情况，从而使得数据主库和fo库对一个业务请求进行了两次处理，对用户造成损失。

发明内容

有鉴于此，本申请实施例提供了一种业务请求处理方法、装置及设备，用于解决逻辑备库切换瞬间重复请求被多次处理的问题，提高了业务请求处理结果的准确性。

为解决上述技术问题，本说明书实施例是这样实现的：

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

获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；

若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

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

业务处理请求获取模块，用于获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

判断模块，用于确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；

业务处理停止模块，用于若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

处理模块，用于若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

本说明书实施例提供的一种业务请求处理设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；

若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：当主库崩溃时，将主库、业务故障切换库进行切换时，获取了业务请求，首先通过判断所述业务处理请求在所述数据库中是否存在过，若不存在，fo库对所述业务处理请求进行处理，保证了在主库和fo库切换瞬间同一请求不会造成被主库和fo库均处理，保证了业务请求处理结果的准确性。

附图说明

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

图1为本说明书实施例提供的一种业务请求处理方法的流程示意图；

图2为本说明书实施例1提供的一种业务处理请求包括上游单号和下游单号的处理方法流程示意图；

图3为本说明书实施例2提供的一种业务处理请求为上游单号的处理方法的流程示意图；

图4为本说明书实施例提供的对应于图1的一种业务请求处理装置的结构示意图；

图5为本说明书实施例提供的对应于图1的一种业务处理请求处理设备的结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

现有技术中，用户通过终端将业务请求发送给数据主库后，数据主库出现宕机，则系统会启用故障切换库(fo库)，将数据主库中的业务请求切换到fo库继续处理，但是在切换瞬间，当用户误操作或者忘记自己是否已发送过该业务请求等情况时，用户可能会重复发送多次相同的业务请求，这时，可能会出现同一请求在主库和fo库切换瞬间造成主库和fo库均接收到该业务处理请求，并都做相应处理的情况，从而使得数据主库和fo库对一个业务请求进行了多次处理，或者fo库对同一个请求进行多次处理，对用户造成损失。

比如：在双十二购物期间，由于商家的优惠活动仅限前十名付款的用户，因此，会导致用户争分夺秒疯抢的情况。在抢购的过程中，用户通过移动终端将价格为100元的淘宝商品的支付请求发送给数据主库进行处理，在处理过程中，由于网络情况或者主库的流量压力导致主库崩溃，此时，系统将数据主库中的支付请求切换到fo库继续处理，fo库对该支付请求进行处理操作，成功支付100元，此时，可能由于网络问题，已支付完成的界面没有及时跳转，导致用户不知道该商品已购买成功，而再次点击支付按钮，此时，fo库继续对该支付请求进行处理操作，完成100元支付，此时，用户共支付200元，造成了fo库对同一个支付请求支付两次的问题。

或者是，用户通过移动终端将价格为100元的淘宝商品的支付请求发送给数据主库进行处理，主库在将支付请求处理结束后崩溃，而由于网络延迟原因，系统并没及时显示支付完成结果，导致用户再次点击支付请求按钮，而此时由于主库崩溃，数据库已由主库切换到fo库，因此，用户再次点击请求按钮后，支付请求只会发送到fo库，导致fo库再次对该支付请求进行处理，造成同一支付请求被主库和fo库均处理的问题。

因此，现有技术中的方法，会造成在主库、fo库切换瞬间，同一业务处理请求被主库和fo库均处理或者同一请求被fo库重复处理的缺陷。

图1为本说明书实施例提供的一种业务请求处理方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。

如图1所示，该流程可以包括以下步骤：

S101:获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求。

业务故障切换库(failover，简称fo库)，作为主库崩溃后的切换备用库，当系统中其中一项设备、数据库失效而无法运作时，另一项设备或数据库即可自动接手原失效系统所执行的工作，继续执行，保证系统的正常运行，failover也可以叫失效备援库，当主库发生故障后，为了数据的安全性与完整性，要将工作模式设置为：最大可用性模式(主库设置完后，fo库自动也为此模式)，这样会保证数据在fo库中的零丢失。

业务处理请求可以是具体的支付请求，也可以是由一台设备发送给另一台设备的任务请求指令等等。但是这里的业务处理请求是针对业务故障切换库的业务处理请求。例如：购物平台的支付请求、各种社交软件上的转账请求、事务处理请求等等。

S102:确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库。

数据库：数据库(Database)是按照数据结构来组织、存储和管理数据的仓库。本方案中所述的数据库可以是业务主库对应的存储数据库或者是业务故障切换库对应的存储数据库，分别用于存储业务主库对业务处理请求的处理记录以及故障切换库对业务处理请求的处理记录，具体的，在本方案中第一数据库可以是业务故障切换库对应的存储数据库，第二数据库可以是业务主库对应的存储数据库。

在现有技术中，业务主库对应的数据库与备库对应的数据库数据更新是同步的，但是在故障切换瞬间，可能会造成业务主库对应的数据库中存储的数据在备库对应的数据库中不存在的情况。例如：在业务主库崩溃前，收到一个业务处理请求A，业务主库对请求A进行处理，处理完成后，业务主库由于网络原因崩溃，此时业务主库针对所述业务处理请求A的业务处理请求记录A’已经存储到业务主库对应的存储数据库中，此时，由于业务主库崩溃了，在进行备库切换时，可能会导致数据出现丢失的情况，此时备库虽然接管了业务主库的工作，但是在切换瞬间丢失的业务处理请求记录A’可能不存在于所述备库对应的存储数据库中，导致备库对同一请求做重复处理。

因此，可以采用failover切换方法，当业务主库发生崩溃，将业务切换给业务故障切换库之后，业务故障切换库在接收到其他业务处理请求时，应该首先从第一数据库和第二数据库中查找是否存在该业务处理请求对应的业务处理请求记录，保证数据在fo库中的零丢失，从而保证处理结果准确性。

S103:若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理。

当从数据库中查找到与当前的业务处理请求对应的业务处理请求处理记录时，则证明该业务处理请求已经被处理过，因此，不能再次进行处理，从而保证数据处理的幂等性。

这里所说的幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。具体的，现在的系统大多拆分为分布式面向服务的体系结构(Service-Oriented Architecture，简称SOA)，或者微服务，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用就是使用远程过程调用协议(Remote Procedure Call Protocol，简称RPC)通信或者restful，其中，REST(Representational State Transfer，简称REST)指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTfu，l描述了一个架构样式的网络系统，在某些情况下，有可能在服务器处理完毕后返回结果的时候崩溃，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，就需要保证服务器处理调用的幂等性，来保证同一请求仅被处理一次。

S104:若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

当系统从数据库中查找不到与该业务处理请求对应的业务处理请求记录，则可以证明该业务处理请求没有被业务主库或者业务故障切换库处理过。而此时由于主库已经崩溃，为了数据的安全性与完整性，要将DG的工作模式设置为：最大可用性模式(主库设置完后，fo库自动也为此模式)，将业务主库中的业务处理请求切换给所述业务故障切换库继续进行处理。

图1中的方法，通过在主库崩溃与fo库切换的瞬间，对业务处理请求进行查询判断，在收到业务处理请求后，首先查找数据库中是否存在对应的业务处理请求记录，不存在，则正常处理收到的业务处理请求，否则拒绝处理收到的业务处理请求，以次保证同一业务处理请求不会被处理多次，保证了业务处理结果的准确性。

基于图1的方法，本说明书实施例还提供了该方法的一些具体实施方案，下面进行说明。

上述方案中，所述查询数据库中是否存在所述业务处理请求的处理记录，具体可以包括：

确定所述业务处理请求中的下游单号；所述业务处理请求中包括上游单号以及下游单号；所述下游单号表示上游系统中的上游单号在下游系统中生成的内部单号；所述上游系统表示生成上游单号的系统；所述下游系统表示与所述上游系统实现信息交互的系统；所述上游单号与所述下游单号一一对应。

根据所述下游单号确定待查询数据库。

查询所述待查询数据库中是否存在所述下游单号对应的业务处理请求的处理记录。

这里的下游单号可以指的是在请求支付时，由上游单号(订单编号)生成的支付宝系统的数据库中单号(即支付宝交易号)，一个上游单号在一次交易中只会生成一个对应的下游单号。

在实际操作中，从下游单号上可以看出需要查询的数据库的具体位置，具体到某个数据库中的某个表。这里的数据库为存储数据库，分别用来存储业务主库或者业务故障切换库对业务处理请求进行处理后的处理记录。

对于交易类业务系统，跟下游业务系统交互时需要根据传入的上游单号动态生成相应的支付宝系统的数据库中单号，跟下游交互传递的是此时系统生成的支付宝系统的数据库中单号。

所述根据所述下游单号确定待查询数据库，具体可以包括：

根据所述下游单号确定数据库弹性位；所述数据库弹性位表示所述待查询数据库类型；

当所述数据库弹性位表示所述待查询数据库类型为业务故障切换库时，将所述业务故障切换库确定为所述待查询数据库；

当所述数据库弹性位表示所述待查询数据库类型为业务主库时，将所述业务主库确定为所述待查询数据库。

下游单号(支付宝交易单号)中包括订单创建日期、弹性位、序列号等等信息。例如：在淘宝购物不管是买家还是卖家都会有一个“订单编号”，这个“订单编号”是淘宝作为一笔交易对应的编号，每个编号都是唯一的，与此同时做为买家或卖家在付款或收款时支付宝也会有唯一一个编号来区分每一笔交易，也即“支付宝交易号”，这两个编号均可在淘宝或支付宝的订单信息中查询到。现在的支付宝交易号为28位，从下游单号中可以识别出弹性位之后，根据弹性位就能判断下游单号所对应的交易记录应该存储的数据库，从下游单号中还能识别出一个虚拟单号，该虚拟单号中可以看出下游单号所对应的交易记录应该存储的库表位置。

所述将所述业务处理请求发送给所述业务故障切换库进行处理之后，还可以包括：

将所述业务处理请求的处理记录存储在所述数据库中。

每一条业务请求记录被处理完后，系统会将相应的处理记录存储到数据库中，即用户从相应的数据库中能够查询到商品名称、支付宝交易号、商品订单编号、交易金额、交易方式、交易状态和操作等等。

所述将所述业务处理请求的处理记录存储在所述数据库中之后，还可以包括：

获取查询请求；所述查询请求包括所述上游单号或者所述下游单号；

根据所述查询请求从所述待查询数据库中查找所述业务处理请求记录。

实际应用中，在某项交易完成之后，用户可能会查看相关交易记录，这时，用户可以选择采用上游系统的上游单号(商品订单号)来查询，也可以采用下游单号(支付宝交易号)进行查询。

在具体应用中，当一套新代码(业务故障切换库对应的代码)要进行发布时，为了保证系统的正常运行，不能直接将老代码切断，运行新代码，因此，会存在一个新代码与老代码切换的过程，在新代码发布的瞬间，采用以下方式进行查询：

所述根据所述查询请求从所述待查询数据库中查找所述业务处理请求记录，具体可以包括：

获取所述业务故障切换库对应的代码的发布状态；

查询所述代码是否已发布完成；

若所述代码未发布完成，则根据所述下游单号确定所述待查询数据库，并根据所述上游单号从所述待查询数据库中查询所述业务处理请求记录；

若所述代码已发布完成，则根据所述上游单号或者所述下游单号从所述待查询数据库中查询所述业务处理请求记录。

新代码发布瞬间，在请求重发场景下可能出现，某一处理请求已经由老代码处理完成并存储到对应的数据库中，此时，该请求再次发送给新代码时，新代码中生成下游单号后，由于上游单号一致，fo库无法根据下游单号对该处理请求进行处理并存储。

因此，下游单号与数据库中的存储的支付宝交易号不同，此时不能使用下游单号查询到业务处理请求记录，只能根据下游单号限定分库分表位信息，然后根据上游单号从数据库中的数据为准。

采用本方案实施例中的方法，建立了一套新代码后，需要将新代码进行发布，在发布时，为了保证系统运行不停止，再将新代码与老代码进行替换时，需要在老代码使用过程中逐渐替换成新代码，新老代码共用一个数据库。具体操作过程可以采用以下例子进行说明：

例如：有两个机房分别为A机房和B机房，A机房与B机房中的流量各为50％，且都运行老代码。此时，将A机房中的50％的流量全部导入B机房，此时A机房中不存在流量，且老代码失效，无法运行，相当于将A机房空出来，此时，将新代码导入A机房中，此时的状态为：A机房无流量，但有全部的新代码，B中存在100％的流量，以及全部的老代码，随后将B中的流量逐渐导入A机房中，观察A机房的运行情况，如果运行正常，则将流量全部导入A中，此时B机房为空，再将新代码导入B中，最后实现A、B机房都为新代码，且每个机房中均存在50％的流量，保证新代码的正常运行。

在上述新代码发布时，在发布瞬间，可能会出现同一业务处理请求同时导入到新代码和老代码上，此时，为了避免新代码和老代码同时处理一个请求，需要保证新老代码的幂等性，例如：当业务处理请求发送到老代码时，老代码将处理完的业务处理请求记录存储到数据库中；同一业务处理请求发送给新代码，系统根据上游单号以及上游ID生成下游单号，但是由于老代码已经将处理完的业务处理请求记录存储到数据库中，因此，新代码中的下游单号以及新代码的业务请求处理记录无法再存入到数据库中。

在新代码发布的瞬间，在进行查询业务时，同一个查询请求可能会同时发送给新老代码，当查询请求发送给老代码时，由于老代码中直接存储有上游单号与业务处理请求的映射关系，因此，在进行查询时，直接采用上游单号就能查询到相应的业务处理请求。当查询请求发送给新代码时，由于此时新代码中生成下游单号与数据库中存储的单号不一致，因此，此时不能采用新代码中生成的下游单号进行查询，而应该根据下游单号，限定分库分表位和主库/fo库模式，并通过上游身份id和上游单号查询业务数据库中的记录。

上述方法中，给出了根据上游单号和下游单号进行查询的方式，获取了代码发布状态后，在代码的发布期间，只能通过采用下游单号限定好分库分表位以及具体数据库后，在采用上游单号从下游单号限定的具体库表中去查询请求处理记录；待代码发布完成后，系统中就仅存在新代码，此时，可以直接采用下游单号从下游单号本身限定的具体库表中去查询请求处理记录，也可以采用上游单号从下游单号本身限定的具体库表中去查询请求处理记录。

所述获取针对业务故障切换库的业务处理请求之前，还可以包括：

获取所述上游系统中的上游单号；

根据所述上游单号确定所述下游单号。

所述根据所述上游单号确定所述下游单号，具体可以包括：

根据所述上游单号以及上游单号对应的身份ID生成虚拟单号；所述虚拟单号中包括分库分表信息；所述分库分表信息表示所述上游单号对应的业务处理请求的处理记录的存储位置；

根据所述虚拟单号生成序列号以及所述弹性位；

将所述虚拟单号、所述序列号以及所述弹性位组成所述下游单号。

分库分表：基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。在进行具体分库分表时，可以使用垂直切分，即把关系紧密(比如同一模块)的表切分出来放在一个server上。也可以使用水平切分，即把表的数据按某种规则(比如按ID散列)切分到多个数据库(server)上。实际运用中，需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。

弹性位一般为两位数字，用来表示数据库所对应的状态，例如以数字00代表数据库为业务主库对应的数据库，以数字01代表数据库为业务故障切换库对应的数据库。

在上面的方案中，业务处理请求是针对业务故障切换库的业务处理请求，即如果该业务处理请求表示某一订单号，那么上述方案中的业务处理请求可以是支付宝根据上游订单编号动态生成的支付宝交易号，还可以是上游系统的订单号，此时，具体的处理过程可以用下面的实施例进行说明。

实施例1

图2为本说明书实施例1提供的一种业务处理请求包括上游单号和下游单号的处理方法流程示意图。

如图2所示，一种业务处理请求包括上游单号和下游单号的处理方法可以用以下步骤进行说明：

S201:获取针对业务故障切换库的业务处理请求；所述业务处理请求中包括上游单号和下游单号；

S202:根据下游单号确定所述分库分表信息和待查询数据库；

S203:根据下游单号查询待查询数据库的具体表栏中是否存在业务处理请求记录；

S204:若存在，停止对所述业务处理请求进行处理；

S205:若不存在，根据所述上游单号能否从所述待查询数据库的具体表栏中查询到业务处理请求记录；

S206:若能，则停止对所述业务处理请求进行处理；

S207:若不能，则将所述业务处理请求发送给所述业务故障切换库进行处理。

例如：业务主库崩溃，业务故障切换库接替业务主库处理业务，获取转账请求Y，请求业务为：通过支付宝向淘宝商家支付80元。获取淘宝订单编号(上游单号)A以及支付宝交易单号(下游单号)B，根据下游单号得到虚拟单号以及弹性位00，从虚拟单号以及弹性位中得到待查询数据库为业务故障切换库(fo库)中的主表，根据单号B在业务故障切换库对应的数据库M中的主表中查找是否存在请求Y对应的请求处理记录Y’，若存在，证明请求Y之前已经被业务故障切换库进行了处理，并且已经处理完成，因此，则拒绝请求Y的处理请求。若根据单号B在业务故障切换库对应的数据库M中的主表中查找，发现不存在请求处理记录Y’，则证明请求Y并没有被业务故障切换库进行过处理，但是此时无法判定请求Y已经没有被处理过，因为可能会出现请求Y由主库处理，并处理完成，但是在完成瞬间主库崩溃，因此，为了避免上述的情况，在根据单号B在业务故障切换库对应的数据库M中的主表中查找，发现不存在请求处理记录Y’的情况下，还应该根据单号A从主库对应的数据库N中查找请求处理记录Y’，若存在，则证明请求Y已被主库支付？过了，则拒绝请求Y的处理请求。若根据单号A从主库对应的数据库N中查找不到请求处理记录Y’，则证明请求Y既没有被业务故障切换库处理过，也没有被业务主库处理过，因此，将业务处理请求Y发送给所述业务故障切换库进行处理。

实施例1中是获取针对业务故障切换库的业务处理请求，此时，主库已崩溃，请求中包含了上游单号和下游单号，在获取请求后，先根据上游单号或者下游单号判断业务处理请求是否被处理过，保证了一项处理请求只被处理一次。

实施例2

图3为本说明书实施例2提供的一种业务处理请求为上游单号的处理方法的流程示意图。

如图3所示，一种业务处理请求为上游单号的处理方法可以用以下步骤进行说明：

S301:获取上游系统发送的业务处理请求。

这里提到的业务处理请求指的是接收到的上游系统发出的业务请求，仅包含上游单号。例如：在淘宝上购物时，需要跳转到支付宝上进行付款操作，此时，业务处理请求指的是商品的订单编号、用户ID等信息，上游系统指的可以是淘宝系统。

S302:从业务处理请求中确定上游单号。

上游单号可以指的是商品的订单编号。

S303:根据上游单号判断下游系统中是否存在下游单号。

S304:若存在，根据所述下游单号确定分库分表位以及数据库类型；所述分库分表位为所述下游单号对应的分库分表位，所述数据库类型包括业务主库对应的第二数据库或业务故障切换库对应的第一数据库。

S305:采用下游单号直接从数据库中的具体位置查找所述业务支付请求记录或者采用所述下游单号根据所述下游单号确定所述下游单号对应的分库分表位以及数据库类型查找所述业务支付请求记录；

S306:若不存在，则继续判断采用上游单号从第二数据库中能否查询到所述业务支付请求记录；

S307:若能，则停止对所述业务支付请求的处理；

S308:若不能，则根据所述上游单号以及上游单号对应的身份ID生成虚拟单号；

S309:根据所述虚拟单号生成序列号；

S310:将所述虚拟单号、所述序列号组成下游单号；

S311:根据所述下游单号对所述业务处理请求进行处理，并将上游单号、下游单号以及该业务处理请求存储到业务故障切换库对应的第一数据库中。

例如：获取客户端通过淘宝应用发过来的支付请求，根据支付请求对应的淘宝订单号A以及用户ID，首先判断在支付宝系统的数据库中中是否存在订单号A对应的内部单号B，若存在，根据内部单号完成支付操作，支付宝完成支付操作后，将订单号A、用户ID、内部单号B以及支付完成记录都存储到数据库中，此时数据库中存在的对应关系是：上游单号→下游单号，下游单号→支付记录，即可以通过上游单号查询到支付宝交易号(上游单号→下游单号)，也可以通过下游单号直接查询到支付记录(下游单号→支付记录)，因此，根据上面的对应关系可以直接根据上游单号查询到支付记录，对应关系为：上游单号→支付记录，即在查询时，既可以通过上游单号查询到交易记录，也可以通过下游单号查询到交易记录。

若在支付宝系统的数据库中不存在订单号A对应的内部单号B，那么会出现的两种可能是：一、该支付请求未被处理过；二、该支付请求未被业务故障切换库处理过，但是已被业务主库处理被存储到第二数据库，由于主库崩溃，没有及时反馈处理结果。因此，当支付宝系统的数据库中不存在订单号A对应的内部单号B时，需要继续判断采用上游单号判断第二数据库中是否能查询到所述业务支付请求记录，若能，表示该支付请求已被主库处理过，因此，停止对该支付请求的处理。若采用上游单号判断第二数据库中不能查询到所述业务支付请求记录，表示该支付请求未被业务主库和业务故障切换库进行过处理，因此，将该支付请求发送给业务故障切换库进行处理。

上述方案中，在实际运用时，还可能会出现由于下游业务系统的特殊需求，不能直接以我方单号请求下游，而只能以下游规定的长度模式等信息生成特定单号请求下游。此时需要根据已生成我方单号再次生成下游单号。由于新生成的下游单号同样需要标识弹性位，所以需要根据已生成我方单号动态分配。

例如：某购物平台发送优惠券，由于优惠券一般为六位数字，且需要从优惠券中看出具体的数据库存储位置，因此，此时需要根据上游单号生成的下游单号，先确定弹性位，利用弹性位固定0库0表生成sequence(序列)，然后将弹性位(两位数字，例如00或01)采用1-9中的某两个数字分别表示弹性位中的00或01，例如：利用弹性位固定0库0表生成sequence(序列)为0876，由下游单号确定出的弹性位为：00，采用9代表弹性位00作为序列前缀，则生成的优惠券单号为：90876。

在这种情况下，由于由下游单号确定了具体的库表位置，因此，在进行优惠券领取或者查询时，仍然能够保证业务处理的幂等性。

基于同样的思路，本说明书实施例还提供了上述方法对应的装置。图4为本说明书实施例提供的对应于图1的一种业务请求处理装置的结构示意图。如图4所示，该装置可以包括：

业务处理请求获取模块401，用于获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

判断模块402，用于确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；

业务处理停止模块403，用于若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

处理模块404，用于若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

可选的，所述判断模块402，具体可以包括：

下游单号第一确定单元，用于确定所述业务处理请求中的下游单号；所述业务处理请求中包括上游单号以及下游单号；所述下游单号表示上游系统中的上游单号在下游系统中生成的内部单号；所述上游系统表示生成上游单号的系统；所述下游系统表示与所述上游系统实现信息交互的系统；所述上游单号与所述下游单号一一对应；

待查询数据库确定单元，用于根据所述下游单号确定待查询数据库；

判断单元，用于查询所述待查询数据库中是否存在所述下游单号对应的业务处理请求的处理记录。

可选的，所述待查询数据库确定单元，具体可以包括：

序列号识别子单元，用于从所述下游单号中识别得到序列号；

虚拟单号识别子单元，用于根据所述序列号识别得到虚拟单号；

数据库弹性位识别子单元，用于从所述虚拟单号中识别得到数据库弹性位；所述数据库弹性位表示所述待查询数据库类型；

待查询数据库确定子单元，用于根据所述数据库弹性位，确定所述待查询数据库。

可选的，所述装置，还可以包括：

存储模块，用于将所述业务处理请求的处理记录存储在所述数据库中。

可选的，所述装置，还包括：

查询请求获取模块，用于获取查询请求；所述查询请求包括所述上游单号或者所述下游单号；

业务处理请求记录查找模块，用于根据所述查询请求从所述待查询数据库中查找所述业务处理请求记录。

可选的，所述业务处理请求记录查找模块，具体可以包括：

代码发布状态获取单元，用于获取所述业务故障切换库对应的代码的发布状态；

判断单元，用于查询所述代码是否已发布完成；

下游单号查询单元，用于若所述代码未发布完成，则根据所述下游单号确定所述待查询数据库，并根据所述上游单号从所述待查询数据库中查询所述业务处理请求记录；

查询单元，用于若所述代码已发布完成，则根据所述上游单号或者所述下游单号从所述待查询数据库中查询所述业务处理请求记录。

可选的，所述装置，还可以包括：

上游单号获取单元，用于获取所述上游系统中的上游单号；

下游单号第二确定单元，用于根据所述上游单号确定所述下游单号。

可选的，所述下游单号确定单元，具体可以用于：

根据所述上游单号以及上游单号对应的身份ID生成虚拟单号；所述虚拟单号中包括分库分表信息；所述分库分表信息表示所述上游单号对应的业务处理请求的处理记录的存储位置；

根据所述虚拟单号生成序列号以及所述弹性位；

第二确定子单元将所述虚拟单号、所述序列号以及所述弹性位组成所述下游单号。

在具体应用中，当获取的业务处理请求仅为上游单号时，该业务请求处理装置还包括业务处理请求获取模块、幂等模块、判断模块、业务处理模块和存储模块。其中业务处理请求获取模块，可以用于动态获取不同业务请求，对不同业务的fo需求做不同处理，比如fo只需要支持部分业务则通过此模块动态识别。幂等模块，用于负责业务切换fo的一致性，保证同一请求由于重发机制分别被正常模式和fo模式分别处理但是结果仍能保证幂等性。判断模块，用于查询数据库中是否存在业务处理请求记录。存储模块，用于负责跟业务主库或业务故障切换库进行交互，负责查询、插入、存储等操作。

更为具体的，幂等模块是由上游单号、上游ID以及下游单号请求调用的，当判定业务故障切换库中存在业务处理记录时，判定系统已经针对该业务处理请求调用过幂等模块，此时，直接查询第一数据库中的业务处理请求记录即可；当判定业务故障切换库中不存在业务处理记录，并且通过上游单号从主库对应的第二数据库中没有发现业务处理请求记录，则证明对于该业务处理请求并没有被处理过，也没有申请调用过幂等模块，此时，同意采用上游单号、上游ID以及下游单号请求调用幂等模块，并将处理完的上游单号、上游ID、下游单号以及业务处理请求记录均存储到存储模块，方便查询。

基于同样的思路，本说明书实施例还提供了上述方法对应的设备。

图5为本说明书实施例提供的对应于图1的一种业务处理请求处理设备的结构示意图。如图5所示，设备500可以包括：

至少一个处理器510；以及，

与所述至少一个处理器通信连接的存储器530；其中，

所述存储器530存储有可被所述至少一个处理器510执行的指令520，所述指令被所述至少一个处理器510执行，以使所述至少一个处理器510能够：

获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；

若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

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

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

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

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

Claims (17)

1.一种业务请求处理方法，包括：

获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；所述处理记录用于证明所述业务处理请求是否被所述业务主库或者所述业务故障切换库处理过；

若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

2.如权利要求1所述的方法，所述确定数据库中是否存在所述业务处理请求的处理记录，具体包括：

确定所述业务处理请求中的下游单号；所述业务处理请求中包括上游单号以及下游单号；所述下游单号为上游系统中的上游单号在下游系统中生成的内部单号；所述上游系统为生成上游单号的系统；所述下游系统为与所述上游系统实现信息交互的系统；所述上游单号与所述下游单号一一对应；

根据所述下游单号确定待查询数据库；

查询所述待查询数据库中是否存在所述下游单号对应的业务处理请求的处理记录。

3.如权利要求2所述的方法，所述根据所述下游单号确定待查询数据库，具体包括：

根据所述下游单号确定数据库弹性位；所述数据库弹性位表示所述待查询数据库类型；

当所述数据库弹性位表示所述待查询数据库类型为业务故障切换库对应的第一数据库时，将所述第一数据库确定为所述待查询数据库；

当所述数据库弹性位表示所述待查询数据库类型为业务主库对应的第二数据库时，将所述第二数据库确定为所述待查询数据库。

4.如权利要求2所述的方法，所述将所述业务处理请求发送给所述业务故障切换库进行处理之后，还包括：

将所述业务处理请求的处理记录存储在所述第一数据库中。

5.如权利要求4所述的方法，所述将所述业务处理请求的处理记录存储在所述第一数据库中之后，还包括：

获取查询请求；所述查询请求包括所述上游单号或者所述下游单号；

根据所述查询请求从待查询数据库中查找所述业务处理请求记录。

6.如权利要求5所述的方法，所述根据所述查询请求从所述待查询数据库中查找所述业务处理请求记录，具体包括：

获取所述业务故障切换库对应的代码的发布状态；

根据所述发布状态，查询所述代码是否已发布完成；

若所述代码未发布完成，则根据所述下游单号确定所述待查询数据库，并根据所述上游单号从所述待查询数据库中查询所述业务处理请求记录；

若所述代码已发布完成，则根据所述上游单号或者所述下游单号从所述待查询数据库中查询所述业务处理请求记录。

7.如权利要求2所述的方法，所述获取针对业务故障切换库的业务处理请求之前，还包括：

获取所述上游系统中的上游单号；

根据所述上游单号确定下游单号。

8.如权利要求7所述的方法，所述根据所述上游单号确定所述下游单号，具体包括：

根据所述上游单号以及上游单号对应的身份ID生成虚拟单号；所述虚拟单号中包括分库分表信息；所述分库分表信息表示所述上游单号对应的业务处理请求的处理记录的存储位置；

根据所述虚拟单号生成序列号以及弹性位；

将所述虚拟单号、所述序列号以及所述弹性位组成所述下游单号。

9.一种业务请求处理装置，包括：

业务处理请求获取模块，用于获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

判断模块，用于确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；所述处理记录用于证明所述业务处理请求是否被所述业务主库或者所述业务故障切换库处理过；

业务处理停止模块，用于若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

处理模块，用于若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。

10.如权利要求9所述的装置，所述判断模块，具体包括：

第一确定单元，用于确定所述业务处理请求中的下游单号；所述业务处理请求中包括上游单号以及下游单号；所述下游单号为上游系统中的上游单号在下游系统中生成的内部单号；所述上游系统为生成上游单号的系统；所述下游系统为与所述上游系统实现信息交互的系统；所述上游单号与所述下游单号一一对应；

待查询数据库确定单元，用于根据所述下游单号确定待查询数据库；

判断单元，用于查询所述待查询数据库中是否存在所述下游单号对应的业务处理请求的处理记录。

11.如权利要求10所述的装置，所述待查询数据库确定单元，具体包括：

弹性位确定子单元，用于根据所述下游单号确定数据库弹性位；所述数据库弹性位表示所述待查询数据库类型；

待查询数据库确定子单元，用于当所述数据库弹性位表示所述待查询数据库类型为业务故障切换库对应的第一数据库时，将所述第一数据库确定为所述待查询数据库；当所述数据库弹性位表示所述待查询数据库类型为业务主库对应的第二数据库时，将所述第二数据库确定为所述待查询数据库。

12.如权利要求10所述的装置，所述装置，还包括：

存储模块，用于将所述业务处理请求的处理记录存储在所述数据库中。

13.如权利要求12所述的装置，所述装置，还包括：

查询请求获取模块，用于获取查询请求；所述查询请求包括所述上游单号或者所述下游单号；

业务处理请求记录查找模块，用于根据所述查询请求从待查询数据库中查找所述业务处理请求记录。

14.如权利要求13所述的装置，所述业务处理请求记录查找模块，具体包括：

代码发布状态获取单元，用于获取所述业务故障切换库对应的代码的发布状态；

判断单元，用于根据所述发布状态，查询所述代码是否已发布完成；

下游单号查询单元，用于若所述代码未发布完成，则根据所述下游单号确定所述待查询数据库，并根据所述上游单号从所述待查询数据库中查询所述业务处理请求记录；

查询单元，用于若所述代码已发布完成，则根据所述上游单号或者所述下游单号从所述待查询数据库中查询所述业务处理请求记录。

15.如权利要求11所述的装置，所述装置，还包括：

上游单号获取单元，用于获取所述上游系统中的上游单号；

第二确定单元，用于根据所述上游单号确定所述下游单号。

16.如权利要求15所述的装置，所述上游单号确定单元，具体用于：

根据所述上游单号以及上游单号对应的身份ID生成虚拟单号；所述虚拟单号中包括分库分表信息；所述分库分表信息表示所述上游单号对应的业务处理请求的处理记录的存储位置；

根据所述虚拟单号生成序列号以及所述弹性位；

第二确定子单元将所述虚拟单号、所述序列号以及所述弹性位组成所述下游单号。

17.一种业务请求处理设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

获取针对业务故障切换库的业务处理请求；所述业务处理请求为业务主库崩溃后系统发送的请求；

确定数据库中是否存在所述业务处理请求的处理记录；所述数据库包括第一数据库和第二数据库；所述第一数据库为业务故障切换库对应的存储处理记录的数据库；所述第二数据库为业务主库对应的存储处理记录的数据库；所述处理记录用于证明所述业务处理请求是否被所述业务主库或者所述业务故障切换库处理过；

若所述数据库中存在所述业务处理请求的处理记录，则停止对所述业务处理请求进行处理；

若所述数据库中不存在所述业务处理请求的处理记录，则将所述业务处理请求发送给所述业务故障切换库进行处理。