CN111930570A - 一种多机房数据库高可用的处理系统及处理方法 - Google Patents

Abstract

本发明提供的多机房数据库高可用的处理系统及处理方法，两机房都有独立对等的数据库集群，且设置一个从库在对方机房，以此来保证两机房数据副本的完整性。在一个机房处理订单的写请求后，该订单的处理信息以及该订单与该机房的路由关系写入该机房的主库中，并通过主库主从数据复制模式将数据同步至该机房本地的从库以及跨机房的从库，以此保证后续任意机房处理该订单的读请求的可操作性。可见，本申请中两机房的应用能够同时对外提供服务，两机房的数据库集群也同时能够提供读写服务，满足高可用要求。

Description

一种多机房数据库高可用的处理系统及处理方法

技术领域

本发明涉及互联网技术领域，更具体地说，涉及一种多机房数据库高可用的处理系统及处理方法。

背景技术

互联网公司业务发展到一定规模，对服务的可用性要求也越来越高。尤其是在金融领域，对服务的可用性、连续性、强一致性有着更高的要求。因此，业界都会选择多机房部署。

业内多机房部署一般会基于MySQL数据复制模式，也就是share nothing模式，通过数据传输、复制协议达到数据一致性。目前主流的多机房方案一般采用“应用层双活，数据库单活”方式，即两个机房的应用同时对外提供服务，但只有一个机房的数据库提供读写，另外一个机房的数据库只提供读，数据库之间单向复制。基于MHA架构，异步复制方案，性能可以接受。如果一致性要求高，采用半同步复制，两个机房距离很远(超过100公里)，跨机房访问的性能会有较大影响。

现有方案虽然实施成本较低、对业务侵入较少但存在跨库写操作，一致性要求高的场景，性能会打些折扣。如果主库机房挂掉，可能会面临不可写，不能满足高可用要求。

发明内容

有鉴于此，为解决上述问题，本发明提供一种多机房数据库高可用的处理系统及处理方法，技术方案如下：

一种多机房数据库高可用的处理系统，所述处理系统包括：

终端、调度服务器、以及机房的网关、微服务处理器和数据库集群；其中，

所述机房包括第一机房和第二机房，所述数据库集群包括主库、第一从库和第二从库，所述第一机房的主库和第一从库部署于所述第一机房中、第二从库部署于所述第二机房中，所述第二机房的主库和第一从库部署于所述第二机房中、第二从库部署于所述第一机房中；

所述终端，用于发起针对订单的写请求；

所述调度服务器，用于通过机房流量调度将所述订单的写请求发送至目标机房；

所述目标机房的网关，用于将所述订单的写请求发送至所述目标机房的微服务处理器；

所述目标机房的微服务处理器，用于处理所述订单的写请求；将所述订单的处理信息以及所述订单与所述目标机房的路由关系写入至所述目标机房的主库中；

所述目标机房的主库，用于将所述订单的处理信息和所述路由关系同步至所述目标机房的第一从库和第二从库，实现所述第一机房和所述第二机房基于所述路由关系响应针对所述订单的读请求得到所述订单的处理信息。

优选的，所述路由关系包括所述订单的流水号以及所述目标机房的机房编号。

优选的，所述目标机房的网关，还用于：

获取所述目标机房的微服务处理器所处理的异常请求的状态，并在所述异常请求的状态符合预设熔断条件的情况下，将指定时间窗口内接收到的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

优选的，所述目标机房的网关，还用于：

在所述订单的写请求符合预设流量调度条件的情况下，将所述订单的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

优选的，所述处理系统还包括：云端服务器；

所述机房的微服务处理器，用于监测所述机房的数据库集群的运行状态，并上传至所述云端服务器；

所述云端服务器，用于将所述机房对应的运行状态写入到机房列表中；

所述终端，具体用于：

通过调用所述机房列表确定数据库集群处于可用状态的机房，并基于确定结果发起所述订单的写请求。

所述调度服务器，具体用于：

将所述订单的写请求发送至数据库集群处于可用状态的目标机房。

优选的，所述处理系统还包括：

第三机房的第一主库和第二主库；

