CN107577700A - 数据库容灾的处理方法及装置 - Google Patents

Abstract

本说明书披露的实施例提供一种数据库容灾的处理方法及装置，在一种数据库的容灾处理方法中，服务器接收用户终端发送的业务请求消息，并根据该消息中的参数生成第一索引，然后在备数据库中的黑名单中查询是否存在与该第一索引匹配的数据记录。当黑名单中已存在与该第一索引匹配的数据记录时，进而判断数据记录中的状态参数的类型是否与服务器接收到业务请求消息时主数据库的工作状态相同，如果不同，则将业务请求消息进行抛弃处理。

Description

数据库容灾的处理方法及装置

技术领域

本说明书披露的多个实施例涉及数据库的信息安全技术领域，尤其涉及一种数据库容灾的处理方法及装置。

背景技术

目前，很多应用的数据都存储在数据库中，数据库容灾可以提高数据的安全性和持续可用性。如，建立一个主数据库和备数据库，当主数据库因某些情况(如，主数据库所处的地理位置发生自然灾害)出现故障而不能工作时,切换至备数据库工作，以保障应用系统的高可用性。为了兼容大容量，高并发请求，大部分应用系统都部署了多机器集群。当数据库容灾时，集群中的所有服务器都会接收到数据库容灾的状态，从而切换至备数据库进行工作。但由于集群中的服务器接收到数据库容灾的状态的时间可能不相同，使集群中的服务器感知到的数据库状态不相同，如，已接收到数据库容灾的状态的服务器感知到的主数据库状态为容灾状态，而暂未接收到数据库容灾的状态的服务器感知到的主数据库状态为非容灾状态。此时，如果因定时任务(如基金定投)消息重发或者网络抖动导致请求消息重发，会出现两个相同的请求消息到达两台不同服务器的情况。如果这两台服务器感知的数据库状态不一致，就会在主数据库和备数据库对这个请求消息分别进行处理，造成用户损失(如一个付款请求扣了两次钱)。

对此，应用系统通常将服务器接收到的请求消息存储至tair缓存中，当另一服务器接收到相同的请求消息并将其存储至tair缓存中时，tair缓存中会因存储有相同的请求消息的数据而拒绝存储并告知此服务器，此服务器将终止对相同的请求消息的处理。这样就实现了幂等操作，即任意多次执行所产生的影响与一次执行的影响相同，从而避免了对一个请求消息进行多次处理。但是，由于tair缓存也可能出现不可用或者丢失的情况，因此，需要提供更可靠的数据库容灾的处理的方案。

发明内容

本说明书描述了一种数据库容灾的处理方法及装置，实现了利用备数据库中存储的黑名单表对幂等进行控制，从而提高了数据库信息的安全性。

第一方面，提供了一种数据库容灾的处理方法，包括：

接收用户终端发送的业务请求消息，所述业务请求消息包括第一参数；

根据所述第一参数，生成第一索引；

当备数据库中的黑名单中已存在与所述第一索引匹配的数据记录时，确定所述数据记录中的第二参数的类型是否与第一类型相同，所述第一类型为接收到所述业务请求消息时主数据库的工作状态；

如果所述数据记录中的第二参数的类型与第一类型不同，则将所述业务请求消息进行抛弃处理。

第二方面，提供了一种数据库容灾的处理装置，包括：

接收单元，用于接收用户终端发送的业务请求消息，所述业务请求消息包括第一参数；

第一生成单元，用于根据所述第一参数，生成第一索引；

确定单元，用于当备数据库中的黑名单中已存在与所述第一索引匹配的数据记录时，确定所述数据记录中的第二参数的类型是否与第一类型相同，所述第一类型为接收到所述业务请求消息时主数据库的工作状态；

处理单元，用于如果所述数据记录中的第二参数的类型与第一类型不同，则将所述业务请求消息进行抛弃处理。

本说明书提供的数据库容灾的处理方法及装置，在备数据库中创建黑名单，主数据库和备数据库共用此黑名单。通过接收用户终端发送的业务请求消息，根据该消息中的第一参数生成第一索引，并根据第一索引查询黑名单中是否存在与第一索引匹配的数据记录，当存在时，进一步判断该数据记录中的第二参数的类型是否与接收到业务请求消息时主数据库的工作状态相同，如果不相同，就对该业务请求消息进行抛弃处理，避免对同一业务请求消息进行重复处理，从而实现了对主数据库和备数据库跨库的幂等操作，并提高了幂等操作的可靠性，进而提高了应用系统的可用性及降低了给用户造成损失的风险。

