负载均衡 | OceanBase 文档中心

负载均衡

更新时间：2026-03-27 14:15:30

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

集群部署

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

位置

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

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

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

MySQL [oceanbase]> select zone, name, info from __all_zone where name in ('region', 'idc') ;
+------+--------+------+
| zone | name   | info |
+------+--------+------+
| z1   | idc    |      |
| z1   | region | SZ   |
| z2   | idc    |      |
| z2   | region | SZ   |
| z3   | idc    |      |
| z3   | region | SZ   |
+------+--------+------+
6 rows in set (0.00 sec)

延迟

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

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

带宽

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

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

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

资源分布

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

租户的基本信息

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

MySQL [oceanbase]> select * from __all_tenant limit 1\G;
*************************** 1. row ***************************
                 gmt_create: 2021-08-25 20:38:18.699528
               gmt_modified: 2021-08-25 20:38:18.699528
                  tenant_id: 1
                tenant_name: sys
                  zone_list: z1;z2;z3
               primary_zone: z1;z2,z3
                     locked: 0
             collation_type: 0
                       info: system tenant
                   locality: FULL{1}@z1, FULL{1}@z2, FULL{1}@z3
          previous_locality:
      default_tablegroup_id: -1
         compatibility_mode: 0
           drop_tenant_time: -1
                     status: TENANT_STATUS_NORMAL
              in_recyclebin: 0
1 row in set

资源分配信息

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

MySQL [oceanbase]> select svr_ip,count(1) from __all_virtual_ls_meta_table where tenant_id=1002 group by svr_ip;
+---------------+----------+
| svr_ip        | count(1) |
+---------------+----------+
| xxx.xxx.xxx.1 |        1 |
| xxx.xxx.xxx.2 |        1 |
| xxx.xxx.xxx.3 |        1 |
+---------------+----------+
3 rows in set 

MySQL [oceanbase]> select svr_ip,count(1) from __all_virtual_ls_meta_table where tenant_id=1001 and role=1 group by svr_ip;
+---------------+----------+
| svr_ip        | count(1) |
+---------------+----------+
| xxx.xxx.xxx.1 |        5 |
+---------------+----------+
1 row in set

其他

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

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