所述第一机房的主库，用于将其信息备份至所述第三机房的第一主库中；

所述第二机房的主库，用于将其信息备份至所述第三机房的第二主库中。

一种多机房数据库高可用的处理方法，应用于多机房数据库高可用的处理系统中目标机房的网关，所述处理方法包括：

接收调度服务器发送的针对订单的写请求，所述订单的写请求是终端发起的；

将所述订单的写请求发送至所述目标机房的微服务处理器，以使所述目标机房的微服务处理器处理所述订单的写请求、并将所述订单的处理信息以及所述订单与所述目标机房的路由关系写入至所述目标机房的主库中，还使所述目标机房的主库将所述订单的处理信息和所述路由关系同步至所述目标机房的第一从库和第二从库，实现第一机房和第二机房基于所述路由关系响应针对所述订单的读请求得到所述订单的处理信息。

优选的，所述路由关系包括所述订单的流水号以及所述目标机房的机房编号。

优选的，所述处理方法还包括：

获取所述目标机房的微服务处理器所处理的异常请求的状态，并在所述异常请求的状态符合预设熔断条件的情况下，将指定时间窗口内接收到的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

优选的，所述处理方法还包括：

在所述订单的写请求符合预设流量调度条件的情况下，将所述订单的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

本发明提供的多机房数据库高可用的处理系统及处理方法，两机房都有独立对等的数据库集群，且设置一个从库在对方机房，以此来保证两机房数据副本的完整性。在一个机房处理订单的写请求后，该订单的处理信息以及该订单与该机房的路由关系写入该机房的主库中，并通过主库主从数据复制模式将数据同步至该机房本地的从库以及跨机房的从库，以此保证后续任意机房处理该订单的读请求的可操作性。可见，本申请中两机房的应用能够同时对外提供服务，两机房的数据库集群也同时能够提供读写服务，满足高可用要求。

附图说明

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

图1为本发明实施例提供的多机房数据库高可用的处理系统的结构示意图；

图2为本发明实施例提供的多机房数据库高可用的处理系统的另一结构示意图；

图3为本发明实施例提供的多机房数据库高可用的处理系统的再一结构示意图；

图4为本发明实施例提供的多机房数据库高可用的处理方法的方法流程图。

具体实施方式

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

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明实施例提供一种多机房数据库高可用的处理系统，提出一种新概念“应用层双活，数据库层伪双活”。两个机房对等，无状态。两机房的应用同时对外提供服务，两机房的数据库集群也同时提供读写服务，数据库之间采用单向复制，两机房的数据库集群的设计思路是采用“分库的思想”。需要说明的是，本申请实施例中的数据库集群可以为MySQL。

参见图1所示的多机房数据库高可用的处理系统的结构示意图。该处理系统包括：

终端10、调度服务器20、以及机房的网关30、微服务处理器40和数据库集群50；其中，

机房包括第一机房和第二机房，数据库集群50包括主库501、第一从库502和第二从库503，第一机房的主库501和第一从库502部署于第一机房中、第二从库503部署于第二机房中，第二机房的主库501和第一从库502部署于第二机房中、第二从库503部署于第一机房中。

终端10，用于发起针对订单的写请求。

为方便理解本发明实施例，以下以支付业务场景为例。终端10响应用户操作，发起针对订单的支付请求。

调度服务器20，用于通过机房流量调度将订单的写请求发送至目标机房。

继续以支付业务场景为例，本发明实施例中，调度服务器20基于已有的流量调度策略将该订单的支付请求分配至目标机房。

具体的，在终端10网络环境稳定的情况下，调度服务转发请求到机房满足一致性，即短时间内，同一个终端10的请求(包括写请求和读请求)会固定调度到同一个机房。因此，这样能很好的避免数据库跨机房主从延时引起的不一致问题。在同一个机房的数据库集群50中处理写请求和读请求。

目标机房的网关30，用于将订单的写请求发送至目标机房的微服务处理器40。

继续以支付业务场景为例，本发明实施例中，目标机房的网关30接收调度服务器20所分配的订单的支付请求，并将该请求转发至处理支付业务的微服务处理器40。