附图说明

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

图1为本说明书披露的一个实施例提供的数据库容灾的处理方法的应用场景示意图；

图2为本说明书披露的一个实施例提供的数据库容灾的处理方法流程图；

图3为本说明书披露的一个实施例提供的转入余额宝业务的应用页面图；

图4为本说明书披露的另一个实施例提供的数据库容灾的处理方法流程图；

图5为本说明书披露的一个实施例提供的数据库容灾的处理装置示意图。

具体实施方式

下面结合附图，对本说明书披露的多个实施例进行描述。

图1为本说明书披露的一个实施例提供的数据库容灾的处理方法的应用场景示意图。图1中，多个用户终端(如，用户终端可以为手机、平板电脑、可穿戴智能设备等)可以向服务器集群(如，服务器集群可以为支付宝应用的服务器集群等)中的某一服务器发送业务请求消息(如，转账请求等)，服务器集群中的数据存储在主数据库和备数据库中。

本说明书披露的一个实施例提供的数据库容灾的处理方法可应用在主数据库容灾状态或者非容灾状态。下面以服务器集群中的某一服务器接收用户终端发送的业务请求消息为例进行说明。

例如，当主数据库处于容灾状态时，服务器接收到用户终端发送的业务请求消息。服务器接收该业务请求消息，从业务请求消息中获取第一参数。第一参数可包括用于表示业务请求消息的标识、用户终端的标识、用户标识以及业务参数。然后，根据第一参数包括的用于表示业务请求消息的标识、用户终端的标识、用户标识以及业务参数，服务器生成第一索引。第一索引用于对业务请求消息所请求的业务进行唯一表示，服务器根据第一索引在备数据库中的黑名单中查询。当备数据库中的黑名单中已存在与第一索引匹配的数据记录时，服务器进一步判断数据记录中的第二参数的类型是否与第一类型相同。其中，第一类型为服务器接收到业务请求消息时主数据库的工作状态。如果数据记录中的第二参数的类型与第一类型不同，则服务器将业务请求消息进行抛弃处理。第二参数为数据记录中主数据库的工作状态。

其中，主数据库的工作状态包括容灾状态和非容灾状态。

同理，当主数据库处于非容灾状态下，服务器也可按照前述过程对接收到的业务请求消息进行处理，在此不再复述。

采用本说明书披露的一个实施例提供的数据库容灾的处理方法，在备数据库中创建黑名单，主数据库和备数据库共用此黑名单，避免服务器在主数据库和备数据库中对同一业务请求消息进行重复处理，从而实现了对主数据库和备数据库跨库的幂等操作，并提高了幂等操作的可靠性。

图2为本说明书披露的一个实施例提供的数据库容灾的处理方法流程图。所述方法的执行主体可以为具有处理能力的设备：服务器或者系统或者装置，如，图1中的服务器集群中的任一服务器，如图2所示，所述方法具体包括：

步骤S210，接收用户终端发送的业务请求消息，该消息包括第一参数。

需要说明的是，第一参数可以包括表示业务请求消息的标识(如，业务请求消息的序列号等)、用户终端的标识(如，用户中终端的国际移动设备身份码(InternationalMobile Equipment Identity，IMEI)等)、用户标识(如，用户用于发起业务请求的账户的标识等)以及业务参数(如，订单金额等)。

本步骤中的执行主体以支付宝应用的服务器集群中的任一服务器为例，用户终端以手机为例。用户可以通过操作用户终端向服务器发起请求，如将资金实时转入余额宝请求、定期将资金转入余额宝请求和从余额宝中提现请求等。

具体地，用户终端安装有支付宝应用，用户通过用户终端登录支付宝账户后，用户希望使用支付宝的账户余额向余额宝中转入100元。用户终端接收用户输入的操作，例如，用户在支付宝应用的页面中选择待转入余额宝中的金额、转入账户等。用户终端根据用户输入的操作生成业务请求，该业务请求的支付页面如图3所示。

