1.本说明书涉及计算机
技术领域：
：，尤其涉及一种分布式数据库的负载均衡方法、装置、设备及介质。
背景技术：
：：2.随着互联网的发展，互联网数据规模的不断扩大，数据存储的需求越来越大，进而产生了数据库。数据库是一个按数据结构来存储和管理数据的计算机软件系统。在实际应用中，对数据可靠性要求越来越高。为此，需要对数据库的负载均衡进一步改进。技术实现要素：3.本说明书一个或多个实施例提供了一种分布式数据库的负载均衡方法、装置、设备及介质，用于解决
背景技术：
：提出的技术问题。4.本说明书一个或多个实施例采用下述技术方案：5.本说明书一个或多个实施例提供的一种分布式数据库的负载均衡方法，包括：6.将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点；7.遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量；8.根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率；9.根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。10.本说明书一个或多个实施例提供的一种分布式数据库的负载均衡装置，所述装置包括：11.分片副本处理单元，将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点；12.分片副本统计单元，遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量；13.负载率确定单元，根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率；14.负载均衡单元，根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。15.本说明书一个或多个实施例提供的一种分布式数据库的负载均衡设备，包括：16.至少一个处理器；以及，17.与所述至少一个处理器通信连接的存储器；其中，18.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：19.将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点；20.遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量；21.根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率；22.根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。23.本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：24.将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点；25.遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量；26.根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率；27.根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。28.本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：本说明书实施例通过恢复分布式数据库的缺失分片副本与丢弃分布式数据库的多余分片副本，以得到分布式数据库中符合要求的节点，便于后续对分布式数据库的节点进行负载均衡处理。通过确定各符合要求的节点的负载率，以调整各符合要求的节点中的分片副本数量，完成分布式数据库的负载均衡，以此改进使得数据可靠性更好。附图说明29.为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：30.图1为本说明书一个或多个实施例提供的一种分布式数据库的负载均衡方法的流程示意图；31.图2为本说明书一个或多个实施例提供的分片副本缺失恢复示意图；32.图3为本说明书一个或多个实施例提供的垃圾分片回收示意图；33.图4为本说明书一个或多个实施例提供的数据分片恢复示意图；34.图5为本说明书一个或多个实施例提供的用户访问分布式数据库的示意图；35.图6为本说明书一个或多个实施例提供的master服务示意图；36.图7为本说明书一个或多个实施例提供的第一master选主流程图；37.图8为本说明书一个或多个实施例提供的第二master选主流程图38.图9为本说明书一个或多个实施例提供的namespace创建流程图；39.图10为本说明书一个或多个实施例提供的一种分布式数据库的负载均衡装置的结构示意图；40.图11为本说明书一个或多个实施例提供的一种分布式数据库的负载均衡设备的结构示意图。具体实施方式41.本说明书实施例提供一种分布式数据库的负载均衡方法、装置、设备及介质。42.为了使本
技术领域：
：的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。43.图1为本说明书一个或多个实施例提供的一种分布式数据库的负载均衡方法的流程示意图，该流程可以由分布式数据库的负载均衡系统执行，可以对分布式数据库进行负载均衡处理，以提高数据可靠性。流程中的某些输入参数或者中间结果允许人工干预调节，以帮助提高准确性。44.本说明书实施例的方法流程步骤如下：45.s102，将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点。46.在本说明书实施例中，将所述分布式数据库的缺失分片副本进行恢复，以尽可能的优先恢复缺失的分片，过程中，先扫描所述分布式数据库中的节点，并确定各节点的分片副本数量；再将所述缺失分片副本进行标记；然后，根据所述负载率对所述分布式数据库的各节点进行排序；最后，将标记的缺失分片副本添加到负载率低于预设值的节点。47.在本说明书实施例中，将所述分布式数据库的多余分片副本进行丢弃时，是垃圾分片回收的流程，以把多余的分片副本删除。过程中，先扫描所述分布式数据库中的节点，并确定各节点的分片副本数量；再根据所述各节点的分片副本数据，确定分片副本数量超出预设配额的不合规节点；最后，在所述不合规节点内确定多余的分片副本，并将所述多余的分片副本进行丢弃。48.s104，遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量。49.在本说明书实施例中，确定所述各符合要求的节点中的分片副本数量时可以通过统计的方式。50.s106，根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率。51.在本说明书实施例中，可以根据所述各符合要求的节点中的分片副本数量与预先设定的容量，确定所述各符合要求的节点的负载率。预先设定的容量可以为预先设定的各符合要求的节点的最佳容量。各符合要求的节点的负载率在计算时，可以根据各符合要求的节点中的分片副本数量除对应节点的容量。52.s108，根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。53.在本说明书实施例中，根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量时，可以遍历所述各符合要求的节点的负载率，若第一指定符合要求的节点的负载率大于平均负载，调整所述第一指定符合要求的节点中的分片副本数量。54.进一步的，在本说明书实施例中，根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量时，可以遍历所述各符合要求的节点的负载率，若第二指定符合要求的节点的负载率不大于平均负载，将所述第一指定符合要求的节点中的分片副本数量调整到所述第二指定符合要求的节点中。55.进一步的，完成所述分布式数据库的负载均衡后，可以将所述各符合要求的节点中的节点数据存储到预先设定的树型存储中间件。56.针对上述的分布式数据库的负载均衡方法，可以把节点的数据平衡过程称之为rebalance，把分片副本缺失恢复的过程称为recover，把多余副本丢弃的过程称为garbagecollect。对于分区信息采取partition进行描述。57.recover是数据分片恢复的流程，每次执行rebalance的过程中首先需要恢复数据分片才进行rebalance，这样做的目的是尽可能的优先恢复缺失的分片。例如当前一共是4096个分区2副本，若当前出现分区缺失，丢失了分区1的副本，此时执行recover流程即可以恢复分区该缺失的副本。分片副本缺失恢复示意图如图2所示。58.recover流程是首先需要扫描所有分布式数据库中的节点，统计所有节点的副本数量；然后把缺失的分片进行标记；接着开始遍历所有被标记的分片，对于现有活跃的数据节点按照负载进行排序(节点的分片数量/节点的容量)，然后从负载较低的节点中选取一个不包含该缺失分片的数据节点，把标记的分片加入到该节点中。59.garbagecollect是垃圾分片回收的流程。如图3所示的垃圾分片回收示意图，例如数据是2副本，由于rebalance是把某个分片移动到其他的分片，这个过程会导致分片数量会增加可能变成3副本，因此在最后需要把多余的分片删除。60.garbagecollect流程首先是扫描所有分布式数据库中的节点，统计所有分片在活跃节点的副本数量；然后提取所有副本数超过配额的分片，移除超出副本数量的非主分片。61.rebalance是数据负载均衡的核心流程，需要把较高负载的分片移动到较低负载的分片上，这样会让数据尽可能的在存储节点中平衡。如图4所示的数据分片恢复示意图，执行rebalance之后某些分区的副本数量会增加，多余的分区会在下一个rebalance流程中garbagecollect是删除。62.rebalance具体流程的设计:63.(1)执行recover流程，如果出现副本缺失则等待下一个rebalance周期。64.(2)执行garbagecollect流程，如果出现多余的副本，则等待下一个rebalance周期。65.(3)遍历各个分片，统计各个节点的分片数量。66.(4)遍历所有的活跃节点，如果节点是低负载节点负载率小于平均负载(节点的分片数/节点的容量大小《总分片数量*负载平衡容忍参数/总容量)，那么加入到低负载集合。67.(5)对所有活跃的数据节点按照负载排序(节点的分片数量/节点的容量)。68.(6)遍历数据节点，从高负载到低负载遍历，每个节点为n[i]。[0069](7)如果n[i]是一个低负载节点，那么退出本次rebalance，对于n[i]每一个非master分片，尝试分配到低负载节点集合中的一个节点，并且执行(4)。[0070]当rebalance流程结束之后，元数据中心会把计算好的分区数据存储到zookeeper中。[0071]进一步的，本说明书实施例针对现有存储的一些问题，需要一个方便访问，可弹性扩容的数据库，针对实时存储部分，需要做到基于ssd存储，热点数据在内存缓存，非热点数据都是磁盘产生的，对于离线存储部分，需要解决数据膨胀等问题，降低副本数量，降低存储成本。[0072]用户访问分布式数据库的示意图如图5所示，客户端首先需要知道集群中元数据中心master的ip和端口号，然后访问master获取集群的元数据例如分片信息以及datanode的节点的ip和端口号。datanode是具体存放数据的节点，是通常会部署在单个物理机或容器实例。datanode具体部署的应用类型可以分为离线存储和实时存储。[0073]本说明书实施例后续将说明元数据中心的设计和实现。[0074]专用名词讲解：[0075]node：节点，组成集群的物理机器或者是实例，在本说明书实施例中可以分为datanode或master，其中datanode也可以分为batchstorage和realtimestorage。[0076]batchstorage：批量存储，离线存储，通常是不允许数据变更，只提供只读服务，数据规模比较大，单个表通常有几t到几百t不等的数据，数据文件由hadoopmapreduce产出并且由数据导入器下载数据，并提供服务。[0077]realtimestorage：实时存储，提供读写服务，支持简单事务，因此性能上没有离线存储高。[0078]master：可以类比hadoophdfs中的namenode节点，客户端通常通过master获取元数据再与各个datanode进行通信，为了提高容错性，master通常会部署多个，当leadermaster宕机其他的master会代替进行服务。[0079]namespace：资源配置和数据组织的单位，一系列table的集合。某个datanode只能配置在一个namespace下，以保证资源、io都是物理隔离的。namespace也可以类比mysql的数据库概念。[0080]table：逻辑概念，逻辑上一个namespace中的数据可以分属于不同的table，用于可以按table查询，但是底层存储的时候不分table，同一个db中不同table的数据会存储在一起，key有一个额外的属性标识table。[0081]partition：分片。一个namespace的数据量太大，以至于单机无法存储，在simpledb使用分片存储，把一个db中的数据分成4096个part，分散到不同机器上，每个分片有主副两副本，提供failover机制。[0082]eventualconsistency:最终一致性,是指当没有新更新的情况下，更新最终会通过网络传播到所有副本点，所有副本点最终会一致，应用层在最终某个时间点前的中间过程中无法保证看到的是新写入的数据。[0083]rebalance:数据平衡，因为一些不确定因素例如节点上线，下线导致每个节点上面的分片数据不一致，因此数据需要根据分片数量进行重新计算把负载比较重的节点上的数据转移到负载比较轻的节点上，使各个节点接受的请求量以及数据存储量相当[0084]由于单个服务器的资源是有限的，单机数据库无法存储海量的数据，因此需要引入分布式数据库来存储大规模数据。但由于分布式系统的引入却带来一系列分布式问题，例如一致性，可用性，分区容错性问题等。但由于广告库，feed流数据对数据的一致性要求并不敏感，但是却希望系统能提供高的可用性，因此根据分布式系统下cap定律选取存储需求选取可用性和分区容错性，即ap系统。ap系统的好处是在分布式系统中数据同步的开销更低，也不在乎数据的版本是否是最新的，而且访问结果总是可控的。例如一次读操作可能读取的数值并不是最新值，但不会因为该数据因为数据在等待同步完成而造成访问超时。[0085]海量数据只能存储在多台服务器中，但是这么多数据如何存储，以及数据在多台服务器上是以怎样的方式排列存放的，就需要用元数据来描述。[0086]下面针对元数据中心的设计和实现进行详细说明：[0087]1、总体结构设计分析[0088]元数据包括了数据库名、表名、集群的节点信息、数据库的分片信息等。这些信息在整个分布式数据库中起到了非常关键的作用。例如客户端访问等都需要通过元数据来了解集群中节点的数量以及查询时具体需要访问哪些数据节点。元数据有时需要变更，例如用户创建namespace，创建表等，因此需要数据库提供元数据管理的接口。[0089]由于元数据的修改、建表改表等对于数据接入用户来说是比较常用的操作。为了提高系统的易用性以及降低分布式系统的数据冲突问题，元数据的管理应该像gfs等系统一样独立成为管理服务，并且通过元数据服务来控制，发放整个集群的元数据。[0090]对于系统管理员来讲，需要及时了解系统状态，因此需要集群的信息的收集的rpc接口。因为系统需要一些扩容缩容操作，因此也需要提供对数据节点的添加删除等操作接口。[0091]由于分布式系统中不能数据存储的一致性，因此元数据具体的存储位置也需要进行抉择。常用的元数据存储方式有集中元数据、元数据分布式存储、元数据中心无状态服务化。[0092]1.1、集中元数据[0093]集群中需要有一个可靠的元数据服务器，负责记录协调表、分片。通知数据产出进行整个集群范围内的下载文件加载，版本切换。[0094]集中元数据的好处是逻辑简单，方便管理，但也存储在元数据服务器需要保持高可用性，一旦元数据中心意外宕机，整个服务都将不可用。[0095]1.2、元数据分布式存储[0096]不提供master节点，集群中每个节点提供自己本机存储表，分片信息，及分片对应的文件目录及记录下载进度(离线数据部分)。只要汇总集群中所有节点元数据就可以获取整个集群整体状态。虽无中心，但元数据模块有主，只有被选为master节点的元数据模块才能更新元数据信息，然后同步到集群内所有其它节点。当master宕掉的时候，集群会选举新的master节点。[0097]元数据分布式存储会保证集群高可用，任何元数据/查询服务节点宕机，都不会影响检索服务，但是为了保持各节点的元数据的一致性。实现复杂度较高，一些常用的解决方案是通过paxos选举出元信息中心节点，由中心节点负责将元数据复制到所有节点进行持久化。中心节点宕机后新选举出的中心节点。这样既方便的保证了元数据的一致性，又保证了集群的高可用性。[0098]1.3、元数据中心无状态服务化[0099]集群可以把具体的存储委托给其他分布式组件例如zookeeper或etcd集群，元数据中心只负责接收请求并异步缓存，降低原理存储服务的查询压力，而且元数据中心服务化可以方便扩容，元数据服务选主等问题也可以依赖分布式锁来解决。[0100]2、元数据服务设计[0101]数据节点的存在通常是对用户透明的，像googlefilesystem一样用户通常需要知道一个集群中的leader节点直接面向用户提供一些基本的服务，这个服务通常称为元数据服务。元数据服务记录整个集群的节点状态，维护namespace、table、partition等非常重要的信息。用户的一些建表，该表服务也都是通过元数据服务提供的修改接口实现的。[0102]本节包括元数据服务选主，元数据存储，元数据类，负载均衡的设计。其中元数据服务选主是元数据服务在部署多个实例服务下，元数据服务是如何选取主服务进行提供元数据写入服务。元数据存储是描述了如何存储元数据，负载均衡是元数据是如何进行分片分区计算的。[0103]2.1、元数据服务选主的设计[0104]为了提高元数据服务的可靠性，采取了元数据无状态服务化的方式管理元数据。如图6所示的master服务示意图，masterservice会启动多个实例，但自身几乎不保存数据，所有的元数据都使用zookeeper进行存储。[0105]为了避免分布式系统的冲突，多个masterservice需要进行选主操作。只有成功选主的masterservice才能接收写请求。每个masterservice都定时去在zookeeper根节点下创建临时节点，内容是，成功获取到锁则认为是一个leader节点，可以接受元数据写请求，执行数据rebalance，其余的master只能接收读请求，客户端查询数据的时候需要跟master进行通信获取分片信息。[0106]一旦主master宕机，由于主master跟zookeeper之间的通信中断，主master在zookeeper中申请的临时节点的就会自动消失，其他从master就会开始对zookeeper下这个节点加锁，成功加锁的节点就会升级为主节点，执行节点探活，数据rebalance等逻辑，这个过程如图7所示的第一master选主流程图。[0107]2.2、元数据存储的设计[0108]zookeeper是一种树型存储中间件。元数据都是这样存放在一个节点中或节点下。为了提高zookeeper的利用率，通常会先建一个根节点。[0109]元数据表示如下表1所示，元数据主要有namespacetablenodepartition等，这些都将用protobuf生成的c++class来表示。[0110]表1元数据节点设计[0111][0112]namespace类似于数据库的概念，每个namespace之间互不影响提供给不同的业务使用，每个namespace下可以建立多个表，每个datanode只能挂载到一个namespace下，后续数据负载均衡也将以namespace为单位进行负载均衡，table类似数据库表的概念，node指的是数据节点(bs/rs)，partition是分区信息，代表分片，因为元数据接口经常是需要被序列化为protobuf的，所以使用protobufmessage来描述元数据，元数据都是存放在zookeeper中进行存储。[0113]因为元数据都是挂载到zookeeper中，挂载路径如下表2所示。因此可以在一个namespace下挂载多个table节点。node节点跟table不同，node是通过protobuf序列化之后直接存储在单个节点下。[0114]表2元数据节点路径设计[0115][0116]2.3、元数据类设计[0117]元数据虽然都是存放在zookeeper中，但是为了提高可维护性以及可移植性，需要对元数据用protobuf来表示。[0118]namespace中name代表的是命名空间的名字类型为byte数组，实际是存储的是字符串utf-8的二进制；type是代表数据库类型，支持离线存储或实时存储，用字符串bs或rs表示。partition_num是数据分片数量，分片数量这个比较重要，是数据库对key进行hash之后分区的的标准，限于目前数据的rebalance策略，这个值指定后不能随意更改，一般设置为4096个分片。replica是副本数量，对于可靠的服务来讲副本数量应当大于等于2，否则可能会因为数据节点宕机导致某一时刻服务不可用，但是副本数量增大会导致数据冗余数据过多。总分片数量就是replica*partition_num。version是元数据版本，每次更新namespace的时候都会生成一个时间戳作为版本号。为日后元数据恢复等操作留有一定的接口。rebalance是执行数据负载均衡时的参数。[0119]table节点主要描述了表的元数据类图。对于实时表来讲，只有name、type、cache_ttl、name_space是有效的。name是表名；type是表类型，同样是离线和实时两种，表的类型必须挂载到同样类型的namespace下；cache_ttl是数据库缓存的有效期。对于离线表来说url以及priority都是必选项。url代表离线表从hdfs中的导入路径；priority代表数据从hdfs下载的优先级，优先级越高数据越优先下载。[0120]node节点主要描述了节点的元数据。所有的datanode节点都需要加入到node节点列表。方便master执行rebalance以及整个集群的管理功能，其中的ip代表节点的ip，port是节点对系统内接口。像一些对内暴露的rpc服务例如节点信息收集以及元数据派发都是通过该端口进行通信的。query端口是系统对外端口，客户端等都是通过该端口执行get/set等服务操作。sync端口是数据同步端口，实时存储会使用该端口进行数据同步通信的操作。[0121]partition是集群的分片信息。pid是分区编号，nodes是该分区的节点列表。分片信息主要描述了分布式数据库下某个数据分片在哪几个节点。为了防止单个机器故障导致服务不可用，每个分片应当分布在不同的节点下。分片信息是主master节点通过rebalance操作进行计算的并且存储在zookeeper中。[0122]2.4、元数据服务类设计[0123]masterservice是master对外提供的rpc接口，masterserviceimpl是其具体实现，zkclient是zookeeper提供的c++api，提供了一些关于zookeeper的操作接口，节点增删改查的基本功能，storage主要负责系统中元数据的存储是对zkclient的封装，降低maserserviceimpl类和zookeeper提供的api的耦合，方便当元数据存储换更换非zookeeper可以减少类的修改。syncer是masterservice跟datanode进行元数据的类，通过send_sync_meta()方法把元数据下发给datanode。rebalancer是主要负责数据负载均衡相关的计算，并且通过syncer把元数据发放到datanode。collector同样跟datanode进行通信，负责节点探活，获取内存和ssd容量相关信息。[0124]masterservice中alter_namespace是对用户提供namespace的修改的rpc接口，进行namespace级别下的命名空间修改。用户可以通过该接口创建、删除namespace。[0125]用户为了方便维护管理自己的表，masterservier提供了alter_table。用户可以通过该接口在元数据服务进行表结构的修改。[0126]集群的rebalance通常是需要接受系统管理员的控制的，因此需要对系统管理员提供提供rebalance管理接口，分别是rebalance和disrebalance接口，方便系统管理员对整个rebalance过程进行控制。系统管理员可以通过这个接口控制集群的rebalance行为。[0127]3、元数据服务的实现[0128]3.1、元数据存储与读入的实现[0129]master通过zookeeper提供的api来进行与zookeeper的访问，但是有些访问的函数重复的比较多在c++中可以使用模板函数解决，为了方便调试，存放在zookeeper的数据不是二进制数据而是文本数据，可读性更强，除此之外选用模板函数是在编译期间完成替换，因此效率会比虚函数更高一些。[0130]数据写入节点时的实现:[0131]输入是zookeeper的路径，通过设计模板函数，让任意生成的c++类都可以把debugstring写入到zookeeper的节点。[0132]template《typenamet》[0133]statusstorage::write_node(conststd::string&path,constt&v){[0134]intret＝_zk_client-》writedata([0135]path.c_str(),v.shortdebugstring().c_str(),v.shortdebugstring().size(),[0136]v.has_version()？v.version():-1)；[0137]//ellipsissomecode[0138]returnconvert_ret(ret)；[0139]}[0140]数据读入的实现:[0141]数据读入流程跟数据写入是相反的过程，输入是zookeeper的路径，以及数据通过debugstring反序列化的实体proto类型，通过设计模板函数，让任意生成的c++类都可以把debugstring反序列化到目标proto中。[0142][0143]数据读入时需要注意buffer需要在堆中申请的内存，因为随着表的数量增加，有可能造成栈溢出。[0144]3.2、master选主的实现[0145]master选主的流程:[0146]master每隔一段时间就尝试在某个目录下建立临时节点，成功建立节点即可认为该master是一个leader节点，否则认为是一个follower节点，过程如图8所示的第二master选主流程图。[0147]其中通过c++api创建临时节点的具体实现如下:[0148]intret＝_zk_client-》createephemeral(_node_path.data(),_ip.c_str(),_ip.length())。[0149]3.3、元数据服务对外接口[0150]因为brpc需要提供服务接口，主要包含了元数据的增删改查等常用操作，另外提供rebalance接口等主要目的是提供集群的管理。对用户提供alter_namespace，alter_table等接口。[0151]alter_namespace主要是数据库管理变更等操作，具体的操作是变更zookeeper中保存的节点。在zookeeper的namespace节点下创建namespace节点。然后创建node等其他节点。这些节点需要在namespace创建的过程中创建完成，后续具体的表等节点都需要挂载到这些节点下面，这个过程如图9所示的namespace创建流程图。[0152][0153][0154]其中storage调用2.1中的数据写入zookeeper方法，完成对zookeeper的修改。对于其他元数据请求跟命名空间请求类似，同样是对zookeeper节点的维护，故不再赘述。[0155]3.4、负载均衡的实现[0156]recover流程的实现:[0157]recover首先需要需要补齐缺失的分区。如果当前ns的分区定义和元数据实际的分区不符合。就把需要恢复的分区加入到需要恢复的分区列表。初次之外还需要把非活跃的节点作为副本丢失进行处理。[0158]if(distribution.partitions_size()！＝_ns-》partition_num()){[0159]for(inti＝0；i《_ns-》partition_num()；++i){[0160]_partition_to_missing_replica_num[i]＝_ns-》replica_num()；[0161]_partition_to_replicas[i].clear()；[0162]}[0163]for(autop:distribution.partitions()){[0164]_partition_to_missing_replica_num.erase(p.pid())；[0165]}[0166]}[0167]随后对于每一个需要进行恢复的分区进行恢复，即根据节点的负载进行排序，选择负载较小的一个节点，并且尝试把缺失的分区加入到其中。如果假如成功，就记录该分区，并且开始恢复下一个分区。当整个流程执行完毕，缺失的分区就会被恢复。[0168]for(auto&&iter:_partition_to_missing_replica_num){[0169]autopartition＝iter.first；[0170]automissing_replica_num＝iter.second；[0171]//prioritytorecoverthepartitiontolittleusagenode[0172]sort_nodes_by_usage(_active_nodes)；[0173]for(autonode:_active_nodes){[0174]//skipnodeifitalreadyhassamepartition[0175]if(！match_distribute_partition_strategy(partition,node)){[0176]continue；[0177]}[0178]if(missing_replica_num‑‑＝＝0){[0179]break；[0180]}[0181]add_partition_to_node(partition,node)；[0182]rebalance_log(partition,node,recover_add)；[0183]}[0184]}[0185]garbagecollact的实现:[0186]垃圾分片回收与recover流程类似，只是统计的是冗余的分片，故不再赘述。[0187]rebalance的实现:[0188]rebalance首先需要计算所有的节点的负载情况，把超过负载和低于负载的节点找出。[0189]//1.finddisproportionnodes[0190]for(autonode:_active_nodes){[0191]if(is_usage_overbalance_node(node)){[0192]_overbalance_nodes.insert(node)；[0193]}elseif(is_usage_underbalance_node(node)){[0194]_underbalance_nodes.insert(node)；[0195]}[0196]}[0197]rebalance随后需要遍历所有低于负载的节点，并且把所有的节点按照负载，由高到低进行排序。把高负载的节点中的分区依次转移给低负载的节点。整个流程结束就可以实现把高负载的数据转移到低负载节点。[0198][0199]需要说明的是，上述元数据设计原理和实现都比较简单，性能对比目前现有的数据库来讲也是不错的一个实现，作为一种节省内存成本的ssd存储来讲，已经是非常节省内存资源的存储系统元数据设计，而且对于正确性有保障。[0200]图10为本说明书一个或多个实施例提供的一种分布式数据库的负载均衡装置的结构示意图，所述装置包括：分片副本处理单元1002、分片副本统计单元1004、负载率确定单元1006与负载均衡单元1008。[0201]分片副本处理单元1002，将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点；[0202]分片副本统计单元1004，遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量；[0203]负载率确定单元1006，根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率；[0204]负载均衡单元1008，根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。[0205]图11为本说明书一个或多个实施例提供的一种分布式数据库的负载均衡设备的结构示意图，包括：[0206]至少一个处理器；以及，[0207]与所述至少一个处理器通信连接的存储器；其中，[0208]所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：[0209]将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点；[0210]遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量；[0211]根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率；[0212]根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。[0213]本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：[0214]将所述分布式数据库的缺失分片副本进行恢复，并将所述分布式数据库的多余分片副本进行丢弃，得到所述分布式数据库中符合要求的节点；[0215]遍历各符合要求的节点，确定所述各符合要求的节点中的分片副本数量；[0216]根据所述各符合要求的节点中的分片副本数量，确定所述各符合要求的节点的负载率；[0217]根据所述各符合要求的节点的负载率，调整所述各符合要求的节点中的分片副本数量，以完成所述分布式数据库的负载均衡。[0218]本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。[0219]上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。[0220]以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。当前第1页12当前第1页12