目标机房的微服务处理器40，用于处理订单的写请求；将订单的处理信息以及订单与目标机房的路由关系写入至目标机房的主库501中。具体的，该路由关系可以包括订单的流水号以及目标机房的机房编号，即建立订单的流水号与目标机房的机房编号间的对应关系。

继续以支付业务场景为例，本发明实施例中，微服务处理器40基于已有的支付交易策略处理接收到的订单的支付请求，产生相应的针对该订单的支付信息，同时，生成该订单与所在目标机房的路由关系，即通过该路由关系能够指示该订单与处理该订单的目标机房间的对应关系，通过该路由关系能够定位到目标机房。最后，将该订单的支付信息、以及路由关系写入至所在目标机房的主库501中。

目标机房的主库501，用于将订单的处理信息和路由关系同步至目标机房的第一从库502和第二从库503，实现第一机房和第二机房基于路由关系响应针对订单的读请求得到订单的处理信息。

继续以支付业务场景为例，本发明实施例中，目标机房的主库501利用MHA工具实现单机的主从高可用，将订单的支付信息、以及路由关系同步至位于目标机房本地的一个从库，同时采用数据复制模式同步至跨机房设置的另一从库中。

可见，本申请中第一机房和第二机房都有独立对等的数据库集群50，且设置一个从库在对方机房，以此来保证两机房数据副本的完整性。例如，在第一机房处理订单的写请求时，第一机房的微服务处理器40将订单的处理信息和路由关系写入至第一机房的主库501，第一机房的主库501再采用主从数据复制模式，将订单的处理信息和路由关系同步至第一机房本地的从库、以及部署于第二机房的从库。

基于此，无论是第一机房，还是第二机房处理订单写请求，部署于各自机房的数据库中具有所有订单的相关信息。假设后续第二机房被分配订单的读请求，通过读取部署于本地的两个从库，即可从一个从库中查找到该订单的路由关系、以及相应的处理信息。这种类似分库的思想，使得两个的业务成为独立的服务单元，独立、对等。由于不存在跨机房读取，因此相比“应用层双活，数据库层单活”方式，不但提高了读写能力，也大大提高了服务的可用性和连续性。

在其他一些实施例中，为提高处理系统的抗风险能力，本发明实施例中，目标机房的网关30，还用于：

获取目标机房的微服务处理器40所处理的异常请求的状态，并在异常请求的状态符合预设熔断条件的情况下，将指定时间窗口内接收到的写请求转发至另一机房的网关30，以触发另一机房的网关30、微服务处理器40和主库501执行相应的操作。

本发明实施例中，如果目标机房的数据库集群50发生异常，相应的目标机房的微服务处理器处理写请求时也会发生异常从而产生异常请求。目标机房的网关30可以获取所在机房的微服务处理器40所产生异常请求的数量和/或比例，如果该异常请求的数量和/或比例大于相应的预设阈值(即异常请求的数量对应有预设数量阈值，异常请求的比例对应有预设比例阈值)时，该网关30则触发熔断降级机制，将后续指定时间窗口，比如未来10分钟内所有订单的写请求转发至另一机房的网关30，从而触发另一机房的网关30、微服务处理器40和主库501执行处理写请求的操作，该操作与上述目标机房的网关30、微服务处理器40和主库501的操作一致，在此不再赘述。

当然，在后续超过该指定时间窗口后，目标机房的网关30可以将小比例的订单的写请求发送至目标机房的微服务处理器40，如果目标机房的微服务处理器40能够正常处理而没有产生异常请求，则目标机房的网关30逐步增加发送目标机房的微服务处理器40的订单比例，直至将所有订单的写请求发送至目标机房的微服务处理器40时结束熔断降级机制。后续继续由目标机房的网关30、微服务处理器40和主库501执行处理写请求的操作。

还需要说明的是，每个订单的写请求转发只会发生一次，不会往复转发，以避免形成死循环。

在其他一些实施例中，目标机房可会开放一定流量，将写请求调度至另一机房，以保证系统链路畅通。目标机房的网关30，还用于：