用户点击确认并校验身份成功后，用户终端将向服务器发送业务请求消息。该消息包括第一参数，且第一参数包括表示业务请求消息的标识(如，转入请求的唯一标识号：0123456789)，用户终端的标识(如，转入来源：00)，用户标识(如，用户身份识别号码(Identity，ID)：208877777777)，业务参数(如转入金额：100)中的至少两个参数。

步骤S220，根据第一参数，生成第一索引。

具体的，服务器在接收到业务请求消息后，从该消息中获取第一参数。服务器根据第一参数，生成一个或多个第一索引。其中，第一索引可由多种形式表示，例如，第一索引可为组合元素索引，由多个元素构成；或者，第一索引可为单一元素索引，由一个元素构成。

本步骤中，服务器根据第一参数，生成第一索引的过程为：

首先，服务器从第一参数包括的表示业务请求消息的标识、用户终端的标识、用户标识以及业务参数中选择出至少两个参数。

然后，服务器将选择的至少两个参数进行拼接加密处理，得到业务索引值。例如，从第一参数中选择转入请求的唯一标识号：0123456789和转入来源：00进行拼接，得到拼接后的参数：012345678900。

在对选择的至少两个参数进行拼接处理后，可进一步对拼接后的参数进行加密处理，如，采用信息-摘要算法(Message-Digest Algorithm 5，MD5)对拼接后的参数进行加密处理，进而得到业务索引值。

需要说明的是，因转入请求的标识号0123456789是唯一的，所以得到的索引值也是唯一的。同时，还可以将0123456789和00拼接为000123456789，或者采用其他的拼接加密方式，只要得到的业务索引值是唯一的即可，本说明书披露的多个实施例对此不作限定。

可以理解的是，对参数进行拼接、加密处理也可不按照前述的顺序进行。例如，可对参数先进行加密处理后，再进行拼接处理；或者，可只对参数进行拼接处理等等。

最后，服务器根据第一参数中的业务参数，确定与该业务参数匹配的业务表以及业务表中的索引名称。服务器将业务索引值、业务表的名称及索引名称中的一个和多个进行组合处理，得到第一索引。

例如，业务参数中包括转入金额：100，确定与该业务参数匹配的业务表是trans_out_data_tbl(如，账户余额转出表)和trans_in_data_tbl(如，余额宝转入表)，且trans_out_data_tbl的索引名称包括index1和index2，trans_in_data_tbl的索引名称包括index3。业务索引值为012345678900。由于根据业务参数确定出多个业务表以及多个索引名称，因此，服务器可将业务索引值与每个业务表以及每个业务表的索引名称分别进行组合处理，得到多个第一索引，该第一索引即为组合元素索引。例如，第一索引包括“012345678900、trans_out_data_tbl和index1”的组合、“012345678900、trans_out_data_tbl和index2”的组合、“012345678900、trans_in_data_tbl和index3”的组合，如表1所示。

表1

编号	业务索引值	业务表的名称	索引名称
				索引1	012345678900	trans_out_data_tbl	index1
索引2	012345678900	trans_out_data_tbl	index2
				索引3	012345678900	trans_in_data_tbl	index3

又例如，根据业务参数，确定与该业务参数匹配的业务表是表A，且索引名称为A1，且黑名单中的业务表只有表A。业务索引值为001，因黑名单中的业务表和索引名称都只有一种，所以第一索引可以为业务索引值，则该第一索引即为单一元素索引。

再例如，根据业务参数，确定与该业务参数匹配的业务表是表B，且索引名称为B1和B2，且黑名单表中的业务表只有表B。因黑名单中的业务表只有一种，所以第一索引可以为“业务索引值和索引名称B1”的组合，以及“业务索引值和索引名称B2”的组合。即该第一索引即为组合元素索引。

再例如，根据业务参数，确定与该业务参数匹配的业务表是表A和表B，且表A和表B中的索引名称均为index，且黑名单中的多个业务表均只有一个索引名称，每个业务的索引名称均相同，所以第一索引可以为“业务索引值和表A的名称”的组合，以及“业务索引值和表B的名称”的组合。同理，该第一索引也为组合元素索引。

需要说明的是，前述的第一索引均是唯一索引，根据一个第一索引最多只能在黑名单中找到一条与之匹配的数据记录。

