蚂蚁 OceanBase负载均衡设计和实践
摘要：本文整理自蚂蚁集团DBA徐力嘉，在深入浅出OceanBase第四期的分享。
本篇内容主要分为六个部分：
1.数据库的负载均衡
2.OceanBase内置的两种负载均衡
3.OceanBase负载均衡相关参数
4.OceanBase外置负载均衡能力设计
5.从应用架构看负载均衡
6.用户问答
一、数据库的负载均衡
目前，数据库主要分为三种。即传统集中式架构数据库、分布式数据库中间件、原生分布式数据库。
其中，原生SQL引擎，支持分布式查询和事务，灵活的部署模式、高可用和负载均衡能力。
如上图所示，OB是一个多租户架构，在OceanBase数据库中，使用资源配置（unit_config）、资源池（Resource Pool）和资源单元（Unit）等三个概念，对各租户的可用资源进行管理。
OceanBase是分布式关系型数据库，采用shared-nothing架构，用户数据以分区(Partition)方式进行分片分布在多台机器上。Partition以分区为单位组织用户数据，分区在不同机器上的数据拷贝称为副本（Replica）。
同一分区的多个副本使用Paxos一致性协议保证副本的强一致，每个分区和它的副本构成一个独立的Paxos组。
二、OceanBase内置的两种负载均衡
上图是一个多租户多unit的案例，其中，集群CLUSTER有三个zone。每个zone N台OB Server，这种部署简称N-N-N。OB Server皆为30C 200G 4T的docker。
OB是多租户的数据库系统，一个集群内可包含多个相互独立的租户，每个租户提供独立数据库服务布局n-n-n。租户A总资源60C 120G，租户B总资源120C 600G，租户C总资源45C 180G。
资源单元对应CPU、内存、存储空间、IOPS这几个物理资源。任何一个资源单元一定会放置在一个资源足够容纳它的OB Server上，一个租户在同一个OB Server上最多有一个资源单元。
当OB Server服务器下线前，其上的资源单元必须迁移到其他OB Server上，如果集群内其他OB Server不足以容纳会导致下线无法成功。
资源池由具有相同资源配置Unit Config的若干个资源单元组成。一个资源池只能属于一个租户，一个租户可以拥有一或多个资源池，这些资源池的集合描述了这个租户所能使用的所物理资源。
RootService包括资源管理、负载均衡和Schema管理。其中，资源管理包括Region/Zone/OBServer/Resource Pool/Unit等元信息的管理，比如：上下线OBServer、改变Tenant资源规格等。
负载均衡决定Unit/Partition在多个机器间的分布均衡，机器上主分区个数。
在容灾场景下通过自动复制/迁移补充缺失的Replica。
Schema管理负责处理DDL请求并生成新Schema。
UNIT资源单元是多租户架构、分布式架构下的重要概念。任何一个资源单元一定会放置在一个资源足够容纳它的OB Server上，一个租户在同一个OB Server上最多有一个资源单元。
RS模块需要对资源单元进行管理，并通过把资源单元在多个OBServer间调度，对系统资源进行有效利用。RS对资源单元的管理包括：资源单元的分配和均衡。
三、OceanBase负载均衡相关参数
假设存在两个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平均调度到该均衡组。
四、OceanBase外置负载均衡能力设计
如上图所示，一共有三个可用区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。
上图是负载均衡的相关参数。
其中，alter system enable_auto_leader_switch=true，代表是否允许rs自动切主。
data_copy_concurrency;server_data_copy_out_concurrency;server_data_copy_in_concurrency控制负载均衡时Partition 迁移的速度和影响。
由于OB内部的负载均衡能力，无法顾及业务热点，OBServer超卖和混合部署。所以为了解决这个问题，出现了外置负载均衡能力，具体架构如上图所示。
五、从应用架构看负载均衡
综上所述，应用架构负载均衡具备以下优势：高效导入、高吞吐、低延迟。除此之外，一份数据支持多种访问接口，适配蚂蚁容灾架构——读写分离。
在存储混部方面，SSD OB Server和SATA盘OB Server部署在同一个Zone。
外置均衡方面，结合指标+规则，产出均衡计划。在线表移动到SSD，支持高速读写。历史表移动到SATA，实现海量数据存档。
六、用户问答
问：当CPU不均衡调度，内存均衡调动回去，会不会一直陷入死循环？
答：内存跟着unit走，内存主要用于分配。在迁unit时，OB会判断目标内存是否不足。假设把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会统一进行调度。
问：热点问题有考虑OB自动做调度吗？
答：阿里有很多产品，具备自动均衡能力。未来，会考虑OB自动调度。目前，工作人员会做一个系统，解决相关问题。
