负载均衡 - OceanBase 数据库 V4.2.2

负载均衡

更新时间：2026-04-10 11:58:36

负载均衡是性能调优过程中经常关注的一个信息，包括集群内物理机负载均衡和业务流量负载均衡两个方面。较好的负载均衡状态能够充分利用软件、硬件环境，使得性能达到最优的状态。压测过程中，我们需要关注集群内部各 OBServer 的资源使用率，包括：CPU、IO、Load 等参数。本文主要从集群部署、资源分布等方面简单阐述。

集群部署

关于集群部署，需要搜集位置、延迟、带宽等信息。

位置

位置信息至关重要，部分关键信息，如： IDC 、部署方式影响 SQL 路由转发、事务模型和性能。包括如下方面：

部署方式：同城三机房、两地三中心、三地五中心或其他部署方式。
OBProxy 等中间件的位置：部署在客户端侧还是跟 Observer 混布？不同的部署方式，对性能有一定的影响。
应用服务器及其他中间件位置。

查看集群各 Zone 分别在什么机房，机房所在城市，IDC 配置的相关 SQL 语句如下：

obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_ZONES;
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
| ZONE  | CREATE_TIME                | MODIFY_TIME                | STATUS | IDC  | REGION         | TYPE      |
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
| zone1 | 2024-03-21 10:07:56.136605 | 2024-03-21 10:07:56.137663 | ACTIVE |      | default_region | ReadWrite |
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
1 row in set

延迟

可通过延迟信息评估单条 SQL 的 rt 是否符合预期。整个集群具体的延迟信息如下：

机房间延迟；
Zone 间延迟；
OBProxy 到OBServer 端延迟；
客户端到 OBProxy 端延迟。

带宽

需要确认如下组件的带宽：

OBProxy 所在机器网卡带宽。
应用服务器网卡带宽。
OBServer网卡、磁盘 IO 带宽。

这些信息的获取可以通过注入 ping 、tsar 、ethtool xxx 、ifconfig 等命令获取。接下来的描述，我们以同城三机房、三副本 FFF 部署为例。

资源分布

了解租户资源分布，为接下来的性能诊断做准备。

租户的基本信息

包括 primary , locality 等，相关 SQL 如下：

obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANTS LIMIT 1\G
*************************** 1. row ***************************
                 TENANT_ID: 1
               TENANT_NAME: sys
               TENANT_TYPE: SYS
               CREATE_TIME: 2024-03-21 10:07:56.037402
               MODIFY_TIME: 2024-03-21 10:07:56.037402
              PRIMARY_ZONE: RANDOM
                  LOCALITY: FULL{1}@zone1
         PREVIOUS_LOCALITY: NULL
        COMPATIBILITY_MODE: MYSQL
                    STATUS: NORMAL
             IN_RECYCLEBIN: NO
                    LOCKED: NO
               TENANT_ROLE: PRIMARY
         SWITCHOVER_STATUS: NORMAL
          SWITCHOVER_EPOCH: 0
                  SYNC_SCN: NULL
            REPLAYABLE_SCN: NULL
              READABLE_SCN: NULL
        RECOVERY_UNTIL_SCN: NULL
                  LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: DISABLED
                  UNIT_NUM: 1
                COMPATIBLE: 4.2.2.0
                 MAX_LS_ID: 1
1 row in set

资源分配信息

单机用户分区总数量及 Leader 分布

obclient [oceanbase]> SELECT svr_ip,count(1) FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id=1002 GROUP BY svr_ip;
+---------------+----------+
| svr_ip        | count(1) |
+---------------+----------+
| 10.10.10.1    |        1 |
| 10.10.10.2    |        1 |
| 10.10.10.3    |        1 |
+---------------+----------+
3 rows in set 

obclient [oceanbase]> SELECT svr_ip,count(1) FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id=1001 and role=1 GROUP BY svr_ip;
+---------------+----------+
| svr_ip        | count(1) |
+---------------+----------+
| 10.10.10.1    |        5 |
+---------------+----------+
1 row in set

其他

从应用服务器发出请求到 OBServer 应用服务器，中间经过的任何组件都是我们关注的重点，任何一处成为瓶颈，均能性能带来比较大的影响。需要关注：

物理资源：中间链路各组件资源是否到瓶颈，比如：JVM 内存、应用服务器和 OBProxy CPU 使用率、软中断。
请求路由：OBProxy 是否能够正确路由 SQL 请求，是否存在乱转发的情况。
连接池：长和短连接数量，SocketTimeout 配置。
流量均衡：每个 OBServer上接收处理的 SQL 数量是否出现严重不均衡问题。