步骤S230，当备数据库中的黑名单中已存在与第一索引匹配的数据记录时，确定数据记录中的第二参数的类型是否与第一类型相同，第一类型为接收到业务请求消息时主数据库的工作状态。

本步骤中，主数据库的工作状态包括容灾状态和非容灾状态。容灾状态即此时服务器通过备数据库对业务请求消息进行处理；非容灾状态即此时服务器通过主数据库对业务请求消息进行处理。相应的，第二参数的类型包括非容灾状态，如NM(Normal)和容灾状态FO(Fail Over)。需要说明的是，第二参数的类型还可以用其他的符号，包括字母或数字进行表示，本说明书披露的多个实施例对此不作限定。具体的，在备数据库中的黑名单中，查找是否存在与第一索引匹配的数据记录。当备数据库中的黑名单中已存在与第一索引匹配的数据记录时，确定数据记录中的第二参数的类型(如NM或FO)是否与第一类型相同，第一类型为接收到业务请求消息时主数据库的工作状态，如容灾状态或非容灾状态。

例如，第一索引为“012345678900、trans_in_data_tbl和Index1”的组合，且备数据库中的黑名单中已存在与第一索引匹配的数据记录，如表2所示，则需确定数据记录中的第二参数的类型是否与第一类型相同。

表2

主键	业务索引值	业务表名	索引名称	数据类型
					201706221111111	012345678900	trans_in_data_tbl	Index1	NM

表2中，主键(id)”、“业务索引值”、“业务表名”、“索引名称”和“数据类型”的字符类型均可以为VARCHAR2(32)。其中，“主键(id)”用于唯一的表示黑名单中的某一条记录，且不能为空，主键的键值“201706221111111”由数据库系统随机生成。“业务索引值(Unique_key)”与上述中的业务索引值相对应，“索引名称”与上述中的索引名称相对应。“数据类型(data_type)”为上述中的第二参数的类型，如“NM”，表示非容灾状态。

又例如，第一索引包括表1中的三个索引，且备数据库中的黑名单中已存在与第一索引匹配的数据记录，如表3所示，则需确定该数据记录中的第二参数的类型是否与第一类型相同。且可以只判断与索引1、索引2和索引3中任一索引对应的数据记录中，第二参数的类型是否与第二类型相同。需要说明的是，因为在黑名单中针对某个业务消息进行数据记录的插入是一个数据库事务，也就是说，与这三个索引匹配的数据记录要么否会插入黑名单，要么都不会插入黑名单。数据库事务(Database Transaction)，是指作为单个逻辑工作单元执行的一系列操作，要么完整地执行，要么完全地不执行。事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。

表3

需要说明的是，可以预先在备数据库中创建黑名单。黑名单中还可以对数据记录的插入时间进行记录，并且只保留最近一段时间内的数据记录，如最近两个月或最近一个月，并对超出这段时间的数据记录进行清除。黑名单中记录的插入时间的字符类型可以为DATE。

步骤S240，如果数据记录中的第二参数的类型与第一类型不同，则将所述业务请求消息进行抛弃处理。

具体的，如果接收到业务请求消息时主数据库的工作状态为容灾状态，即第一类型为容灾状态，而数据记录中的第二参数的类型为非容灾状态，则将该业务请求消息进行抛弃处理，即终止对该业务请求消息的处理进程。例如，第一索引为“012345678900、trans_in_data_tbl和Index1”，与第一索引匹配的数据记录中第二参数的类型为NM，如表2所示，而第一类型为FO，则将与第一索引对应的业务请求消息进行抛弃处理。又例如，表1中的索引1为“012345678900、trans_out_data_tbl和Index1”，与索引1匹配的数据记录中第二参数的类型为NM，如表3所示，而第一类型为FO，那么不需要继续对表1中的索引2和索引3执行相关操作，而是将与第一索引对应的业务请求消息进行抛弃处理。

同理，如果接收到业务请求消息时主数据库的工作状态为非容灾状态，即第一类型为非容灾状态，而数据记录中的第二参数的类型为容灾状态，则将该业务请求消息进行抛弃处理，即终止对该业务请求消息的处理进程。例如，第一索引为“012345678900、trans_in_data_tbl和Index1”，与第一索引匹配的数据记录中第二参数的类型为FO，如表4所示，而第一类型为NM，则将与第一索引对应的业务请求消息进行抛弃处理。