在订单的写请求符合预设流量调度条件的情况下，将订单的写请求转发至另一机房的网关30，以触发另一机房的网关30、微服务处理器40和主库501执行相应的操作。

本发明实施例中，目标机房可以预先流量调度条件，比如设置流量调度的时间窗口，再比如设置流量调度的数量等，将符合该条件的订单的写请求由目标机房的网关30转发至另一机房的网关30，从而触发另一机房的网关30、微服务处理器40和主库501执行处理写请求的操作，该操作与上述目标机房的网关30、微服务处理器40和主库501的操作一致，在此不再赘述。

在其他一些实施例中，为即时探测可用机房，参见图2所示的结构示意图，处理系统还包括：云端服务器60；

机房的微服务处理器40，用于监测机房的数据库集群50的运行状态，并上传至云端服务器60；

云端服务器60，用于将机房对应的运行状态写入到机房列表中；

终端10，具体用于：

通过调用机房列表确定数据库集群50处于可用状态的机房，并基于确定结果发起订单的写请求。

调度服务器20，具体用于：

将订单的写请求发送至数据库集群50处于可用状态的目标机房。

本发明实施例中，第一机房和第二机房各自对应的微服务处理器40能够将所在机房的数据库集群50的运行状态上传至云端服务器60，由云端服务器60将各机房对应的数据库集群50的运行状态写入到机房列表中，并实时更新。终端10基于该机房列表能够主动探测数据库集群50处于可用状态的机房，即可用机房，从而针对性发起订单的写请求，由调度服务器20将写请求分配至可用机房。这就可以提高调度的有效性。

在其他一些实施例中，处理系统也可以拓展为“两地三中心”的部署方案，参见图3所示的结构示意图，该处理系统还包括：

第三机房的第一主库701和第二主库702；

第一机房的主库501，用于将其信息备份至第三机房的第一主库701中；

第二机房的主库501，用于将其信息备份至第三机房的第二主库702中。

本发明实施例中，第一机房和第二机房的主库都可以分别连接到第三机房的两个主库，即将第三机房作为灾备机房，及时备份各机房的数据。

本发明实施例提供的多机房数据库高可用的处理系统，两机房都有独立对等的数据库集群，且设置一个从库在对方机房，以此来保证两机房数据副本的完整性。在一个机房处理订单的写请求后，该订单的处理信息以及该订单与该机房的路由关系写入该机房的主库中，并通过主库主从数据复制模式将数据同步至该机房本地的从库以及跨机房的从库，以此保证后续任意机房处理该订单的读请求的可操作性。可见，本申请中两机房的应用能够同时对外提供服务，两机房的数据库集群也同时能够提供读写服务，满足高可用要求。

基于以上实施例提供的多机房数据库高可用的处理系统，本发明实施例还提供一种多机房数据库高可用的处理方法，该处理方法应用于处理系统中目标机房的网关，该处理方法的方法流程图如图4所示，包括：

S10，接收调度服务器发送的针对订单的写请求，订单的写请求是终端发起的。

S20，将订单的写请求发送至目标机房的微服务处理器，以使目标机房的微服务处理器处理订单的写请求、并将订单的处理信息以及订单与目标机房的路由关系写入至目标机房的主库中，还使目标机房的主库将订单的处理信息和路由关系同步至目标机房的第一从库和第二从库，实现第一机房和第二机房基于路由关系响应针对订单的读请求得到订单的处理信息。

可选的，路由关系包括订单的流水号以及目标机房的机房编号。

可选的，上述处理方法还包括：

获取目标机房的微服务处理器所处理的异常请求的状态，并在异常请求的状态符合预设熔断条件的情况下，将指定时间窗口内接收到的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

可选的，上述处理方法还包括：

在订单的写请求符合预设流量调度条件的情况下，将订单的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

本发明实施例提供的多机房数据库高可用的处理方法，在一个机房处理订单的写请求后，该订单的处理信息以及该订单与该机房的路由关系写入该机房的主库中，并通过主库主从数据复制模式将数据同步至该机房本地的从库以及跨机房的从库，以此保证后续任意机房处理该订单的读请求的可操作性。可见，本申请中两机房的应用能够同时对外提供服务，两机房的数据库集群也同时能够提供读写服务，满足高可用要求。

