随着企业业务范围的持续扩展和技术架构的不断复杂化，有效管理和优化庞大的数据集已成为亟待解决的关键问题。OceanBase 数据库，作为一款国内自主研发的原生分布式数据库产品，凭借其卓越的高可用性、高性能以及出色的扩展能力，赢得了广大用户的认可。
在OceanBase 4.0版本中，该数据库实现了单机与分布式的一体化架构设计，并创新性地引入了自适应日志流的概念，以灵活支持多种数据负载均衡需求，从而进一步提升了系统的灵活性和运行效率。
为了应对不同场景下对数据分布和访问速度的不同要求，OceanBase 数据库精心设计和实现了一系列负载均衡策略。这些策略主要分为两大类：一是租户间均衡，旨在调整和优化跨多个租户的数据分配，确保资源得到合理有效的利用；二是租户内均衡，专注于优化单个租户内部的数据布局，以提升特定应用或服务的性能表现。
本文将深入探讨上述两种类型的负载均衡策略是如何被应用于实际中的，并分析它们对相关业务所带来的具体影响。同时，我们也会分享一些实用的调优建议，帮助读者更好地理解和掌握如何根据自身需求配置最合适的负载均衡方案，以达到最优的数据管理和使用效果。通过这种方式，希望能够为广大的开发者和技术人员提供有价值的参考信息，助力他们在面对复杂的数据库环境时做出更满足场景诉求的选择。
一、租户间均衡策略
（一）应用场景：创建租户
OceanBase 数据库为多租户架构，每个租户拥有自己的资源单元 Unit，包含 CPU、内存、磁盘等规格，多租户间存在着资源负载均衡。在创建租户前新建 Unit 时，系统会通过 CPU、内存、磁盘空间的使用情况计算加权值进行比较，使新建的 Unit 分配到剩余资源最多的 Server 上。
租户间还存在 Unit 的动态负载均衡，当磁盘的水位线高于集群级配置项 server_balance_critical_disk_waterlevel 所设置的值时，系统会将高水位 Server 上的 Unit 迁移到低水位 Server 上，以达到磁盘均衡的目标。当整体水位均不高时，系统会以 CPU 和内存的加权计算负载，把高负载 Server 上的 Unit 迁移到低负载 Server，以达到 CPU 和内存均衡的目标。
（二）开启或关闭租户间均衡
用户可以通过在系统租户（sys 租户）下设置配置项 enable_rebalance 的方式来开启或关闭租户间的均衡。默认为开启状态。
如果不确定是否开启租户间均衡，可通过以下方式查询并配置：
1、在 sys 租户下，执行以下语句，查询配置项 enable_rebalance 的值，确认租户间均衡是否为开启状态。
obclient> SHOW PARAMETERS LIKE '%enable_rebalance%';2、如果未开启，可以执行以下语句，开启租户间均衡。
obclient> ALTER SYSTEM SET enable_rebalance = true;（三）租户间均衡对业务的影响
租户间的均衡一般都是在集群或租户初始化阶段进行，在 V4.x 版本中，其触发的场景比较少。
二、租户内均衡策略
租户内均衡策略又包括日志流均衡和分区均衡。
（一）日志流均衡
🚩 场景一：扩缩容场景
OceanBase 数据库支持非常灵活的扩缩容能力，一个重要实现手段就是通过增加或减少租户的 Unit Number 或者增加或减少租户的 Primary Zone 第一优先级的个数来调整服务节点的数量。服务节点数量变更，会触发日志流的均衡。通过日志流分裂、日志流合并、日志流副本迁移、日志流切主、分区均衡等动作，均衡日志流的数量和 Leader 数，以满足理想的租户状态，即每个租户的 Unit 都有日志流副本，Primary Zone 第一优先级中的每个 Zone 都有且只有一个日志流 Leader。
🚩 场景二：容灾场景
OceanBase 数据库支持可靠高可用，涉及到节点的永久下线，Locality 对齐，Unit 迁移，Unit 缩容等操作时，也会触发日志流均衡。
（二）分区均衡
🚩 场景一：扩缩容场景
扩缩容场景下，当扩容或缩容操作执行成功后，系统内部会进行 LS（Log Stream，日志流）均衡，在 LS 均衡的基础上，负载均衡模块会通过 Transfer，将分区 Tablet 打散或聚合在不同的 LS 上，达到租户下的分区均衡。
🚩 场景二：表的动态变更（新建表或删除表）
随着表和分区的动态创建与删除，不同节点上的分区个数会有很大差异，这时候就需要执行分区均衡。
在创建用户表时，OceanBase 数据库会根据不同的表类型采用对应的均衡分配策略将分区打散或聚合到各个用户日志流上，以保证各个日志流上分区的相对均衡，不同的表类型及均衡策略的详细介绍，请通过下方链接或二维码，查看 租户内均衡。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001036380
OceanBase 数据库通过 “均衡组” 的组内均衡和组间均衡的方式实现了分区的数量均衡，又通过交换分区方式实现了分区磁盘均衡。在实际业务场景中，用户还有定制数据分布的需求，希望将特定的分区进行聚合或打散，就需要手动调整分区分布，手动调整分区分布的详细操作，请通过下方链接或二维码，查看 TRANSFER PARTITION。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001033453
🚩 场景三：复制表属性变更
OceanBase 数据库从 V4.2.0 版本开始支持复制表，复制表只能存在于广播日志流上。从 V4.2.3 版本（不含 V4.3.x 版本）开始又支持了复制表属性变更。用户修改复制表属性后，需要等待分区均衡执行完成后才能按照预期属性进行使用。
（三）租户内均衡对业务的影响
租户内均衡对业务会有一定的影响：
✅ 频繁扩缩容的场景下，会创建和删除若干日志流，导致系统中可能同时存在很多日志流（包含未 GC 的日志流），系统的日志盘需要足够大，否则可能会卡住扩缩容或者负载均衡流程。
✅ 扩缩容场景下，租户的 UNIT_NUM 由 1 扩大到 2，TPS 下降 50%，持续 1 分钟，将与 Transfer 任务重合；租户的 UNIT_NUM 由 2 缩小到 1，TPS 比较稳定，性能抖动在 5% 以内。
✅ 由于合并等原因会导致磁盘 IO 占用非常高，实测可达到 99%，进而导致 Transfer 执行调度非常慢。其中，由于 Transfer Block 日志流的设计，可能还会出现性能抖动的情况，并且每次抖动的时间长度与隐藏配置项 _transfer_start_trans_timeout 所设置的数值相等，对抖动敏感的用户，可以根据需要调整 Transfer 的调度周期。
隐藏配置项 _transfer_start_trans_timeout 用于控制 Transfer Start 阶段开启事务的超时时间，其默认值为 1s，取值范围为 [1ms, 600s]。查询及配置该隐藏配置项的方法如下：
1️⃣ 租户管理员（MySQL 模式默认为 root 用户，Oracle 模式默认为 SYS 用户）登录集群的 MySQL 租户或 Oracle 租户。
2️⃣ 执行以下语句，查看配置项 _transfer_start_trans_timeout 的值。
MySQL 模式：
SELECT * FROM oceanbase.GV$OB_PARAMETERS WHERE NAME LIKE '%_transfer_start_trans_timeout%';Oracle 模式：
SELECT * FROM SYS.GV$OB_PARAMETERS WHERE NAME LIKE '%_transfer_start_trans_timeout%';3️⃣ 执行以下语句，修改配置项 _transfer_start_trans_timeout 的值。
MySQL 模式下示例如下：
ALTER SYSTEM SET _transfer_start_trans_timeout = '1s';Oracle 模式下示例如下：
ALTER SYSTEM SET "_transfer_start_trans_timeout" = '1s';三、均衡过程中对活跃事务的处理策略
OceanBase 数据库在进行负载均衡 Transfer 的过程中，暂不支持活跃事务，当前对活跃事务有如下两种处理策略：
✅ Transfer 等待活跃事务完成后再执行。
该方式为默认配置。如果是在业务高峰期，Transfer 任务会长时间等待业务事务完成，耗时会比较久，具体时间长度与业务压力、分区数量以及日志流数量有关，预期对于业务是无感知的。
✅ 由 Transfer 主动 Kill 掉对应日志流上的活跃事务。
该方式需要用户手动开启配置（即 _enable_balance_kill_transaction 的值设置为 true），设置后，在业务高峰期，可以推进 Transfer 的进度，保证分区转移的顺利进行，但可能会造成业务事务因被 Kill 而失败回滚。
隐藏配置项 _enable_balance_kill_transaction 用于设置负载均衡任务是否主动 Kill 远端日志流上的活跃事务，其默认值为 False。查询及配置该隐藏配置项的方法如下：
1️⃣ 租户管理员（MySQL 模式默认为 root 用户，Oracle 模式默认为 SYS 用户）登录集群的 MySQL 租户或 Oracle 租户。
2️⃣ 执行以下语句，查看配置项 _enable_balance_kill_transaction 的值。
MySQL 模式：
SELECT * FROM oceanbase.GV$OB_PARAMETERS WHERE NAME LIKE '%_enable_balance_kill_transaction%';Oracle 模式：
SELECT * FROM SYS.GV$OB_PARAMETERS WHERE NAME LIKE '%_enable_balance_kill_transaction%';3️⃣ 执行以下语句，修改配置项 _enable_balance_kill_transaction 的值。
MySQL 模式下的示例如下：
ALTER SYSTEM SET _enable_balance_kill_transaction = true;Oracle 模式下的示例如下：
ALTER SYSTEM SET "_enable_balance_kill_transaction" = true;以上两种对活跃事务的处理策略，需要根据不同的业务需求和负载均衡的紧急程度来进行选择，请谨慎选择。、
四、推荐配置
在业务低峰期，如果用户执行过扩缩容或容灾等操作，同时又希望租户能快速达到均衡状态，建议采用以下配置：
👉 对于 V 4.2.1 ~ V4.2.3（含该版本）等版本，建议将当前用户租户的 enable_balance 和 enable_transfer 的值均设置为 true，并调小配置项 partition_balance_schedule_interval 的值。
👉 对于 V4.2.4 及之后版本（不含 V4.3.x 版本），建议将当前用户租户的 enable_balance 和 enable_transfer 的值均设置为 true，并手动触发一次分区均衡任务。手动触发分区均衡任务的详细操作，请通过下方链接或二维码，查看 手动触发分区均衡。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001033890
在业务高峰期，希望减少负载均衡对业务的影响，建议采用以下配置：
👉 如果希望所有日志流均衡和分区均衡都不进行，则将当前用户租户的 enable_balance 和 enable_transfer 的值均设置为 false。
👉 如果希望允许做负载均衡，但又希望降低负载均衡的频率，则：
🔎 对于 V 4.2.1 ~ V4.2.3（含该版本）等版本，建议将当前用户租户的 enable_balance 和 enable_transfer 的值均设置为 true，并调大配置项 partition_balance_schedule_interval 的值。
🔎 对于 V4.2.4 及之后版本（不含 V4.3.x 版本），建议将当前用户租户的 enable_balance 和 enable_transfer 的值均设置为 true，并降低定时分区均衡任务（TRIGGER_PARTITION_BALANCE）的调度频率。调整定时分区均衡任务调度频率的详细操作，请通过下方链接或二维码，查看 配置定时分区均衡任务。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001033891
🧡注意：
对于从 V4.2.3 及之前版本升级至 V4.2.4 及之后版本的用户租户，默认定时分区均衡任务为关闭状态，还需要先开启定时分区均衡任务。
👉 如果仅允许调整特定热点分区的位置，推荐将当前用户租户的 enable_balance 的值均设置为 false，同时 enable_transfer 的值设置为 true，然后手动执行 TRANSFER PARTITION。手动执行 TRANSFER PARTITION 的详细操作，请通过下方链接或二维码，查看 TRANSFER PARTITION。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001033453
以上就是 OceanBase 数据负载均衡技术的详细解读，希望能为开发者和技术专家提供参考，帮助他们在处理复杂的数据库问题时做出更合理的决策。更多负载均衡相关的配置介绍，请点击阅读原文，查看 数据均衡相关的视图和配置项。