表4

主键	业务索引值	业务表名	索引名称	数据类型
					201706221111111	012345678900	trans_in_data_tbl	Index1	FO

可选的，在步骤S240之后，还可以包括：如果数据记录中的第二参数的类型与第一类型相同，则将业务请求消息中包括的第一参数存储至主数据库或备数据库中。

具体的，如果接收到业务请求消息时主数据库的工作状态为非容灾状态，即第一类型为非容灾状态，且数据记录中的第二参数的类型也为非容灾状态，则不将与第一索引匹配的数据记录存储至黑名单，并根据第一参数组装业务数据，并插入到主数据库的业务数据表中。例如，第一索引为“012345678900、trans_in_data_tbl和Index1”，与第一索引匹配的数据记录中第二参数的类型为NM，如表2所示，且第一类型为NM，则不将与第一索引匹配的数据记录存储至黑名单，并根据第一参数组装业务数据，并插入到主数据库的业务数据表中，如表5所示。

表5

主键	用户ID	请求的唯一标识号	转入来源	转入金额
					201706221111111	00	0123456789	00	Index1

同理，如果接收到业务请求消息时主数据库的工作状态为容灾状态，即第一类型为容灾状态，且数据记录中的第二参数的类型也为容灾状态，则不将与第一索引匹配的数据记录存储至黑名单，且将该业务请求消息中包括的第一参数存储至备数据库中，并根据第一参数组装业务数据，并插入到备数据库的业务数据表中。例如，第一索引为“012345678900、trans_in_data_tbl和Index1”，与第一索引匹配的数据记录中第二参数的类型为FO，如表4所示，且第一类型为FO，则不将与第一索引匹配的数据记录存储至黑名单，并根据第一参数组装业务数据，并插入到主数据库的业务数据表中，如表5所示。

需要说明的是，在步骤S230之后，还可以包括：当备数据库中的黑名单中未存在与所述第一索引匹配的数据记录时，生成与所述第一索引匹配的数据记录，并将生成的数据记录存储至黑名单中。然后，将该业务请求消息中包括的第一参数存储至数据库。例如，第一索引为“012345678900、trans_in_data_tbl和Index1”，经查找发现黑名单中未存在与第一索引匹配的数据记录，则生成与第一索引匹配的数据记录，将第二参数的类型设置为FO，如表4所示，并将表4中的数据记录存储至黑名单中。然后，将该业务请求消息中包括的第一参数存储至备数据库。此外，上述的将该业务请求消息中包括的第一参数存储至数据库(如，主数据库或备数据库)中，具体包括：当数据库中未存储第一参数时，则将第一参数存储至数据库。例如，根据第一参数中的业务请求消息的标识(如，请求的唯一标识号)在数据库的业务表中进行查询，如果返回字段I，则表示可以将业务数据插入业务数据表，并将业务数据插入业务数据表中。如果返回字段S，则表示可以业务数据表中已存在该数据，不需要再次插入，则不执行将业务数据插入业务数据表的操作。

由上可知，本说明书披露的一个实施例提供的数据库容灾的处理方法，在备数据库中创建黑名单，主数据库和备数据库共用此黑名单。通过接收用户终端发送的业务请求消息，根据该消息中的第一参数生成第一索引，并根据第一索引查询黑名单中是否存在与第一索引匹配的数据记录，当存在时，进一步判断该数据记录中的第二参数的类型是否与接收到业务请求消息时主数据库的工作状态相同，如果不相同，就对该业务请求消息进行抛弃处理，避免对同一业务请求消息进行重复处理，从而实现了对主数据库和备数据库跨库的幂等操作，并提高了幂等操作的可靠性，进而提高了应用系统的可用性及降低了给用户造成损失的风险。

图4为本说明书披露的另一个实施例提供的数据库容灾的处理方法示意图。所述方法的执行主体可以为具有处理能力的设备：服务器或者系统或者装置，如，图1中的服务器集群中的任一服务器。

本方法中的执行主体以支付宝应用的服务器集群中的任一服务器为例，用户终端以安装有支付宝应用的手机为例，业务请求消息使用支付宝将资金实时转入余额宝生成的业务请求消息为例。本方法的应用场景包括容灾场景和非容灾场景。

