作者： 蚂蚁集团 DBA 专家，NoSQL 技术负责人力虾
在管理 HBase OBKV 的实践中，我们认识到分布式数据库系统的负载均衡能力非常重要，这关系到服务稳定与业务体感。基于此，我们将从以下五个部分讲解 OceanBase 负载均衡设计和实践 ：
-
数据库的负载均衡
-
OceanBase内置的两种负载均衡
-
OceanBase负载均衡相关参数
-
OceanBase外置负载均衡能力设计
-
从应用架构看负载均衡
在讲负载均衡之前，先来看看数据库的架构演进，起初集中式架构：主备部署，主要问题是主备可能出现数据不一致性，纵向扩展为主，负载比较集中；
为了解决扩展能力有限的问题，引入中间层进行分库：可扩展性提高、成本降低，每个分库承担一部分负载，但是中间件复杂，调整分库麻烦。
现在，我们采用了 OceanBase 这种原生分布式数据库，具备自身可扩展性、同时高可用性、数据强一致，支持分布式查询和事务，灵活的部署模式、高可用和负载均衡能力。
接下来让我们了解下 OceanBase 的分布式对象有哪些？
如上图所示，OceanBase 是一个多租户架构，在OceanBase数据库中，使用资源配置（unit_config）、资源池（Resource Pool）和资源单元（Unit）等三个概念，对各租户的可用资源进行管理。
OceanBase 采用 shared-nothing架构，用户数据以分区(Partition)方式进行分片分布在多台机器上。Partition以分区为单位组织用户数据，分区在不同机器上的数据拷贝称为副本（Replica）。
同一分区的多个副本使用 Paxos 一致性协议保证副本的强一致，每个分区和它的副本构成一个独立的 Paxos 组。
上图是一个多租户多 unit 的案例，其中，集群 CLUSTER 有三个 zone。每个 zone 有 N 台 OBServer，这种部署简称N-N-N。 OBServer皆为30C 200G 4T的 docker。OceanBase 是多租户的数据库系统，一个集群内可包含多个相互独立的租户，每个租户提供独立数据库服务布局n-n-n。租户A总资源 60C 120G，租户B总资源120C 600G，租户C总资源45C 180G。
资源单元对应CPU、内存、存储空间、IOPS 这几个物理资源。任何一个资源单元一定会放置在一个资源足够容纳它的 OBServer 上，一个租户在同一个 OBServer 上最多有一个资源单元。
当 OBServer 服务器下线前，其上的资源单元必须迁移到其他 OBServer 上，如果集群内其他 OBServer 不足以容纳会导致下线无法成功。
资源池由具有相同资源配置 Unit Config 的若干个资源单元组成。一个资源池只能属于一个租户，一个租户可以拥有一或多个资源池，这些资源池的集合描述了这个租户所能使用的所物理资源。RootService 包括资源管理、负载均衡和 Schema 管理。其中，资源管理包括 Region/Zone/OBServer/Resource Pool/Unit 等元信息的管理，比如：上下线 OBServer、改变 Tenant 资源规格等。
一、数据库的负载均衡
通过上面的架构理解，我们可以看到，资源单元在 OBServer 的分布，分区在资源单元间的分布，就是分布式数据库负载均衡的本质，分别对应 unit 均衡 和 parition 均衡。
那么，负责均衡是哪个模块呢，可能很多同学都有了解过，没错就是 RootService，主要提供资源管理、负载均衡、schema 管理等功能。
二、OceanBase 内置的两种负载均衡
UNIT 资源单元是多租户架构、分布式架构下的重要概念。任何一个资源单元一定会放置在一个资源足够容纳它的OBServer 上，一个租户在同一个 OBServer 上最多有一个资源单元。RS 模块需要对资源单元进行管理，并通过把资源单元在多个 OBServer 间调度，对系统资源进行有效利用。RS 对资源单元的管理包括：资源单元的分配和均衡。
假设存在两个 OBServer：OBS0（10个CPU）和 OBS1（10个CPU）。其中，OBS0 上包含 6 个 Unit，OBS1 上包含 4 个 Unit，每个 Unit 的资源规格都为 1个 CPU。在OBServer 间迁移 Unit，使得各 OBServer 的 CPU 占用率尽可能接近。与迁移 Unit 前相比，两个 OBServer 的资源占用率更平均。
多种资源均衡算法，即为参与分配和均衡的每种资源分配一个权重，作为计算 OBServer 总的资源占用率时该资源所占的百分比，某种资源使用的越多，则该资源的权重就越高。
enable_rebalance为负载均衡的总开关，用于控制 UNIT 均衡和 PARTITION 均衡的开关。当 enable_rebalance的值为False时，UNIT均衡和PARTITION均衡均关闭。当enable_rebalance的值为True时，UNIT均衡需参考配置项resource_soft_limit的配置。resource_soft_limit为UNIT均衡resource_soft_limit的开关。当enable_rebalance的值为True且resource_soft_limit的值小于100时，资源单元均衡开启。
当enable_rebalance的值为True且resource_soft_limit的值大于等于100时，资源单元均衡关闭。当所有节点的资源水位低于resource_soft_limit时，不执行负载均衡，缺省为50。server_balance_cpu_mem_tolerance_percent为触发资源单元均衡的阈值。当某些OBServer的资源单元负载与平均负载的差值超过。
server_balance_cpu_mem_tolerance_percent设置的值时，开始调度均衡，直到所有OBServer的资源单元的负载与平均负载的差值都小于配置项server_balance_cpu_mem_tolerance_percent的值。
Partition 是分区副本的自动负载均衡，在租户拥有的 Unit 内调整分区副本的分布使得 Unit 的负载差值尽量小。Partition 均衡是发生在单个 Zone 内的租户级别的行为。均衡组是 Partition 的集合，Zone 内的全部 Partition 划分成若干个组，以组为均衡调度的基本单位，各个均衡组之间相互独立。
均衡组主要分为三类。第一类均衡组，包含多个分区的一个 Table Group下的所有 Partition 被认定为一个均衡组。
第二类均衡组，不属于任何 Table Group 的某个多分区表下的全部 Partition 被认定为一个均衡组。
第三类均衡组，除上述 Partition 以外的全部其他 Partition 被认定为一个均衡组。针对一个租户，此类均衡组在某个 Zone 内仅有一个。
在 Partition 个数满足要求的前提下，通过在 Unit 间交换 Partition 使各 Unit 磁盘使用量的差值小于配置项balancer_tolerance_percentage 设置的值。
Table Group 是一个逻辑概念，是表的集合。属于某个Table Group 集合的所有 Table 均需要满足三点约束。
第一，必须有相同的 Locality（包括副本类型、个数及位置）；
第二，必须相同的 Primary Zone（包括 Leader 位置及其优先级）；
第三，必须相同的分区方式、相同的分区数量。
如上图所示，处于同一个Partition Group的多个分区有较大概率在同一个事务中被修改。为使同一个事务的修改尽量发生在同一个OBServer上，减少分布式事务发生的概率，RootService会将属于同一个Partition Group的分区尽量调度到同一个OBServer上去。
上图是不同事务类型的持久化日志与事务提交。多机分布式事务有2台及以上server，分为两阶段提交多条日志，采用参与者即协调者的优化和协调者无状态设计。单机多分区事务有1台 Server，一阶段可以提交多条日志，但仍走分布式事务的流程，二阶段提交优化为一阶段提交。PG 事务有1台 Server，支持单 PG 提交一条日志，事务提交由原来的一阶段提交优化成单 PG 提交。
在分区副本均衡的基础之上，OceanBase 数据库还实现了 Leader 维度的均衡。用户可通过租户级的配置使租户下分区 Leader 分布在指定的 Zone 上。与此同时，Leader 均衡仍然以均衡组为基本均衡单元，旨在将一个均衡组的所有分区的 Leader 平均调度到该均衡组。
如上图所示，一共有三个可用区Zone1、Zone2、Zone3。每个可用区部署2台OBServer，其中一个包括12个Partition的均衡组。
PrimaryZone：Zone1，全部12个Partition的Leader都分布在Zone1上，Zone1的每个OBServer上各有6个Leader。
PrimaryZone：Zone1，Zone2，全部12个Partition的Leader平均分布到Zone1和Zone2上，每个OBServer上各有3个 Leader。
从图中可知，全部 12 个 Partition 的 Leader 平均分布到 Zone1、Zone2 和 Zone3 上，每个 OBServer 上各有 2个 Leader。
三、OceanBase 负载均衡相关参数
其中，alter system enable_auto_leader_switch=true，代表是否允许rs自动切主。
data_copy_concurrency;server_data_copy_out_concurrency;server_data_copy_in_concurrency控制负载均衡时 Partition 迁移的速度和影响。
**
四、OceanBase 外置负载均衡能力设计**
由于 OceanBase 内部的负载均衡能力，无法顾及业务热点，OBServer 超卖和混合部署。所以为了解决这个问题，出现了外置负载均衡能力，具体架构如上图所示。
通过单机、整体监控指标来判断流量不均衡的情况，进行干预，对热点 Partition 进行隔离等。
五、从应用架构看负载均衡
综上所述，应用架构负载均衡具备以下优势：高效导入、高吞吐、低延迟。除此之外，一份数据支持多种访问接口，适配蚂蚁容灾架构——读写分离。
在存储混部方面，SSD OBServer 和 SATA 盘 OBServer 部署在同一个Zone。
外置均衡方面，结合指标+规则，产出均衡计划。在线表移动到SSD，支持高速读写。历史表移动到SATA，实现海量数据存档。
附录、用户问答
问：当CPU不均衡调度，内存均衡调动回去，会不会一直陷入死循环？
答：内存跟着unit走，内存主要用于分配。在迁unit时，OceanBase会判断目标内存是否不足。假设把ZONE_2的黄色资源单元，迁到ZONE_2的第三台机器，这其实是不可行的。当这三个资源单元加起来，CPU会超过目标端。迁移时会考虑目标端的CPU配置、内存配置以及存储的空间配置。
问：热点调度需要要外部干预吗？
答：是的。目前，调度主要实现Partition的数字、数量的相对均衡。暂时无法考虑到每个partition的实际请求。
问：Root Service是通过选举产生的吗？
答：是的。Root Service具备高可用的能力。如果Leader副本所在的机器挂了，它会漂移到另外的机器上面去的。
问：Table group和Partition group有什么区别？
答：Table group是一个集合定义，在建某个表时，需要指定Table group，才能知道哪几张表属于一个Table group。Partition group会出现很多分区，Partition group会统一进行调度。
问：热点问题有考虑OceanBase自动做调度吗？
答：阿里有很多产品，具备自动均衡能力。未来，会考虑OceanBase自动调度。目前，工作人员会做一个系统，解决相关问题。
最后的最后，您有任何疑问都可以通过以下方式联系到我们～
联系我们
欢迎广大 OceanBase 爱好者、用户和客户随时与我们联系、反馈，方式如下：
钉钉群：33254054
