一种分布式数据库系统及电子设备

摘要

本发明提供了一种分布式数据库系统及电子设备，该分布式数据库系统响应于用户发起的数据库访问请求，包括：主控制器、受控于主控制器的Statefulset对象、PDB对象以及代理服务器；Statefulset对象生成若干Pod以形成Pod集群，PDB对象限制Pod集群中的Pod数量的阈值范围，Statefulset对象与PDB对象之间形成引用关系，基于引用关系获取阈值范围，并调整Pod数量位于阈值范围以内；代理服务器对Pod集群进行管理请求以及业务请求转发。通过本发明，实现了分布式数据库的维护和管理不需依赖外部系统，同时能够避免环境控制对象混乱所造成的一系列问题。

权利要求

1.一种分布式数据库系统，响应于用户发起的数据库访问请求；

其特征在于，所述分布式数据库系统包括：主控制器、受控于所述主控制器的Statefulset对象、PDB对象以及代理服务器；

所述Statefulset对象生成若干Pod以形成Pod集群，所述PDB对象限制Pod集群中的Pod数量的阈值范围，所述Statefulset对象与所述PDB对象之间形成引用关系，基于所述引用关系获取所述阈值范围，并调整Pod数量位于所述阈值范围以内；所述代理服务器对所述Pod集群进行管理请求以及业务请求转发；

所述代理服务器部署业务代理，所述主控制器接收业务请求并转发至业务代理，以通过所述业务代理将业务请求转发至Pod集群；

所述业务代理包括：响应主控制器转发的数据写入请求与数据读取请求的主代理和仅响应主控制器转发的数据读取请求的从代理，所述主代理与从代理仅向主控制器予以暴露；

其中，所述Pod内独立部署数据库容器。

2.根据权利要求1所述的分布式数据库系统，其特征在于，所述分布式数据库系统基于部署删除策略的Kubernetes组建，以基于所述删除策略同步地对所述Statefulset对象与PDB对象执行删除操作。

3.根据权利要求2所述的分布式数据库系统，其特征在于，所述PDB对象在收到分布式数据库系统出现自愿中断事件时，通过PDB对象生成维护策略以基于所述维护策略进行维护；所述自愿中断事件包括：Pod维护、升级事件、节点删除事件和Pod删除事件中的一种或者任意几种组合。

4.根据权利要求1所述的分布式数据库系统，其特征在于，所述代理服务器部署管理代理并仅向主控制器予以暴露，通过所述管理代理接收管理请求并由域名系统为每个Pod创建唯一访问名称，并对Pod进行监控以得到每个Pod的状态信息并记录。

5.根据权利要求4所述的分布式数据库系统，其特征在于，所述Pod内部署Init容器以及标签控制器，所述Init容器对同一个Pod中的数据库容器进行初始化以形成独立提供数据库服务的状态，若干Pod所分别部署的数据库容器之间基于主从确定策略确定一个主数据库容器与若干从数据库容器，所述标签控制器读取其所属Pod中的数据库容器的元数据信息，以基于所述元数据信息标识数据库容器所在Pod的角色信息。

6.根据权利要求5所述的分布式数据库系统，其特征在于，所述主代理根据所述角色信息确定主数据库容器并将所述数据写入请求与数据读取请求转发至由所述主从确定策略所确定的主数据库容器，所述从代理根据所述角色信息确定从数据容器并将所述数据读取请求转发至基于所述主从确定策略所确定的从数据库容器。

7.根据权利要求5所述的分布式数据库系统，其特征在于，若当前提供数据库服务的主数据库容器宕机，则基于所述主从确定策略从若干从数据库容器中选取一个从数据库容器作为主数据库容器。

8.根据权利要求1至7中任一项所述的分布式数据库系统，其特征在于，所述分布式数据库系统独立运行于一个计算装置中，所述计算装置为物理机或者虚拟机集群。

9.一种电子设备，其特征在于，包括：