如图4所示。在非容灾场景下，用户使用手机在支付宝应用的页面选择转入余额宝的金额(如，100元等)和转入账户(如，支付宝的账户余额、中国银行等)。用户终端根据用户输入的操作生成业务请求。

用户点击确认并校验身份成功后，用户终端将向服务器发送业务请求消息，此时服务器接收到业务请求消息时主数据库的工作状态为非容灾状态(NM)。该消息包括第一参数，且第一参数包括表示业务请求消息的标识(如，转入请求的唯一标识号：0123456789)，用户终端的标识(如，转入来源：00)，用户标识(如，用户身份识别号码(Identity，ID)：208877777777)，业务参数(如转入金额：100)中的至少两个参数。

服务器接收到此业务请求消息后，对第一参数(也称为入口参数)进行校验以及进行其他的业务校验。其中，对第一参数的校验可以包括：根据用户终端的标识验证该终端设备是否合法，根据用户标识校验该用户的账户是否合法。其他的业务校验可以包括：判断转入账户中的资金数额是否不小于转入余额宝的金额。例如，当用户选择的转入账户为支付宝的账户余额时，如果服务器判断支付宝的账户余额(如，2000元)大于转入余额宝的金额(如，100元)，则继续执行将资金转入余额宝的操作。如果服务器判断支付宝的账户余额(如，20元)小于转入余额宝的金额(如，100元)，则停止资金的转入进程，并向终端返回相关消息(如：所选账户余额不足，请选择其他账户)。

服务器在对业务请求消息进行前置校验后，根据第一参数包括的用于表示业务请求消息的标识、用户终端的标识、用户标识以及业务参数，生成第一索引。具体的，从第一参数中选择至少两个参数。然后，将选择的至少两个参数进行拼接处理，得到业务索引值。并根据第一参数中的业务参数，确定与该业务参数匹配的业务表以及业务表中的索引名称。然后将业务索引值、业务表的名称及索引名称中的一个和多个进行组合处理，得到第一索引。

服务器判断备数据库中的黑名单中是否已存在与第一索引匹配的数据记录。当备数据库中的黑名单中已存在与第一索引匹配的数据记录时，确定数据记录中的第二参数的类型是否与第一类型(非容灾场景下为NM)相同，第一类型为接收到业务请求消息时主数据库的工作状态。如果不同，即第二参数的类型为容灾状态(FO)，则将该业务请求消息进行抛弃处理。如果相同，即第二参数的类型也为非容灾状态(NM)，则将业务请求消息中包括的第一参数存储到主数据库中。

而当备数据库中的黑名单中未存在与第一索引匹配的数据记录时，生成与第一索引匹配的数据记录，并将生成的数据记录存储至黑名单中。然后，将该业务请求消息中包括的第一参数(如第一参数包括的用于表示业务请求消息的标识、用户终端的标识、用户标识以及业务参数)存储至主数据库中。

在容灾场景下，用户使用手机在支付宝应用的页面选择转入余额宝的金额(如，100元等)和转入账户(如，支付宝的账户余额、中国银行等)。用户终端根据用户输入的操作生成业务请求。用户点击确认并校验身份成功后，用户终端将向服务器发送业务请求消息，此时服务器接收到业务请求消息时主数据库的工作状态为容灾状态(FO)。服务器接收到此业务请求消息后，对第一参数进行校验以及进行其他的业务校验。对这段内容的描述具体可参见上述对非容灾场景的描述，在此不作赘述。

服务器在对业务请求消息进行前置校验后，根据业务请求消息中的第一参数生成第一索引。服务器判断备数据库中的黑名单中是否已存在与第一索引匹配的数据记录。当备数据库中的黑名单中已存在与第一索引匹配的数据记录时，确定数据记录中的第二参数的类型是否与第一类型(容灾场景下为FO)相同，第一类型为接收到业务请求消息时主数据库的工作状态。如果不同，即第二参数的类型为非容灾状态(NM)，则将该业务请求消息进行抛弃处理。如果相同，即第二参数的类型也为容灾状态(FO)，则将业务请求消息中包括的第一参数存储到备数据库中。

