夜雨聆风
每天分享一个 Oceanbase 趣味小知识，今天我们来聊聊让集群告别 “偏心” 的隐藏高手 —— 分区均衡。
想象一下，你是一名运维 DBA，凌晨三点的手机突然被告警震得发烫。你揉着眼睛点开监控，瞬间清醒：集群里的日志流像两条极端的车道 —— 一条堵得水泄不通，业务请求排队到超时；另一条却空空荡荡，CPU 和磁盘资源在 “摸鱼”。更糟的是，关键业务表的分区扎堆挤在少数节点，磁盘占用更是天差地别，眼看老板的夺命连环 call 就要打过来，你急得像热锅上的蚂蚁……
就在这时，一个藏在 OceanBase里的 “智能调度官” 悄悄上线，对你说：“别慌，让我来给你的集群‘调个天平’。”
第一幕：登场！什么是分区均衡？它的 “杀手锏” 是什么？
在分区均衡出现之前，OceanBase 已经有了日志流均衡的能力，但还不够 “精准”。负载均衡模块解锁了新技能：它可以把分区（也就是 Tablet）在不同的日志流之间来回 “搬家”—— 这个操作，我们叫它 Transfer。
简单说，Transfer 就是调度官的 “魔法传送门”：它能把挤在拥堵日志流里的分区，搬到空闲的日志流上，让整个租户下的资源分布从 “一边倒” 变成 “动态平衡”，这就是分区均衡的核心目标。
而控制这个调度官能不能干活的开关，就是租户级配置项 enable_transfer。默认值为 true，也就是一开局就给了它 “调度许可”，除非你手动关闭，否则它会一直默默守护你的集群均衡。
第二幕：第一步，先解决 “分区扎堆”！分区数量均衡怎么玩？
调度官的第一招，就是先让 “队伍排整齐”：分区数量均衡。它的目标很明确 —— 让租户里所有日志流上，用户表主表的分区数量尽量均匀，偏差不大于 1。
这里有两个容易踩坑的细节，给大家划个重点：
局部索引的分区是跟着主表走的，就像主表分区的 “跟班”，它们的数量不算在分区数量均衡之内；
但全局索引不一样，它是一种特殊的主表，所以它的分区数量，是要算在均衡范围内的。
就像一个班级排课，先保证每个小组的主课学生人数差不多，副课的跟班学生不用单独占名额，但全局的课代表要算进小组人数里，这样排出来的队伍才够整齐。
第三幕：第二步，再解决 “贫富不均”！磁盘负载均衡怎么落地？
光队伍排整齐还不够，要是有的分区是 “数据大胃王”，占了几十 G 的空间，有的却是 “小不点” 只有几百 M，那就算数量一样，磁盘占用还是会差很多 —— 就像两个小组人数一样，但一个组的同学都带着大行李箱，另一个却空手，队伍还是会歪。
这时候，调度官的第二招 ——磁盘负载均衡就上场了。它会在分区数量均衡的基础上，通过交换分区，让每个日志流的磁盘占用也尽量均等。
这里的关键配置，就是集群级的 server_balance_disk_tolerance_percent，它就像给磁盘均衡设了个 “警戒线”：当一个租户的所有日志流副本，磁盘使用量占比的差值超过这个阈值时，才会触发磁盘均衡。默认值为 1，也就是差值超过 1% 的时候，调度官就会出手干预。
而且它还特别贴心，怕小数据量的集群被来回折腾：当单个日志流的磁盘占用小于 50GB 时，是不会触发磁盘均衡的，避免了频繁调度反而影响业务性能的问题。
故事的结尾：原来均衡，是藏在细节里的温柔
故事讲到这里，你会发现，OceanBase 的分区均衡，从来不是简单的 “平均主义”，而是一套层层递进的智能调度逻辑：先让分区数量均匀，再让磁盘负载均等，从根上解决集群 “偏心” 的问题，让每一份资源都用在刀刃上。
它就像你集群里的 “幕后交警”，不用你熬夜盯着监控，也不用你手动调整分区，它会在后台默默干活，让业务请求跑得稳稳当当，再也不用怕凌晨的告警和老板的电话。