---
title: "数据负载均衡最佳实践 - OceanBase 最佳实践 | OceanBase 文档中心"
description: 数据负载均衡最佳实践 在当今快速发展的大数据时代，数据库作为数据存储和管理的核心组件，面临着前所未有的挑战。随着企业业务规模的不断扩大和技术架构的日益复杂化，如何高效地管理和优化海量数据成为了一个亟待解决的问题。OceanBase 数据库作为一款由阿里巴巴自主研发的分布式关系型数据库系统，在应对这些挑战方面展现出了强…
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

# 数据负载均衡最佳实践

更新时间：2026-07-28

[编辑](https://github.com/oceanbase/best-practices-doc/edit/master/zh-CN/700.management/300.best-practice-for-data-load-balancing.md) 适用产品： OceanBase 数据库 适用场景： 运维管理  

在当今快速发展的大数据时代，数据库作为数据存储和管理的核心组件，面临着前所未有的挑战。随着企业业务规模的不断扩大和技术架构的日益复杂化，如何高效地管理和优化海量数据成为了一个亟待解决的问题。OceanBase 数据库作为一款由阿里巴巴自主研发的分布式关系型数据库系统，在应对这些挑战方面展现出了强大的能力。自其推出以来，OceanBase 数据库就以其高可用性、高性能以及良好的扩展性赢得了众多用户的青睐。

进入 V4.0 版本后，OceanBase 数据库实现了单机分布式一体化架构的支持并引入自适应日志流概念以支持多种场景下的数据负载均衡要求，从而进一步提升了整个系统的灵活性与效率。

在此基础上，为了满足不同场景下对于数据分布及访问速度的需求，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` 的值，确认租户间均衡是否为开启状态。

   ```sql
   obclient> SHOW PARAMETERS LIKE '%enable_rebalance%';

   ```
 2. 如果未开启，可以执行以下语句，开启租户间均衡。

   ```shell
   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 模式   Oracle 模式

       ```shell
       obclient> SELECT * FROM oceanbase.GV$OB_PARAMETERS WHERE NAME LIKE '%_transfer_start_trans_timeout%';

       ```

       ```shell
       obclient> SELECT * FROM SYS.GV$OB_PARAMETERS WHERE NAME LIKE '%_transfer_start_trans_timeout%';

       ```
     3. 执行以下语句，修改配置项 `_transfer_start_trans_timeout` 的值。

       MySQL 模式下的示例如下：

       ```sql
       obclient> ALTER SYSTEM SET _transfer_start_trans_timeout = '1s';

       ```

       Oracle 模式下的示例如下：

       ```shell
       obclient> 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` 的值。

       ```shell
       obclient> SELECT * FROM oceanbase.GV$OB_PARAMETERS WHERE NAME LIKE '%_enable_balance_kill_transaction%';

       ```

       ```shell
       obclient> SELECT * FROM SYS.GV$OB_PARAMETERS WHERE NAME LIKE '%_enable_balance_kill_transaction%';

       ```
     3. 执行以下语句，修改配置项 `_enable_balance_kill_transaction` 的值。

       ```sql
       obclient> ALTER SYSTEM SET _enable_balance_kill_transaction = true;

       ```

       ```shell
       obclient> 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)。

更多负载均衡相关的配置介绍，参见 [数据均衡相关的视图和配置项](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001036381)。

 上一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线