处理器，存储器，以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序；

所述处理器在执行所述计算机程序时执行如权利要求1至8中任一项所述的分布式数据库系统中所包含的逻辑。

说明书

一种分布式数据库系统及电子设备

技术领域

[0001] 本发明涉及数据库技术领域，尤其涉及一种分布式数据库系统及电子设备。

背景技术

[0002] “编排”主要是指用户如何通过某些工具或者配置完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，由云计算平台按照这些指定的逻辑执行的过程。“容器编排”是指定义容器组织和管理规范的工具，尤为典型的就是Kubernetes。Kubernetes是一种容器编排的工具，可作为基础设施搭建应用体系。而搭建的应用体系所包含的应用与应用数据之间处于割裂的状态，无法对应用和应用数据进行统一的管理；同时，应用与应用数据之间还需要搭建通信网络以实现通信，因此通过数据库迁移以实现应用和应用数据的统一成为了一种迫切需求。

[0003] 在数据库迁移过程中，一般通过分布式数据库的方式以实现容错。所谓“容错”技术是指保证系统在某些组成部分出现故障或差错时仍能正常工作的技术，也就是组件可以删除而系统应该继续按照预期运行。分布式数据库以一主多从的方式对外提供服务，数据库自身提供的主从复制功能可以实现数据的多处备份。而对于一主多从所形成的多个数据库需要同时对多个服务器（即，单独的数据库所在的独立的服务器）进行管理和维护。同时，在多个服务器协同工作时，还会出现其他一些分布式数据库的问题，例如断网或者脑裂等。因此，需要对多个服务器、数据库、以及数据复制的逻辑以一种简单一致的方式协调运行的逻辑相融合。

[0004] 现有技术中所揭示的分布式数据库的维护方式需要依赖外部系统（例如，监控系统），而此种方法在外部系统和分布式数据库所在的系统建立通信网络，则会增加系统出错的概率。另一种方法虽然利用了云原生技术，但是不是以组复制技术实现数据库复制，则存在性能不足的缺陷；同时，监控指标需要运维经验予以实现，则存在通用性不足的缺陷。

[0005] 有鉴于此，有必要对现有技术中的分布式数据库系统予以改进，以解决上述问题。

发明内容

[0006] 本发明的目的在于揭示一种分布式数据库系统及电子设备，用以解决现有技术中分布式数据库的维护和管理所存在的需要依赖外部系统、性能不足、以及通用性不足的缺陷。

[0007] 为实现上述目的之一，本发明提供了一种分布式数据库系统，响应于用户发起的数据库访问请求；

[0008] 所述分布式数据库系统包括：主控制器、受控于所述主控制器的Statefulset对象、PDB对象以及代理服务器；

[0009] 所述Statefulset对象生成若干Pod以形成Pod集群，所述PDB对象限制Pod集群中的Pod数量的阈值范围，所述Statefulset对象与所述PDB对象之间形成引用关系，基于所述引用关系获取所述阈值范围，并调整Pod数量位于所述阈值范围以内；所述代理服务器对所述Pod集群进行管理请求以及业务请求转发；

[0010] 所述代理服务器部署业务代理，所述主控制器接收业务请求并转发至业务代理，以通过所述业务代理将业务请求转发至Pod集群；

[0011] 所述业务代理包括：响应主控制器转发的数据写入请求与数据读取请求的主代理和仅响应主控制器转发的数据读取请求的从代理，所述主代理与从代理仅向主控制器予以暴露；

[0012] 其中，所述Pod内独立部署数据库容器。

[0013] 作为本发明的进一步改进，所述分布式数据库系统基于部署删除策略的Kubernetes组建，以基于所述删除策略同步地对所述Statefulset对象与PDB对象执行删除操作。

[0014] 作为本发明的进一步改进，所述PDB对象在收到分布式数据库系统出现自愿中断事件时，通过PDB对象生成维护策略以基于所述维护策略进行维护；所述自愿中断事件包括：Pod维护、升级事件、节点删除事件或者Pod删除事件中的一种或者任意几种组合。