以上对本发明所提供的一种多机房数据库高可用的处理系统及处理方法进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

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

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备所固有的要素，或者是还包括为这些过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种多机房数据库高可用的处理系统，其特征在于，所述处理系统包括：

终端、调度服务器、以及机房的网关、微服务处理器和数据库集群；其中，

所述机房包括第一机房和第二机房，所述数据库集群包括主库、第一从库和第二从库，所述第一机房的主库和第一从库部署于所述第一机房中、第二从库部署于所述第二机房中，所述第二机房的主库和第一从库部署于所述第二机房中、第二从库部署于所述第一机房中；

所述终端，用于发起针对订单的写请求；

所述调度服务器，用于通过机房流量调度将所述订单的写请求发送至目标机房；

所述目标机房的网关，用于将所述订单的写请求发送至所述目标机房的微服务处理器；

所述目标机房的微服务处理器，用于处理所述订单的写请求；将所述订单的处理信息以及所述订单与所述目标机房的路由关系写入至所述目标机房的主库中；

所述目标机房的主库，用于将所述订单的处理信息和所述路由关系同步至所述目标机房的第一从库和第二从库，实现所述第一机房和所述第二机房基于所述路由关系响应针对所述订单的读请求得到所述订单的处理信息。

2.根据权利要求1所述的处理系统，其特征在于，所述路由关系包括所述订单的流水号以及所述目标机房的机房编号。

3.根据权利要求1所述的处理系统，其特征在于，所述目标机房的网关，还用于：

获取所述目标机房的微服务处理器所处理的异常请求的状态，并在所述异常请求的状态符合预设熔断条件的情况下，将指定时间窗口内接收到的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

4.根据权利要求1所述的处理系统，其特征在于，所述目标机房的网关，还用于：

在所述订单的写请求符合预设流量调度条件的情况下，将所述订单的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

5.根据权利要求1所述的处理系统，其特征在于，所述处理系统还包括：云端服务器；

所述机房的微服务处理器，用于监测所述机房的数据库集群的运行状态，并上传至所述云端服务器；

所述云端服务器，用于将所述机房对应的运行状态写入到机房列表中；

所述终端，具体用于：

通过调用所述机房列表确定数据库集群处于可用状态的机房，并基于确定结果发起所述订单的写请求；

所述调度服务器，具体用于：

将所述订单的写请求发送至数据库集群处于可用状态的目标机房。

6.根据权利要求1所述的处理系统，其特征在于，所述处理系统还包括：

第三机房的第一主库和第二主库；

所述第一机房的主库，用于将其信息备份至所述第三机房的第一主库中；

所述第二机房的主库，用于将其信息备份至所述第三机房的第二主库中。

7.一种多机房数据库高可用的处理方法，其特征在于，应用于多机房数据库高可用的处理系统中目标机房的网关，所述处理方法包括：

接收调度服务器发送的针对订单的写请求，所述订单的写请求是终端发起的；

将所述订单的写请求发送至所述目标机房的微服务处理器，以使所述目标机房的微服务处理器处理所述订单的写请求、并将所述订单的处理信息以及所述订单与所述目标机房的路由关系写入至所述目标机房的主库中，还使所述目标机房的主库将所述订单的处理信息和所述路由关系同步至所述目标机房的第一从库和第二从库，实现第一机房和第二机房基于所述路由关系响应针对所述订单的读请求得到所述订单的处理信息。

8.根据权利要求7所述的处理方法，其特征在于，所述路由关系包括所述订单的流水号以及所述目标机房的机房编号。

9.根据权利要求7所述的处理方法，其特征在于，所述处理方法还包括：

获取所述目标机房的微服务处理器所处理的异常请求的状态，并在所述异常请求的状态符合预设熔断条件的情况下，将指定时间窗口内接收到的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

10.根据权利要求7所述的处理方法，其特征在于，所述处理方法还包括：

在所述订单的写请求符合预设流量调度条件的情况下，将所述订单的写请求转发至另一机房的网关，以触发另一机房的网关、微服务处理器和主库执行相应的操作。

Images