一种双站点分布式数据库的业务处理方法及装置与流程

1.本申请涉及计算机技术领域，具体涉及双站点分布式数据库的业务处理方法及装置。


背景技术：

2.随着信息技术的进步，数字化金融空前发展，数据对于金融企业也愈发重要，数据丢失或者中断业务都会给金融企业带来无法估量的损失，尤其是银行业。随着数据库技术的提升以及it架构转型的浪潮，越来越多的大型金融机构把数据从传统数据库迁移至分布式数据库，以提高数据的安全性及高可用性。目前几乎所有的分布式数据库都是基于分布式一致性协议，即多数副本数据强一致，一般设置数据副本为3副本或者大于3的奇数副本，为了抵御站点级故障对数据带来的影响，同城应至少建立3个站点，但事实上即便是安全等级最高的银行业，同城最多也只建设了两中心或者两地三中心架构，这就导致同城有一个站点必然存有多数副本(即主站点)，主站点发生灾难不仅导致业务中断，而且备站点(少数副本站点)会丢失一部分数据(主备站点为异步数据复制)，这不仅会带来巨大影响，而且也无法满足监管要求。


技术实现要素：

3.针对现有技术中的问题，本申请提供一种双站点分布式数据库的业务处理方法及装置，解决了双站点中主备站点数据一致性的问题，当出现站点级故障时，保证数据零丢失；当灾难发生后通过故障自动检测及参数动态调整的方式减少人工干预，全程自动化应急帮助业务快速恢复，有效减轻运维人员压力，降低金融业务风险和生产运维风险。
4.为解决上述技术问题，本申请提供以下技术方案：
5.本发明的一个方面，提供一种双站点分布式数据库的业务处理方法，其中，所述双站点分布式数据库包括主站点和备站点，所述主站点和所述备站点中各自存储有多个副本，包括：
6.若当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务；
7.若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务；其中，所述多数为大于对应总数的一半的正整数。
8.在优选的实施例中，还包括：
9.若当前异常副本数大于零，通过故障检测器检测服务器、网络以及当前异常副本中的至少一个，得到故障原因；
10.根据所述故障原因处理导致异常副本的故障。
11.在优选的实施例中，所述通过故障检测器检测服务器，得到故障原因，包括：通过获取bmc上信息定位服务器故障原因。
12.在优选的实施例中，所述通过故障检测器检测网络，得到故障原因，包括：通过ping网络、比较网络延迟以及查看丢包率检测网络。
13.在优选的实施例中，所述通过故障检测器检测当前异常副本，得到故障原因，包括：通过故障检测器对副本发送查询指令，若在规定时间返回预期结果则判定为正常，反之判断为异常。
14.在优选的实施例中，还包括：针对每个异常副本，从云端服务器下载故障发生前的业务数据，并将下载的业务数据同步到对应异常副本。
15.本发明的又一方面，提供一种双站点分布式数据库的业务处理装置，其中，所述双站点分布式数据库包括主站点和备站点，所述主站点和所述备站点中各自存储有多个副本，包括：
16.正常状态处理模块，若当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务；
17.异常状态处理模块，若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务；其中，所述多数为大于对应总数的一半的正整数。
18.在优选的实施例中，还包括：故障检测模块，若当前异常副本数大于零，通过故障检测器检测服务器、网络以及当前异常副本中的至少一个，得到故障原因；
19.故障处理模块，根据所述故障原因处理导致异常副本的故障。
20.本发明的又一方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的双站点分布式数据库的业务处理方法。
21.本发明的又一方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的双站点分布式数据库的业务处理方法。
22.由上述技术方案可知，本申请提供的一种双站点分布式数据库的业务处理方法，方法包括：若当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务；若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务；其中，所述多数为大于对应总数的一半的正整数。本发明解决了双站点中主备站点数据一致性的问题，当出现站点级故障时，保证数据零丢失；当灾难发生后通过故障自动检测及参数动态调整的方式减少人工干预，全程自动化应急帮助业务快速恢复，有效减轻运维人员压力，降低金融业务风险和生产运维风险。
附图说明
23.为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
24.图1是双站点分布式数据库的业务处理方法流程示意图。
25.图2是故障处理流程示意图。
26.图3是重建数据库流程示意图。
27.图4是双站点分布式数据库的业务处理装置的结构示意图。
28.图5是故障处理模块的结构示意图。
29.图6是重建数据库单元的结构示意图。
30.图7是本申请实施例中的电子设备的结构示意图。
具体实施方式
31.为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
32.需要说明的是，本申请公开的双站点分布式数据库的业务处理方法及装置可用于计算机技术领域，也可用于除计算机技术领域之外的任意领域，本申请公开的双站点分布式数据库的业务处理方法及装置的应用领域不做限定。
33.随着信息技术的进步，数字化金融空前发展，数据对于金融企业也愈发重要，数据丢失或者中断业务都会给金融企业带来无法估量的损失，尤其是银行业。随着数据库技术的提升以及it架构转型的浪潮，越来越多的大型金融机构把数据从传统数据库迁移至分布式数据库，以提高数据的安全性及高可用性。目前几乎所有的分布式数据库都是基于分布式一致性协议，即多数副本数据强一致，一般设置数据副本为3副本或者大于3的奇数副本，为了抵御站点级故障对数据带来的影响，同城应至少建立3个站点，但事实上即便是安全等级最高的银行业，同城最多也只建设了两中心或者两地三中心架构，这就导致同城有一个站点必然存有多数副本(即主站点)，主站点发生灾难不仅导致业务中断，而且备站点(少数副本站点)会丢失一部分数据(主备站点为异步数据复制)，这不仅会带来巨大影响，而且也无法满足监管要求。
34.本申请提供一种双站点分布式数据库的业务处理方法，其中，所述双站点分布式数据库包括主站点和备站点，所述主站点和所述备站点中各自存储有多个副本，如图1，包括：
35.s1:若当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务；
36.具体的，对于分布式数据库，副本参数是指数据被同步写入所述副本参数所设置的数量个副本中时，可以对数据库中数据进行读操作。在建立副本集群时，其副本参数会自动被设置为副本总数的一半再加一，即将当前业务数据备份至集群中多数副本中，采用的是多数一致性的机制来保障业务数据不丢失。而对于双站点的分布式数据库系统，这样的多数一致机制在主站点崩溃或者多数副本异常的情况下，非常容易造成业务数据丢失导致业务无法处理，例如假设数据库副本总数为11个，其中主站点存储了6个，备站点存储了5个，采用多数一致的机制，当业务处理完毕后，将业务数据同步至了主站点的6个副本中，此时已经满足多数一致机制，所以不再继续同步，流程会开始处理下一个业务请求。正当流程开始处理下一个业务请求时，主站点中的所有副本由于某种故障均发生异常，而备站点中的副本还未根据本次业务数据进行异步复制，此时就出现了一个严重的问题，本次业务的
数据被丢失了。数据的丢失在很多情况中是不被允许的。为了抵御双站点分布式数据库出现业务数据丢失的情况，需要采用全数一致的机制，即当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务。仍然以数据库副本总数为11个，其中主站点存储了6个，备站点存储了5个来进行举例说明。当前业务完成后，采用全数一致的机制对副本进行同步，即将主站点的6个副本和备站点的5个副本均写入本次业务数据，才进入下一业务的处理。同样地，若在进入下一业务的处理过程中，主站点由于某种原因导致其存储的6个副本均发生异常，但此时备站点中副本已经存储了当前的业务数据，可以根据备站点的副本来进行处理后续下一个业务，不会造成业务数据的丢失。
37.s2:若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务；其中，所述多数为大于对应总数的一半的正整数。
38.具体的，全数一致的机制可以保证数据的不丢失，但是当某一副本发生故障时，会直接导致业务的中断。为了提高双站点的高可用性，若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务。可以理解，当副本发生故障后，为了使得业务仍然可以连续处理，将初始的全数一致机制降级为多数一致机制，即将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务。举例而言，若分布式数据库集群中副本总数为11，其中主站点存储有6个，备站点存储有5个。通过故障检测器发现主站点中1个副本发生了异常，此时将数据库的副本参数从初始的11更改为6，即只要有6及6以上个副本是正常状态，数据库即可对外进行服务，此时虽然有1个副本发生异常，但还有10个副本是正常的，10个大于6个，所以满足数据库对外服务的条件，故相邻的下一个业务可以正常被处理，从而不会影响业务的连续性。
39.可以理解的是，本发明中的业务可以是客户端设备与本发明的分布式站点之间的业务，例如转账、打款等，服务器可以是银行服务器，客户端设备可以包括智能手机、平板电子设备、便携式计算机、台式电脑、个人数字助理(pda)。
40.上述的客户端设备可以具有通信模块(即通信单元)，可以与远程的银行服务器进行通信连接，实现与所述服务器的数据传输。
41.上述分布式站点与所述客户端设备之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括tcp/ip协议、udp/ip协议、http协议、https协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的rpc协议(remote procedure call protocol，远程过程调用协议)、rest协议(representational state transfer，表述性状态转移协议)等。
42.在本发明的实施例中，还包括了对故障的处理，如图2，其步骤为：
43.s21:若当前异常副本数大于零，通过故障检测器检测服务器、网络以及当前异常副本中的至少一个，得到故障原因。
44.具体的，当发现有副本发生异常，需要首先定位到是各种原因导致的故障，以便精准地进行故障的处理。通过内部故障检测器判断数据库是否故障以及故障原因，以保障集群健康稳定的运行，同时精准定位故障原因便于后续系统恢复工作。以故障原因从底层往
上划分3个场景：1、服务器故障，本系统的故障检测器通过连接bmc(baseboardmanagercontroller)获取服务器基本信息，bmc是intelx86服务器的控制系统，独立于主板、cpu、操作系统等。bmc中包含服务器主板、cpu、磁盘、电源、温度等各种信息，例如磁盘故障时，bmc上就会出现相应的磁盘告警(同样适用主板、cpu、电源等故障)，本系统通过获取bmc上信息精确定位服务器故障原因，及时告知设备专业人员，缩短维修时间。2、网络故障。故障检测器会定时检测站点间和节点间网络健康情况，通过ping网络、比较网络延迟、查看丢包率等各方面评估网络健康状况，若发现网络延迟升高，丢包突增，则可判定为网络异常，及时告知网络专业人员，提升系统恢复效率。3、副本故障。故障检测器通过基于应用的副本探活，不是简单的副本发送心跳，而是通过故障检测器对副本发送查询指令，若在规定时间返回预期结果(例如时间戳)则判定为正常，这种探活方式可以有效避免假活。
45.s22:根据所述故障原因处理导致异常副本的故障。
46.具体的，例如若检测到故障是由于服务器导致的故障，则通过对服务器的修复来处理故障问题，例如重新启动服务器。若检测到的故障是由于网络导致的故障，则可以通过对网络的修复来处理故障，例如重新插拔网络数据线。若检测到的故障是由于副本本身异常导致的故障，则可以通过对副本本身的修复来处理故障，例如将异常副本删除后，重新复制一个正常副本。
47.在本发明的实施例中，若当前异常副本数大于所有副本的多数，则重新建立数据库，从云端服务器下载故障发生前的业务数据，并将下载的业务数据同步到对应副本。如图3，对于重建数据库的具体步骤包括：
48.s301：恢复故障区域基础环境。恢复基础环境，包含服务器设备，网络，操作系统等，通过故障检测器提供的故障原因，可以精准定位故障位置及原因，提高故障恢复效率。
49.s302：重建故障离线组件。系统在恢复的基础环境上搭建之前故障组件，含数据库管理组件、数据库存储组件、数据库计算组件等。
50.s303：在线系统恢复。系统将恢复后的组件重新加入集群，将应急期间临时重建的组件和副本缩容，恢复到故障前的集群部署架构，恢复期间对业务透明。
51.结合一个具体的实施场景对本发明进行进一步说明。
52.假设在某银行为了业务需要，在一个城市中搭建了一个双站点的分布式数据库，数据库中设置总副本数为25，其中主站点存储副本数为13，备站点存储副本数为12，数据库的副本参数设置为25，即全数一致。
53.当前银行服务器已经完成了一笔转账业务的处理，获得了本次转账业务的相关数据信息，例如转账时间，转账账户，转账金额，到账方式等。同时故障检测器显示所有副本的状态都是处于正常。根据副本参数的设置，需要将该转账业务的数据信息同步至25个副本中，即主站点和备站点的所有副本中，才开始进入下一个业务的处理。
54.假设下一个业务请求是一个存储业务，系统进行了存储账户的账户信息更新，得到了本次存储业务的相关业务信息，例如存储账户，存储金额，存储时间，存储方式等。此时故障检测器检测到主站点的一个副本状态处于异常。若根据当前数据库的副本参数25，需要将本次存储业务同步至主站点和备站点的25个副本中，才会进入下一个业务。但此时无法实现，因为有一个副本出现异常。所以若要实现业务的不中断，需要将全数一致的同步机
制更改为多数一致，即将副本参数更改为当前正常副本数的一半再加一的正整数，也就是24的一半12，再加1后为13，副本参数被设置为13。故本次存储业务只需要同步至13个副本中，就可以进入下一个业务。这个是完全可以实现的。
55.假设存储业务的下一个业务是银行开户业务，银行服务器已经完成了开户业务的相关处理，得到了与本次开户业务相关的数据信息，例如开户人身份证件号，开户账号，开户时间等。此时，故障检测器检测出备站点的12个副本均出现异常，主要是由于主站点和备站点之间的网络通信中断。根据当前的副本参数13可知，需要将本次开户业务同步至13个副本中才可以进入下一个业务，而此时正常工作的副本数只有12，显然不满足副本同步的需求。所以为了业务不出现中断，需要更改副本参数为7，使得业务继续进行。也就是说，本次开户业务的数据信息只需要同步至7个副本中，就可以进入下一个业务处理。
56.假设开户业务的下一个业务是取款业务，银行服务器已经对取款业务进行了处理，并且得到了本次取款业务的相关数据信息，例如取款时间，取款账号，取款方式，取款金额等。此时故障检测器检测到主站点的服务器出现故障导致主站点的所有副本出现异常。此时整个数据库中没有正常状态副本，所以无法进行副本同步，更无法进入下一个业务为了保证业务的不中断，采用一键式恢复操作，重新搭建数据库，副本总数为25，主站点有13个，备站点有12个，这些新建的副本数据是云端数据库中下载的故障发生前的业务数据。同时设置副本参数为25。将本次取款业务同步至主备站点中所有25个副本后进入下一个业务。
57.以上述过程类推，本申请实现双站点分布式数据库的高可用。
58.在上述具体场景中是假设了一个最极端的情况，所有的故障包括副本自身，网络及服务器故障，都是无法在短时间内修复的。实际过程中，在故障的处理线程与业务处理的线程是并行的。可以理解，如检测到副本自身出现故障，而此时业务处理线程还在执行业务处理，没有需要同步副本，则故障处理线程就可以将出现故障的副本删除，并将当前正常副本复制至删除副本位置，实现故障自愈。
59.由以上描述可知，本发明提供的一种双站点分布式数据库的业务处理方法，解决了双站点中主备站点数据一致性的问题，当出现站点级故障时，保证数据零丢失；当灾难发生后通过故障自动检测及参数动态调整的方式减少人工干预，全程自动化应急帮助业务快速恢复，有效减轻运维人员压力，降低金融业务风险和生产运维风险。
60.从软件层面来说，本申请提供一种用于执行所述双站点分布式数据库的业务处理方法中全部或部分内容的双站点分布式数据库的业务处理装置的实施例，参见图4，所述双站点分布式数据库的业务处理装置具体包含有如下内容：
61.正常状态处理模块1:若当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务；
62.具体的，对于分布式数据库，副本参数是指数据被同步写入所述副本参数所设置的数量个副本中时，可以对数据库中数据进行读操作。在建立副本集群时，其副本参数会自动被设置为副本总数的一半再加一，即将当前业务数据备份至集群中多数副本中，采用的是多数一致性的机制来保障业务数据不丢失。而对于双站点的分布式数据库系统，这样的多数一致机制在主站点崩溃或者多数副本异常的情况下，非常容易造成业务数据丢失导致业务无法处理，例如假设数据库副本总数为11个，其中主站点存储了6个，备站点存储了5
个，采用多数一致的机制，当业务处理完毕后，将业务数据同步至了主站点的6个副本中，此时已经满足多数一致机制，所以不再继续同步，流程会开始处理下一个业务请求。正当流程开始处理下一个业务请求时，主站点中的所有副本由于某种故障均发生异常，而备站点中的副本还未根据本次业务数据进行异步复制，此时就出现了一个严重的问题，本次业务的数据被丢失了。数据的丢失在很多情况中是不被允许的。为了抵御双站点分布式数据库出现业务数据丢失的情况，需要采用全数一致的机制，即当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务。仍然以数据库副本总数为11个，其中主站点存储了6个，备站点存储了5个来进行举例说明。当前业务完成后，采用全数一致的机制对副本进行同步，即将主站点的6个副本和备站点的5个副本均写入本次业务数据，才进入下一业务的处理。同样地，若在进入下一业务的处理过程中，主站点由于某种原因导致其存储的6个副本均发生异常，但此时备站点中副本已经存储了当前的业务数据，可以根据备站点的副本来进行处理后续下一个业务，不会造成业务数据的丢失。
63.异常状态处理模块2:若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务；其中，所述多数为大于对应总数的一半的正整数。
64.具体的，全数一致的机制可以保证数据的不丢失，但是当某一副本发生故障时，会直接导致业务的中断。为了提高双站点的高可用性，若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务。可以理解，当副本发生故障后，为了使得业务仍然可以连续处理，将初始的全数一致机制降级为多数一致机制，即将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务。举例而言，若分布式数据库集群中副本总数为11，其中主站点存储有6个，备站点存储有5个。通过故障检测器发现主站点中1个副本发生了异常，此时将数据库的副本参数从初始的11更改为6，即只要有6及6以上个副本是正常状态，数据库即可对外进行服务，此时虽然有1个副本发生异常，但还有10个副本是正常的，10个大于6个，所以满足数据库对外服务的条件，故相邻的下一个业务可以正常被处理，从而不会影响业务的连续性。
65.在本发明的实施例中，还包括了对故障处理模块，如图5，该模块包括：
66.故障检测单元:若当前异常副本数大于零，通过故障检测器检测服务器、网络以及当前异常副本中的至少一个，得到故障原因。
67.具体的，当发现有副本发生异常，需要首先定位到是各种原因导致的故障，以便精准地进行故障的处理。通过内部故障检测器判断数据库是否故障以及故障原因，以保障集群健康稳定的运行，同时精准定位故障原因便于后续系统恢复工作。以故障原因从底层往上划分3个场景：1、服务器故障，本系统的故障检测器通过连接bmc(baseboardmanagercontroller)获取服务器基本信息，bmc是intelx86服务器的控制系统，独立于主板、cpu、操作系统等。bmc中包含服务器主板、cpu、磁盘、电源、温度等各种信息，例如磁盘故障时，bmc上就会出现相应的磁盘告警(同样适用主板、cpu、电源等故障)，本系统通过获取bmc上信息精确定位服务器故障原因，及时告知设备专业人员，缩短维修时间。2、网络故障。故障检测器会定时检测站点间和节点间网络健康情况，通过ping网络、比较网络
延迟、查看丢包率等各方面评估网络健康状况，若发现网络延迟升高，丢包突增，则可判定为网络异常，及时告知网络专业人员，提升系统恢复效率。3、副本故障。故障检测器通过基于应用的副本探活，不是简单的副本发送心跳，而是通过故障检测器对副本发送查询指令，若在规定时间返回预期结果(例如时间戳)则判定为正常，这种探活方式可以有效避免假活。
68.故障处理单元:根据所述故障原因处理导致异常副本的故障。
69.具体的，例如若检测到故障是由于服务器导致的故障，则通过对服务器的修复来处理故障问题，例如重新启动服务器。若检测到的故障是由于网络导致的故障，则可以通过对网络的修复来处理故障，例如重新插拔网络数据线。若检测到的故障是由于副本本身异常导致的故障，则可以通过对副本本身的修复来处理故障，例如将异常副本删除后，重新复制一个正常副本。
70.在本发明的实施例中，还包括重建单元，若当前异常副本数大于所有副本的多数，则重新建立数据库，从云端服务器下载故障发生前的业务数据，并将下载的业务数据同步到对应副本。如图6，重建单元包括：
71.基础环境恢复单元：恢复基础环境，包含服务器设备，网络，操作系统等，通过故障检测器提供的故障原因，可以精准定位故障位置及原因，提高故障恢复效率。
72.重建故障离线组件单元：系统在恢复的基础环境上搭建之前故障组件，含数据库管理组件、数据库存储组件、数据库计算组件等。
73.在线系统恢复单元：系统将恢复后的组件重新加入集群，将应急期间临时重建的组件和副本缩容，恢复到故障前的集群部署架构，恢复期间对业务透明。
74.结合一个具体的实施场景对本发明进行进一步说明。
75.假设在某银行为了业务需要，在一个城市中搭建了一个双站点的分布式数据库，数据库中设置总副本数为25，其中主站点存储副本数为13，备站点存储副本数为12，数据库的副本参数设置为25，即全数一致。
76.当前银行服务器已经完成了一笔转账业务的处理，获得了本次转账业务的相关数据信息，例如转账时间，转账账户，转账金额，到账方式等。同时故障检测器显示所有副本的状态都是处于正常。根据副本参数的设置，需要将该转账业务的数据信息同步至25个副本中，即主站点和备站点的所有副本中，才开始进入下一个业务的处理。
77.假设下一个业务请求是一个存储业务，系统进行了存储账户的账户信息更新，得到了本次存储业务的相关业务信息，例如存储账户，存储金额，存储时间，存储方式等。此时故障检测器检测到主站点的一个副本状态处于异常。若根据当前数据库的副本参数25，需要将本次存储业务同步至主站点和备站点的25个副本中，才会进入下一个业务。但此时无法实现，因为有一个副本出现异常。所以若要实现业务的不中断，需要将全数一致的同步机制更改为多数一致，即将副本参数更改为当前正常副本数的一半再加一的正整数，也就是24的一半12，再加1后为13，副本参数被设置为13。故本次存储业务只需要同步至13个副本中，就可以进入下一个业务。这个是完全可以实现的。
78.假设存储业务的下一个业务是银行开户业务，银行服务器已经完成了开户业务的相关处理，得到了与本次开户业务相关的数据信息，例如开户人身份证件号，开户账号，开户时间等。此时，故障检测器检测出备站点的12个副本均出现异常，主要是由于主站点和备
站点之间的网络通信中断。根据当前的副本参数13可知，需要将本次开户业务同步至13个副本中才可以进入下一个业务，而此时正常工作的副本数只有12，显然不满足副本同步的需求。所以为了业务不出现中断，需要更改副本参数为7，使得业务继续进行。也就是说，本次开户业务的数据信息只需要同步至7个副本中，就可以进入下一个业务处理。
79.假设开户业务的下一个业务是取款业务，银行服务器已经对取款业务进行了处理，并且得到了本次取款业务的相关数据信息，例如取款时间，取款账号，取款方式，取款金额等。此时故障检测器检测到主站点的服务器出现故障导致主站点的所有副本出现异常。此时整个数据库中没有正常状态副本，所以无法进行副本同步，更无法进入下一个业务为了保证业务的不中断，采用一键式恢复操作，重新搭建数据库，副本总数为25，主站点有13个，备站点有12个，这些新建的副本数据是云端数据库中下载的故障发生前的业务数据。同时设置副本参数为25。将本次取款业务同步至主备站点中所有25个副本后进入下一个业务。
80.以上述过程类推，本申请实现双站点分布式数据库的高可用。
81.在上述具体场景中是假设了一个最极端的情况，所有的故障包括副本自身，网络及服务器故障，都是无法在短时间内修复的。实际过程中，在故障的处理线程与业务处理的线程是并行的。可以理解，如检测到副本自身出现故障，而此时业务处理线程还在执行业务处理，没有需要同步副本，则故障处理线程就可以将出现故障的副本删除，并将当前正常副本复制至删除副本位置，实现故障自愈。
82.由以上描述可知，本发明提供的一种双站点分布式数据库的业务处理装置，解决了双站点中主备站点数据一致性的问题，当出现站点级故障时，保证数据零丢失；当灾难发生后通过故障自动检测及参数动态调整的方式减少人工干预，全程自动化应急帮助业务快速恢复，有效减轻运维人员压力，降低金融业务风险和生产运维风险。
83.从硬件层面来说，本申请提供一种用于实现双站点分布式数据库的业务处理方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：
84.图7为本申请实施例的电子设备9600的系统构成的示意框图。如图7所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图7是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。
85.在一实施例中，双站点分布式数据库的业务处理功能可以被集成到中央处理器中。其中，中央处理器可以被配置为进行如下控制：
86.s1:若当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务；
87.s2:若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务；其中，所述多数为大于对应总数的一半的正整数。
88.从上述描述可知，本申请实施例提供的电子设备，解决了双站点中主备站点数据一致性的问题，当出现站点级故障时，保证数据零丢失；当灾难发生后通过故障自动检测及参数动态调整的方式减少人工干预，全程自动化应急帮助业务快速恢复，有效减轻运维人员压力，降低金融业务风险和生产运维风险。
89.在另一个实施方式中，双站点分布式数据库的业务处理装置可以与中央处理器9100分开配置，例如可以双站点分布式数据库的业务处理装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现双站点分布式数据库的业务处理功能。
90.如图7所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图7中所示的所有部件；此外，电子设备9600还可以包括图7中没有示出的部件，可以参考现有技术。
91.如图7所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。
92.其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。
93.输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为lcd显示器，但并不限于此。
94.该存储器9140可以是固态存储器，例如，只读存储器(rom)、随机存取存储器(ram)、sim卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为eprom等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。
95.存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。
96.通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。
97.基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。
98.本申请的实施例还提供能够实现上述实施例中的双站点分布式数据库的业务处理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的双
站点分布式数据库的业务处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：
99.s1:若当前所有副本正常，设置副本参数为总副本数，将当前处理业务的业务数据同步至所有副本后进行相邻的下一业务；
100.s2:若当前异常副本数小于所有副本的多数，设置所述副本参数为当前正常副本数的多数，将当前处理业务的业务数据同步至当前正常副本中的多数副本后进行相邻的下一业务；其中，所述多数为大于对应总数的一半的正整数。
101.从上述描述可知，本申请实施例提供的计算机可读存储介质，解决了双站点中主备站点数据一致性的问题，当出现站点级故障时，保证数据零丢失；当灾难发生后通过故障自动检测及参数动态调整的方式减少人工干预，全程自动化应急帮助业务快速恢复，有效减轻运维人员压力，降低金融业务风险和生产运维风险。
102.本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
103.本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
104.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
105.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
106.本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。