[0015] 作为本发明的进一步改进，所述代理服务器部署管理代理并仅向主控制器予以暴露，通过所述管理代理接收管理请求并由域名系统为每个Pod创建唯一访问名称，并对Pod进行监控以得到每个Pod的状态信息并记录。

[0016] 作为本发明的进一步改进，所述Pod内部署Init容器以及标签控制器，所述Init容器对同一个Pod中的数据库容器进行初始化以形成独立提供数据库服务的状态，若干Pod所分别部署的数据库容器之间基于主从确定策略确定一个主数据库容器与若干从数据库容器，所述标签控制器读取其所属Pod中的数据库容器的元数据信息，以基于所述元数据信息标识数据库容器所在Pod的角色信息。

[0017] 作为本发明的进一步改进，所述主代理根据所述角色信息确定主数据库容器并将所述数据写入请求与数据读取请求转发至由所述主从确定策略所确定的主数据库容器，所述从代理根据所述角色信息确定从数据容器并将所述数据读取请求转发至基于所述主从确定策略所确定的从数据库容器。

[0018] 作为本发明的进一步改进，若当前提供数据库服务的主数据库容器宕机，则基于所述主从确定策略从若干从数据库容器中选取一个从数据库容器作为主数据库容器。

[0019] 作为本发明的进一步改进，所述分布式数据库系统独立运行于一个计算装置中，所述计算装置为物理机或者虚拟机集群。

[0020] 基于相同发明思想，本发明还提供了一种电子设备，包括：

[0021] 处理器，存储器，以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序；

[0022] 所述处理器在执行所述计算机程序时执行如上述任一项发明创造所述的分布式数据库系统中所包含的逻辑。

[0023] 与现有技术相比，本发明的有益效果是：

[0024] 通过本发明，引用PDB对象，实现了Pod集群的高可用能力，保证了Pod集群中Pod数量位于阈值范围以内，还扩展了Kubernetes管理数据库容器的能力。同时，通过在Statefulset对象与PDB对象之间引用关系的建立，防止Statefulset对象的随意删除，避免了环境控制对象混乱导致的一系列问题，例如，产生大量遗留资源及残留文件等问题，并有效地防止了分布式数据库系统中资源的浪费。数据库的容器化，固化了繁琐的分布式数据库维护操作步骤，降低了运维人员对分布式数据库维护技能的需求也降低了很多。通过管理代理对Pod监控，以得到每个Pod的状态信息，不需要对外部系统进行依赖，从而降低减少了对分布式数据库系统执行维护作业所导致的出错的概率。

附图说明

[0025] 图1为本发明示出的一种分布式数据库系统的整体拓扑图；

[0026] 图2为代理服务器的拓扑图；

[0027] 图3为业务代理的拓扑图；

[0028] 图4为本发明所示出的一种电子设备的拓扑图。

具体实施方式

[0029] 下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

[0030] 请参图1至图3所示，本发明示出了一种分布式数据库系统的一种具体实施方式。

[0031] 本发明所示出的一种分布式数据库系统的应用场景为数据库容器化后部署一套高可用集群以实现对数据库容器的管理，以通过系统化的操作降低人为失误和重复劳动，资源使用集中管理，有效利用服务器资源，用以解决现有技术中所存在的分布式数据库的维护和管理所存在的需要依赖外部系统、性能不足、以及通用性不足的缺陷。本发明所示出的分布式数据库系统独立运行于一个计算装置（例如，图1中所示出的计算机系统1）中，该计算装置为物理机或者虚拟机集群。在本实施例中，将分布式数据库系统部署于计算机系统1中予以示范性说明。