而当备数据库中的黑名单中未存在与第一索引匹配的数据记录时，生成与第一索引匹配的数据记录，并将生成的数据记录存储至黑名单中。然后，将该业务请求消息中包括的第一参数存储至备数据库中。

与上述数据库容灾的处理方法对应地，本说明书披露的多个实施例还提供一种数据库容灾的处理装置，如图5所示，该装置包括：

接收单元501，用于接收用户终端发送的业务请求消息，业务请求消息包括第一参数。

可选的，接收单元接收的业务请求消息包括的第一参数包括用于表示业务请求消息的标识、用户终端的标识、用户标识以及业务参数。

第一生成单元502，用于根据第一参数，生成第一索引。

可选的，第一生成单元具体用于，从用于表示业务请求消息的标识、用户终端的标识、用户标识以及业务参数中选择出至少两个参数；

对选择出的至少两个参数进行拼接加密处理，得到业务索引值；

根据业务参数，确定与业务参数匹配的业务表以及业务表中的索引名称；

将业务索引值、业务表的名称和索引名称中的一个或多个进行组合处理，得到第一索引。

可选的，第一生成单元具体用于，将所述业务索引值与所述业务表的名称和所述索引名称中的进行组合处理，得到所述第一索引；

或者，将所述业务索引值作为所述第一索引。

确定单元503，用于当备数据库中的黑名单中已存在与第一索引匹配的数据记录时，确定数据记录中的第二参数的类型是否与第一类型相同，第一类型为接收到业务请求消息时主数据库的工作状态。

具体的，主数据库的工作状态包括容灾状态和非容灾状态。

处理单元504，用于如果数据记录中的第二参数的类型与第一类型不同，则将业务请求消息进行抛弃处理。

可选的，处理单元还用于，如果数据记录中的第二参数的类型与第一类型相同，则不将与第一索引匹配的数据记录存储至黑名单。

此外，该装置还可以包括：

第二生成单元505，用于当第一数据库中的黑名单中未存在与第一索引匹配的数据记录时，生成与第一索引匹配的数据记录；

存储单元506，用于将与第一索引值匹配的数据记录存储至黑名单中。

可选的，存储单元还用于，当在主数据库容灾状态下接收到业务请求消息时，将第一参数存储至备数据库中；当在主数据库非容灾状态下接收到业务请求消息时，将第一参数存储至主数据库中。

可选的，存储单元具体用于，当数据库中未存储第一参数时，则将第一参数存储至数据库。

本说明书披露的一个实施例装置的各功能模块的功能，可以通过上述方法实施例的各步骤来实现，因此，本说明书披露的一个实施例提供的装置的具体工作过程，在此不复赘述。

由上可知，本说明书披露的一个实施例提供的数据库容灾的处理装置，接收单元接收用户终端发送的业务请求消息，第一生成单元根据该消息中的第一参数生成第一索引，确定单元根据第一索引查询黑名单中是否存在与第一索引匹配的数据记录，当存在时，进一步判断该数据记录中的第二参数的类型是否与接收到业务请求消息时主数据库的工作状态相同，如果不相同，处理单元就对该业务请求消息进行抛弃处理，避免对同一业务请求消息进行重复处理，从而实现了对主数据库和备数据库跨库的幂等操作，并提高了幂等操作的可靠性，进而提高了应用系统的可用性及降低了给用户造成损失的风险。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本说明书披露的多个实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本说明书披露的多个实施例的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本说明书披露的多个实施例的具体实施方式而已，并不用于限定本说明书披露的多个实施例的保护范围，凡在本说明书披露的多个实施例的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本说明书披露的多个实施例的保护范围之内。

Claims (12)

1.一种数据库容灾的处理方法，其特征在于，包括：

接收用户终端发送的业务请求消息，所述业务请求消息包括第一参数；

根据所述第一参数，生成第一索引；

当备数据库中的黑名单中已存在与所述第一索引匹配的数据记录时，确定所述数据记录中的第二参数的类型是否与第一类型相同，所述第一类型为接收到所述业务请求消息时主数据库的工作状态；

如果所述数据记录中的第二参数的类型与第一类型不同，则将所述业务请求消息进行抛弃处理。

2.根据权利要求1所述的方法，其特征在于，所述业务请求消息包括的第一参数包括用于表示所述业务请求消息的标识、所述用户终端的标识、用户标识以及业务参数；