[0032] 参图1所示，一种分布式数据库系统，响应于用户所发起的数据库访问请求；其中，数据库访问请求是指数据写入请求以及数据读取请求中的任意一种。分布式数据库系统包括：主控制器10、受控于主控制器10的Statefulset对象21、PDB对象22以及代理服务器2。

[0033] Statefulset对象21生成若干Pod以形成Pod集群，PDB对象22限制Pod集群中的Pod数量的阈值范围，Statefulset对象21与PDB对象22之间形成引用关系，基于引用关系获取阈值范围，并调整Pod集群中的Pod数量位于阈值范围以内，代理服务器2对Pod集群进行管理请求的转发以及业务请求（即，数据写入请求以及数据读取请求）的转发。其中，Pod内独立部署数据库容器。其中，PDB对象22为中断预算（PodDisruptionBudget）；Statefulset对象21顾名思义“有状态的集合”，用于管理所有有状态的服务，例如，MySQL、MongoDB集群等。

[0034] 具体地，将若干独立的数据库容器化后，以形成独立的数据库容器（即，MySQL‑1~MySQL‑n，其中，n取大于等于2的正整数），数据库容器之间为相互独立的关系，可独立为用户提供数据库服务。同时，数据库容器之间可以基于主从确定策略自定义确定一个主数据库容器和若干从数据库容器。其中，主数据库容器用以对外提供数据写入服务和数据读取服务，从数据库容器用以对外提供数据读取服务。当然，也可以是由自定义用户确定一个主数据库容器和若干从数据库容器，优选为，由若干独立的数据库容器之间基于主从确定策略自定义确定一个主数据库容器和若干从数据库容器，从而基于系统化的操作不需要用户手动操作以达到减少人为失误和重复劳动的目的。

[0035] Statefulset对象21创建若干Pod（即，Pod‑1 Pod‑n，其中，n取大于等于2的正整~数）以形成Pod集群，将数据库容器独立部署至Pod中，即，每个Pod中部署一个数据库容器。
例如图1中所示出的，将MySQL‑1部署至Pod‑1，依次类推，将MySQL‑n部署至Pod‑n。

[0036] 若干数据库容器（即，MySQL‑1 MySQL‑n）基于主从确定策略确定一个数据库容器~和若干从数据库容器。该主从确定策略可以是由用户以自定义下发的逻辑予以配置，也可以是分布式数据库系统预先配置并由用户选择予以确定，本实施例对此不作限定。主从确定策略的具体内容例如可以是将第一个生成的数据库容器作为主数据库容器，还可以是将配置最高的数据库容器作为主数据库容器，只要能够保证分布式数据库系统中仅有一个主数据库容器和若干从数据库容器即可。当主数据库容器被移除或者宕机导致该主数据库容器不能继续提供数据写入服务或者数据读取服务，则基于主从确定策略从若干从数据库容器中选取一个从数据库容器作为主数据库容器，以保证主数据库容器对外提供数据写入服务或者数据读取服务不中断，从而达到保证用户体验的目的。

[0037] 参图2所示，代理服务器2部署管理代理23和业务代理24。管理代理23仅向主控制器10予以暴露，即，仅受控于主控制器10。具体而言，通过管理代理23接收自用户所下发的管理请求并由域名系统为每个Pod创建唯一访问名称，以实现Pod的唯一定位。Pod中所部署的init容器内部进行初始化脚本，分别访问Pod中所部署的数据库容器，进行初始化并启动数据库容器，以形成独立提供数据库服务的状态。在进行初始化并启动之后的数据库容器才能正常对外提供数据库服务（例如，前述数据写入服务和数据读取服务）。例如，Pod‑1所部署的init容器‑1内部进行初始化脚本，并访问MySQL‑1以对MySQL‑1进行初始化并启动，依次类推。在若干Pod分别部署的数据库容器之间基于主从确定策略确定一个主数据库容器与若干从数据库容器之后，Pod中所部署的标签控制器读取其所属Pod中的数据库容器的元数据信息，以基于元数据信息标识数据库容器所在Pod的角色信息。例如，在Pod‑1中，标签控制器‑1读取MySQL‑1的元数据表‑1，以基于元数据表‑1确定MySQL‑1为主数据库容器还是从数据库容器。若MySQL‑1为主数据库容器，则标识Pod‑1的角色信息为主；若MySQL‑1为从数据库容器，则标识Pod‑1的角色信息为从，依次类推。