所述根据所述第一参数，生成第一索引，具体包括：

从所述用于表示所述业务请求消息的标识、所述用户终端的标识、用户标识以及业务参数中选择出至少两个参数；

对选择出的所述至少两个参数进行拼接加密处理，得到业务索引值；

根据所述业务参数，确定与所述业务参数匹配的业务表以及所述业务表中的索引名称；

将所述业务索引值、所述业务表的名称和所述索引名称中的一个或多个进行组合处理，得到所述第一索引。

3.根据权利要求2所述的方法，其特征在于，所述将所述业务索引值、所述业务表的名称和所述索引名称中的一个或多个进行组合处理，得到所述第一索引，具体包括：

将所述业务索引值与所述业务表的名称和所述索引名称中的进行组合处理，得到所述第一索引；

或者，将所述业务索引值作为所述第一索引。

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

当所述第一数据库中的黑名单中未存在与所述第一索引匹配的数据记录时，生成与所述第一索引匹配的数据记录；

将与所述第一索引匹配的数据记录存储至所述黑名单中。

5.根据权利要求1所述的方法，其特征在于，还包括：如果所述数据记录中的第二参数的类型与所述第一类型相同，则不将所述数据记录存储至所述黑名单。

6.根据权利要求4或5所述的方法，其特征在于，所述主数据库的工作状态包括容灾状态和非容灾状态；

所述方法还包括：

当在主数据库容灾状态下接收到所述业务请求消息，且所述备数据库未存储所述第一参数时，将所述第一参数存储至所述备数据库中；

当在主数据库非容灾状态下接收到所述业务请求消息，且所述主数据库未存储所述第一参数时，将所述第一参数存储至所述主数据库中。

7.一种数据库容灾的处理装置，其特征在于，包括：

接收单元，用于接收用户终端发送的业务请求消息，所述业务请求消息包括第一参数；

第一生成单元，用于根据所述第一参数，生成第一索引；

确定单元，用于当备数据库中的黑名单中已存在与所述第一索引匹配的数据记录时，确定所述数据记录中的第二参数的类型是否与第一类型相同，所述第一类型为接收到所述业务请求消息时主数据库的工作状态；

处理单元，用于如果所述数据记录中的第二参数的类型与第一类型不同，则将所述业务请求消息进行抛弃处理。

8.根据权利要求7所述的装置，其特征在于，所述接收单元接收的所述业务请求消息包括的第一参数包括用于表示所述业务请求消息的标识、所述用户终端的标识、用户标识以及业务参数；

第一生成单元具体包括：选择子单元，用于从所述用于表示所述业务请求消息的标识、所述用户终端的标识、用户标识以及业务参数中选择出至少两个参数；

加密子单元，用于对选择出的所述至少两个参数进行拼接加密处理，得到业务索引值；

确定子单元，用于根据所述业务参数，确定与所述业务参数匹配的业务表以及所述业务表中的索引名称；

处理子单元，用于将所述业务索引值、所述业务表的名称和所述索引名称中的一个或多个进行组合处理，得到所述第一索引。

9.根据权利要求8所述的装置，其特征在于，所述处理子单元具体用于，将所述业务索引值与所述业务表的名称和所述索引名称中的进行组合处理，得到所述第一索引；

或者，将所述业务索引值作为所述第一索引。

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

第二生成单元，用于当所述第一数据库中的黑名单中未存在与所述第一索引匹配的数据记录时，生成与所述第一索引匹配的数据记录；

存储单元，用于将与所述第一索引匹配的数据记录存储至所述黑名单中。

11.根据权利要求10所述的装置，其特征在于，所述处理单元还用于，如果所述数据记录中的第二参数的类型与所述第一类型相同，则不将所述数据记录存储至所述黑名单。

12.根据权利要求10或11所述的装置，其特征在于，所述主数据库的工作状态包括容灾状态和非容灾状态；

所述存储单元还用于，当在主数据库容灾状态下接收到所述业务请求消息，且所述备数据库未存储所述第一参数时，将所述第一参数存储至所述备数据库中；

当在主数据库非容灾状态下接收到所述业务请求消息，且所述主数据库未存储所述第一参数时，将所述第一参数存储至所述主数据库中。