[0038] 需要说明的是，管理代理23即为Governing Service，受控于主控制器10，用于接收自用户下发的管理请求并由域名系统为每个Pod创建唯一访问名称，并对Pod进行监控，以得到每个Pod的状态信息并记录。由于默认环境下，只有Pod进入就绪状态时才会生成与之对应的记录，因此为稳定管理的需要，设置“publishNotReadyAddress=true”，以取消该限制，从而保证所有的Pod（即，进入就绪状态的Pod以及未进入就绪状态的Pod）均会生成与之对应的记录。init容器是Pod的三大容器之一，用于运行初始化任务，以保证容器内的运行环境。因此，通过init容器对数据库容器进行初始化并启动，以保证数据库容器能够正常对外提供数据库服务（即，数据写入服务或者数据读取服务）。标签控制器即为LabelController，部署于Pod中，用于读取同一Pod中部署的数据库容器的元数据信息，以基于元数据信息标识该Pod的角色信息。由于在Kubernetes环境下，Statefulset对象21提供的语义保证相同名字的Pod在Pod集群中仅有一个，也就是如果发生了宕机，而Statefulset对象21是不会做故障转移的。Kubernetes会简单地重新调度生成一个Pod，但是原有数据库容器之间的主从关系，可能就会紊乱。因此在Pod中部署标签控制器以标识Pod的角色信息，从而告知外界自身的业务角色，以防止主从关系的紊乱。

[0039] 参图3所示，业务代理24包括主代理241与从代理242。主代理241与从代理242仅向主控制器10予以暴露，即，受控于主控制器10。主控制器10接收业务请求并转发至业务代理24，以通过业务代理24将业务请求转发至Pod集群。其中，主代理241用于响应主控制器10转发的数据写入请求与数据读取请求，从代理242用于响应主控制器10转发的数据读取请求。
在Pod中部署标签控制器，并通过标签控制器对各自所属的Pod标识角色信息后，主代理241根据角色信息确定主数据库容器（即，根据角色信息确定主Pod，从而确定主Pod中部署的主数据库容器），并将数据写入请求与数据读取请求转发至主数据库容器，以通过主数据库容器提供数据写入服务和数据读取服务；同理，从代理242根据角色信息确定从数据库容器，并将数据读取请求转发至从数据库容器，以通过从数据库容器提供数据读取服务。其中，主代理241即为Primary Service，从代理242即为Standby Service。

[0040] 参图1所示，Statefulset对象21与PDB对象22之间形成引用关系。Statefulset对象21创建Pod以形成Pod集群。PDB对象22在收到分布式数据库系统出现自愿中断事件时，通过PDB对象22生成维护策略以基于维护策略进行维护。由于Pod集群需要保持高可用，则节点数量则需要尽可能地保持稳定。若出现宕机的情况，则需要通过一套机制以应对，因此通过PDB对象22应对自愿中断的情况。自愿中断事件包括：Pod维护、升级事件、节点删除事件或者Pod删除事件中的一种或者任意几种组合。例如，排空节点进行修复或升级，从集群中排空节点以缩小节点，从节点中移除一个Pod以允许其他Pod使用该节点，删除管理Pod的控制器，更新Pod模板导致Pod重启，意外删除Pod等。

[0041] PDB对象22限制Pod集群中的Pod数量的阈值范围。PDB对象22包括两个关键参数“.spec.minAvailable”与“.spec.maxUnavailable”。其中，参数“.spec.minAvailable”表示发生自愿中断的过程中，需要保证的最少可用的Pod数量或者比例，参数“.spec.maxUnavailable”表示发生自愿中断的过程中，需要保证的最大可用的Pod数量或者比例。因此通过建立Statefulset对象21与PDB对象22的引用关系，Statefulset对象21基于该引用关系获取阈值范围，以调整Pod数量位于该阈值范围内（例如，Pod数量小于阈值范围，则创建Pod，并将数据库容器独立部署于Pod中等等），从而保证Pod集群中所包含的数据库容器的高可用，同时还提升了Kubernetes管理数据库容器的能力。另外，Statefulset对象21与PDB对象22之间形成引用关系后，还用于应对Kubernetes的删除操作，防止出现随意删除的情况，避免环境控制对象混乱导致的一系列问题。在Statefulset对象21删除后，用于限制Pod数量的PDB对象22也就没有了作用，因此通过引用关系将其也进行删除，防止Statefulset对象21被单独删除，从而达到防止产生大量遗留资源及残留文件的目的。建立Statefulset对象21与PDB对象22的引用关系（即，建立OwnerReference的引用关系）。因此，分布式数据库系统基于部署删除策略的Kubernetes组建，以基于删除策略同步地对Statefulset对象21与PDB对象22基于所述引用关系对Statefulset对象21与PDB对象22同步地执行删除操作。

[0042] 通过本发明所揭示的分布式数据库系统，通过引用PDB对象22，实现了Pod集群的高可用能力，保证了Pod集群中Pod数量位于阈值范围以内，以保证Pod集群中包含的数据库容器的高可用，同时还扩展了Kubernetes管理数据库容器的能力。另外，通过在Statefulset对象21与PDB对象22之间引用关系的建立，防止Statefulset对象21的随意删除，避免了环境控制对象混乱导致的一系列问题，例如，产生大量遗留资源及残留文件等问题，并有效地防止了分布式数据库系统中资源的浪费。数据库的容器化，固化了分布式数据库维护操作步骤，降低了运维人员对分布式数据库维护技能的需求。通过管理代理23对Pod监控，以得到每个Pod的状态信息，不需要对外部系统进行依赖，从而降低了对分布式数据库系统执行维护作业所导致的出错概率。

[0043] 基于前述实施例所揭示的一种分布式数据库系统的具体实施方式所包含的技术方案，本实施例还揭示了一种电子设备500的具体实施方式。

[0044] 参图4所示，本实施例揭示了一种电子设备500，包括：处理器51、存储器52以及存储在存储器52中且被配置为由所述处理器51执行的计算机程序，该处理器51在执行所述计算机程序时执行如前述实施例所述的一种容器化数据库部署方法中的步骤。具体地，该存储器52由若干存储单元组成，即存储单元521 存储单元52j，其中，参数i取大于或者等于二~的正整数。处理器51与存储器52均接入系统总线53。系统总线53的形式并不需要予以具体
2
限定，I C总线、SPI总线、SCI总线、PCI总线、PCI‑e总线、ISA总线等，并可根据电子设备500的具体类型及应用场景需求予以合理变更。系统总线53并非本申请发明点，故在本申请中不予展开陈述。

[0045] 需要说明的是，本实施例中的存储单元52可为物理态的存储单元，从而将电子设备500理解为物理态的计算机或者计算机集群或者集群服务器；同时，存储单元52还可为虚拟态的存储单元，例如基于物理存储设备通过底层虚拟化技术所形成的虚拟存储空间，从而将该电子设备500配置为虚拟服务器、虚拟集群等虚拟装置，或者将该电子设备500理解为PC、平板电脑、智能手机、智能可穿戴电子设备、物理集群或者数据中心等。

[0046] 本实施例所示出的电子设备500与前述实施例具有相同部分的技术方案，请参照前述实施例所示，在此不再赘述。

[0047] 本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路（ASIC），现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

[0048] 上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

[0049] 对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

[0050] 此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。