HBase多租户资源隔离实战：RSGroup、RPC队列与Quota-育师

去年年底值班时遇到过一次典型的“事故”：集群整体读写RT突然从20ms附近涨到2秒多，首先是一张业务大表开始超时告警，紧接着连累同一台RegionServer上的几个小表也一起抖动，客户端连接池被打满，下游服务开始批量重试。最后定位到的问题其实不复杂——同集群里另一个团队跑大数据的bulkload，加上一张全表的scan，把IO和RPC队列全部打满了。

这种“一颗老鼠屎坏一锅汤”的场景，在大数据集群里太常见了。做HBase的人早晚都要面对同一个问题：如果多个业务共用一套HBase集群，怎么保证一个业务的高负载不影响其他业务？这就是HBase资源隔离要解决的核心问题。这篇文章我把生产上真正用过的隔离方案从头梳理一遍，包括RSGroup物理机组隔离、RPC队列分流、Quota限流、cgroup和容器化，以及我在实际踩坑过程中总结出来的注意事项。如果你正在运维HBase集群，或者打算把一套集群同时交付给多个业务团队，这篇应该能帮你少走不少弯路。

1. 资源隔离要解决的核心问题

1.1 “吵闹邻居”现象与业务风险

HBase集群中所有请求最终都落在RegionServer这个Java进程上。RegionServer内部共享一堆线程资源，读请求、写请求、compaction、scan都会抢同一批handler线程、同一块堆内存、同一个磁盘IO通道。

在一个多业务共享的集群里，这种行为特征最像合租房里的“吵闹邻居”。你正常租房过日子，隔壁突然深夜开派对，你的睡眠就被毁了。在HBase里，某个业务突然来一波全表scan、某个定时任务晚上做大批量写入、或者某张表触发了major compaction，都会让整台RegionServer的资源水位迅速抬升，其他业务的请求被挤在后面排队，延迟迅速恶化。

这种场景在工作里几乎每周都遇到：要么是大促前数据团队跑报表，把在线业务拖垮；要么是某个新接入的业务写量估算失误，直接把RegionServer的写入队列占满，导致所有在线读写一起饿死。HBase集群一抖动，上游接口、下游任务、业务方数据看板全部跟着遭殃，排障和善后的成本非常高。

资源隔离要解决的，就是让这些“邻居”之间尽可能互不干扰，或者至少让你的关键业务在别人闹腾时能扛住。

1.2 隔离的对象：CPU、内存、IO、请求量

很多人一说到资源隔离就只想到“限流”，其实这不够。要对症下药，先要看准我们要隔离的到底是什么。HBase里常见的资源竞争对象有四类：

CPU：in-memory scan、compaction的编码解码、WAL日志写盘、GC线程都在抢CPU。CPU一旦被打满，直接影响所有请求的处理速度。
内存：RegionServer的JVM堆内存被block cache、memstore、各种请求缓存瓜分。内存不够时触发频繁GC，整个RegionServer都会卡顿。
IO：磁盘IO是最大短板，bulkload、大scan、compaction都会把IO吞吐打满。IO过载时，正常的WAL写入和HDFS读写也会跟着变慢。
请求量：每秒进来的RPC数量和请求堆积量。请求量溢出会让handler线程队列排满，大量请求超时重试。

其中CPU、IO、内存属于“物理资源”，请求量属于“逻辑资源”。物理资源的隔离往往需要靠进程级、节点级手段；逻辑资源的隔离则可以通过RPC队列、优先级、限流等软件方案实现。搞混这两者的区别，很容易选错方案——以为配个Quota就是搞定了CPU和IO，实际上Quota只是挡住了一部分超量请求，物理资源被打满时它一样无能为力。

2. 方案总览：三层隔离思路与选型判断

2.1 集群层、节点层、请求层三张“闸门”

HBase资源隔离方案按粒度可以分成三层，每一层解决不同维度的问题：

集群层隔离：一个业务、一套独立HBase集群，底层存储可以共享或独立。隔离最彻底，但机器成本、运维成本最高。
节点层隔离：在同一个集群内部，用RSGroup把RegionServer物理分成多个组，把不同业务或namespace绑定到不同组。隔离效果接近机器级，成本和灵活性居中。
请求层隔离：在RegionServer内部通过RPC线程池队列拆分、请求优先级、Quota限流等方式，对具体请求做逻辑上的隔离和限制。成本最低，实施最快，但属于软隔离。

三层方案不是互斥的，生产上更常见的做法是组合使用：底层用RSGroup把关键业务和高负载业务分开，中间用RPC队列把读写分流，最上层用Quota限制非核心业务的请求量。我比较习惯把它们形容成三道水闸：第一道闸分水路，第二道闸分车道，第三道闸管水流量。

2.2 先回答四个问题再选型

不是所有业务都需要上全套隔离方案。我在给团队做方案评审时，一般会先逼着业务方回答四个问题，答案决定了选型：

这个业务可接受的延迟抖动是多少？SLA严格到500ms以内，还是能接受几秒延迟波动？
业务流量特征是什么？是读多写少、写多读少，还是经常有批量大查询？
有没有预算和机器冗余做物理隔离？让关键业务独占机组甚至独占集群的成本能否接受？
运维团队有多少人力维护多个集群、多套监控、多个数据链路？

一般回答下来：SLA严格、预算够的业务直接上独立集群或多组RSGroup物理隔离；大多数混部业务采用RSGroup+Quota的组合；临时性、试验性的业务用Quota限流就够了。

从成本、隔离强度和运维复杂度来看，大致可以这样权衡：

方案	隔离强度	实施成本	运维复杂度	适用场景
独立集群	最高	很高	高	核心交易、强SLA业务
RSGroup分组	高	中	中	多个业务共享一套集群
RPC队列拆分	中	低	低	读写混部、防scan扫库
Quota限流	中偏弱	低	低	限制非核心业务、租户
cgroup/容器	高	中高	较高	物理机资源精确控制

3. 第一层：用RSGroup做物理上的机组隔离

3.1 RSGroup的原理和版本限制

RSGroup（RegionServer Group）是HBase内部提供的一套RegionServer分组成员管理机制。核心思路很简单：把集群里的RegionServer节点划分成若干个逻辑组，每个组可以绑定一批namespace或表，Master在分配Region时会把Region尽量调度到所属组内的RegionServer上，同时组内单独跑负载均衡。

使用RSGroup后，某张表的所有Region都只会落在它所属组的机器上。这样组与组之间天然隔离了物理资源，A组业务就算把机器IO打满，B组业务在自己的机器上照样正常服务。它比独立集群成本低，但隔离效果已经接近物理隔离的级别。

需要注意版本限制。HBase 1.1.0开始引入RSGroup，2.x之后功能逐步完善。如果你用的是特别老的版本，建议先评估升级。另外，老版本里通过ZooKeeper节点存储RSGroup信息，新版本改为放在Master的元数据里管理，版本不同操作细节也有差异，不要盲目照搬网上老文章的命令。

3.2 实操：把一个namespace隔离到独立机组

生产里我最推荐的做法是先用namespace划分业务，再把namespace绑定到RSGroup，这样新表只要创建在对应namespace里，就自动归入对应机组，不需要一张表一张表去指定。

假设现在有一个核心支付业务，希望把它的namespace独立到一组专属机器上，可以按下面流程操作：

# 1. 在HBase Shell中创建namespace和rsgroup create_namespace 'pay_ns' add_rsgroup 'group_pay' # 2. 查看当前集群的RS列表，确定要移动哪些节点 list_servers # 3. 把目标RegionServer移动到group_pay组 move_servers_rsgroup 'group_pay', 'rs01.example.com,rs02.example.com,rs03.example.com' # 4. 把namespace绑定到group_pay组 move_namespaces_rsgroup 'group_pay', 'pay_ns' # 5. 手动触发一次组内均衡，让已有表快速迁移到位 balance_rsgroup 'group_pay' # 6. 确认绑定结果 get_rsgroup 'group_pay'

执行完成后，pay_ns下面所有既有表和新建表，都只会落在group_pay那几台机器上。如果有一些老的业务表不在namespace里，想单独移动到某个组，可以用move_tables_rsgroup：

move_tables_rsgroup 'group_pay', 'order_table,user_table'

3.3 RSGroup容易踩的坑

RSGroup看着简单，用起来有几个坑特别值得注意。

第一个是组内机器数量不能太少，否则Region没法全部分配。HBase一张表默认有三个副本（如果开启replication），如果组内RegionServer数量小于副本数，Master就无法完成分配，Region会一直处于过渡状态，表现为RIT（Region In Transition）数量增多、表不可用。我在测试环境踩过，RSGroup组里只有两台机器，副本数是3，结果表怎么都起不来，后来把副本数调成2或者加机器才恢复正常。

第二个是组间不能互借资源。RSGroup是强隔离，一旦某个组里的RegionServer宕机，组内的Region不能自动漂移到其他组的机器上，只能等其他机器恢复。如果组内没有足够的冗余，故障的代价比混部更大。所以给核心业务做RSGroup分组时，组内至少要预留一台故障转移的余量。

第三个是负载均衡冲突。集群默认的Balancer是按全局机器负载来调的，启用RSGroup后，如果不加配置，默认Balancer可能和RSGroup的调度逻辑打架，导致Region在组内外漂移。HBase 2.x里RSGroup自带的balancer会根据组内情况做均衡，但需要确认对应的balancer实现已经配置好，同时排查确认没有其他自定义的balancer和多组策略同时生效。

4. 第二层：用RPC队列和线程池做“车流分流”

4.1 HBase RPC请求是怎么进队列的

RSGroup解决的是“机器各自分开”的问题，但同一组机器内部，不同请求还是会互相挤占。这时候就要看RegionServer内部的请求处理路径。

客户端发往RegionServer的每一个RPC请求，先进入一个CallQueue队列，由固定数量的handler线程从队列里取出请求执行。在默认配置下，所有请求混在同一个队列里，读请求、写请求、scan请求、compaction管理请求全都排在一起。

这带来一个很直接的问题：某个业务发起大scan，一条scan请求会长时间占用handler执行扫描逻辑，队列积压之后，在线写请求也要排队。用户感受就是“没人告诉我刚才跑大查询，我的RT怎么突然就崩溃了”。要分流，就得从队列这一层入手。

4.2 读写分离参数实操

HBase从0.98版本开始就在RPC层提供了队列拆分能力。常用的核心参数有三个：

hbase.regionserver.handler.count：RegionServer处理RPC的handler线程总数，默认30。并发请求量大的集群可以适量调大，但不建议无脑调高，线程过多反而增加上下文切换开销。
hbase.ipc.server.callqueue.handler.factor：CallQueue数量与handler数量的比例系数。比如设置为0.5，handler是30，就会创建15个独立的CallQueue。
hbase.ipc.server.callqueue.read.ratio：读写队列的分配比例。设为0.3表示30%的队列专门给读请求，写入请求使用剩下的70%队列。
hbase.ipc.server.callqueue.scan.ratio：在分配给读请求的队列中，再专门划分出多大比例给scan请求。设为0.5表示read队列里有一半专门给scan。

实操中，我一般把read.ratio调到0.4到0.5，scan.ratio调到0.5到0.6。这么做的目的，说白了就是给大scan单独开一条慢车道，让它别去挤正常的读写快车道：

<property> <name>hbase.ipc.server.callqueue.handler.factor</name> <value>0.5</value> </property> <property> <name>hbase.ipc.server.callqueue.read.ratio</name> <value>0.4</value> </property> <property> <name>hbase.ipc.server.callqueue.scan.ratio</name> <value>0.5</value> </property>

需要注意，这是全局生效的参数，调完之后所有RegionServer都会按这个比例分配队列。如果你们集群写请求本身非常高，read.ratio调得太大反而会让写队列变少，写并发降下来。生产上调整要结合监控里的读写延迟和队列积压情况，观察一两天再微调。

4.3 自定义PriorityFunction扩展

队列拆分是“给不同类型的请求分车道”，但同一个车道里，核心业务和普通业务的请求依旧平等排队。如果希望核心业务的关键请求优先处理，可以利用HBase RPC层提供的PriorityFunction机制。

HBase在处理RPC时会根据请求上下文返回一个优先级，高优先级的请求会进入单独的高优先级队列，优先被handler执行。默认实现下，大部分请求是普通优先级，只有部分系统内部请求才是高优先级。

自定义PriorityFunction需要你实现一个类，重写获取优先级的方法，在里面根据调用者用户名、表名来判断请求重要性。比如识别到来自核心交易用户、或者访问订单表这类关键表的请求就返回高优先级：

public class BizPriorityFunction extends SimplePriorityFunction { @Override public int getPriority(Configuration conf, String userName, HBaseRPCProtos.RequestHeader requestHeader) { if ("pay_service_user".equals(userName)) { return HConstants.HIGH_QOS; } return super.getPriority(conf, userName, requestHeader); } }

然后在每个RegionServer的hbase-site.xml里配置：

<property> <name>hbase.ipc.server.priority.function</name> <value>com.example.BizPriorityFunction</value> </property>

这个方案的效果很直接：即使别人在跑全表scan，核心业务的读写请求依然能进高优队列尽快执行。代价是需要写代码、重新编译并部署到所有RegionServer，并且要处理类加载问题。我建议把这类扩展放在公共依赖包里统一管理，避免每台机器单独放jar导致类冲突。

5. 第三层：用Quota限流做请求量的“硬约束”

5.1 Quota能限制什么

RPC队列是让请求“排队不打架”，限流则是直接从入口掐掉超量的部分。HBase内置的Quota就是用来做这件事的。

HBase Quota支持按表、按namespace、按用户三个维度设置限制，可以限制的指标包括：

REQUEST_PER_SECOND：每秒总请求次数
READ_REQUESTS_PER_SECOND：每秒读请求次数
WRITE_REQUESTS_PER_SECOND：每秒写请求次数
REQUEST_SIZE：请求总容量
READ_SIZE/WRITE_SIZE：读写请求的容量上限

它本质上是一个基于令牌桶的限流器，在Master和RegionServer的RPC入口处生效。一旦请求量超过配额，多余的请求会被直接拒绝，返回ThrottlingException。

这样的机制很适合多业务混部场景：给报表分析用户限制每秒只能提交一定量的请求，防止他们的大查询把在线业务挤垮；给某个数据导入账号限制写入速率，防止bulkload打爆磁盘IO。

5.2 实操配置示例

HBase Shell里操作Quota非常方便，常用的几个命令：

# 限制某张表每秒最多100个请求 set_table_quota 'big_report_table', {REQUEST_PER_SECOND => 100} # 限制某个namespace的读写并发 set_namespace_quota 'report_ns', { READ_REQUESTS_PER_SECOND => 300, WRITE_REQUESTS_PER_SECOND => 200 } # 限制某用户每秒总请求量 set_user_quota 'report_user', {REQUEST_PER_SECOND => 200} # 查看当前所有配额配置 list_quotas

Quota命令执行后会持久化保存，不需要重启集群。生效速度取决于Master上的刷新周期配置，一般几十秒内就能看到效果。

这里多说一句：Quota超限后的表现是请求被拒绝，客户端如果需要自动恢复，通常会配置重试。如果你的客户端重试次数设置得很大，超限请求会反复重试，反而放大压力。所以限流策略一定要和上游客户端的重试配置一起调，别一边限流一边疯狂重试。

5.3 软隔离的边界与误区

Quota是最快能用上的资源隔离手段，但它的能力边界一定要认清。

Quota限制的是“请求量”，不是“物理资源”。一个别有用心的用户就算每秒只发10个请求，每个请求都是大范围scan，扫描的数据量依然可以把磁盘IO和内存吃满。或者反过来，请求量不高但每条请求都触发大量GC，CPU照样飙高。对这类场景，不能只依赖Quota。

另外一个常见误区是把Quota当成CPU和内存的隔离手段。很多团队给所有用户都配置了严格Quota，以为万无一失，结果到了高峰期CPU还是被打满。原因是Quota只掐请求入口，compaction、balance、region split这些后台操作根本不计入请求配额，它们照样在背后消耗资源。所以要管住后台操作，必须配合调compact和split的策略。

Quota配置也要克制。配额项太多、刷新太频繁，反而可能给Master的Quota管理模块增加额外压力。我习惯只对高风险、高消耗业务配Quota，核心在线业务本身不需要限流，而是通过优先队列和隔离来保。

6. 整机资源硬隔离：cgroup与容器化

6.1 给RegionServer加CPU/内存围栏

RSGroup和RPC队列都只能管HBase上层，RegionServer进程本身能用的CPU和内存，仍然可能把整台机器掏空。尤其当同一台物理机上还部署了其他组件时，想精确控制HBase占用资源的比例，就得靠操作系统层的手段。

Linux的cgroup就是很成熟的做法。以CPU限制为例，可以用cpu子系统限制RegionServer进程在每100ms周期内最多使用多少CPU时间。假设机器是16核，你想让HBase最多用8核，可以这样设置：

# 创建cgroup目录 mkdir /sys/fs/cgroup/cpu/hbase mkdir /sys/fs/cgroup/memory/hbase # 设置CPU限制：100000us为一个周期，cfs_quota_us为50000us，即最多50%CPU echo 100000 > /sys/fs/cgroup/cpu/hbase/cpu.cfs_period_us echo 50000 > /sys/fs/cgroup/cpu/hbase/cpu.cfs_quota_us # 设置内存上限，单位是字节，比如限制为32GB echo 34359738368 > /sys/fs/cgroup/memory/hbase/memory.limit_in_bytes # 把RegionServer进程加入cgroup echo <pid> > /sys/fs/cgroup/cpu/hbase/tasks echo <pid> > /sys/fs/cgroup/memory/hbase/tasks

实际操作时建议用systemd或专门的cgroup管理工具，把配置写成服务，不要把命令裸跑在终端，否则重启后配置就丢了。

设置内存限制时要格外小心。HBase进程的内存除了JVM堆（Xmx指定的部分），还要算上堆外内存、Direct Memory、native开销、以及线程栈。如果把内存上限直接设成Xmx大小，几乎必然触发OOM。我一般会把memory.limit_in_bytes设置为Xmx的1.3倍左右，同时留出一部分给系统缓存。安全起见，设置完先在测试环境压一遍，观察内存水位是否接近上限。

6.2 容器化部署HBase的取舍

和手工cgroup相比，容器化是更现代、可维护性更好的硬隔离方式。把RegionServer跑在容器里，用容器的CPU和内存限制天然实现资源隔离，再用Kubernetes的节点亲和性把容器调度到指定物理节点，效果比手工cgroup稳定得多。

但容器化HBase不是没有代价。RegionServer是重度使用磁盘IO的组件，容器化之后需要考虑日志盘、WAL盘、HDFS数据盘的挂载方案，还要处理容器重建后RegionSever重启、数据恢复、replication切换这些状态类问题。如果你的HDFS DataNode和HBase RegionServer是混合部署在同一批物理机上的，给RegionServer加容器限制时，DataNode的资源也要一并规划，否则可能出现容器的limits把DataNode挤得没资源的情况。

我个人建议，只有条件成熟、运维体系和监控体系都支持容器化时，才考虑用容器方案。如果只是想让核心业务独占机器，完全可以用RSGroup加物理机隔离，运维成本比容器化低很多。

6.3 cgroup+RSGroup组合实践

硬隔离和软隔离组合使用，是我在生产环境里验证最稳妥的模式。典型配置如下：

核心在线业务使用独立的RSGroup，组内RS数量有冗余，保证物理资源独占。
非核心报表业务放在另一个RSGroup，并用cgroup限制整组RegionServer的CPU上限。
RPC层开启读写队列拆分，并给核心业务配置高优先级。
对非核心业务账号配置Quota，限制每秒请求数。

这样即便某个非核心业务在报表组里疯狂扫表，CPU和IO也只会在它自己的机器组里消耗，不会影响核心业务的机器组，同时还有Quota作为最后一道保险，从入口挡住超量请求。排查问题时也清晰：先看是不是核心组机器自身故障，再看非核心组的异常负载有没有突破cgroup限制。

7. 线上实战案例与问题排查

7.1 一次典型故障的排查顺序

回到开头说的那次故障。我发现RT飙高后的排查顺序可以给一个通用参考：

看监控。先看各业务维度的读写RT曲线，判断是全体故障还是某个业务受到影响。
看RegionServer的请求队列积压和handler使用率。如果写队列大量积压，说明写入通道被堵；如果scan队列积压，优先怀疑大查询。
看机器层负载。CPU、磁盘IO、内存GC情况，判断是资源打满还是进程异常。
看具体请求来源。通过RegionServer日志或审计信息，找到占用资源最多的客户端来源和表名。
堵漏。对大查询账号临时加Quota、隔离扫表任务、错峰跑批，先把问题止血。
复盘。看是不是缺了隔离配置，把对应方案补上。

那次故障排查到最后发现，是报表团队一个全表scan任务直接命中了大表，导致scan队列占满。集群当时没有拆分scan队列，所以所有读写请求全堵在一起。后来我们做的调整很快：开启scan队列独立、给报表账号加Quota、把核心业务放到独立RSGroup，之后再遇到大规模扫表，影响范围都控制在了报表组内部。

7.2 常见问题速查表

把我在实践里经常遇到的几类隔离相关问题整理成了表格，方便大家直接对照：

故障现象	可能原因	排查思路	解决方案
RT全部飙升，不分业务	RPC队列被占满，大量scan或bulkload阻塞	查handler队列积压、IO曲线	拆分读写队列，调高scan.ratio
某个表写入被拖垮	同一RS上其他表在跑compaction/大scan	查RS的compaction队列和scan活跃量	错峰/手动控compaction，加RSGroup
Quota已配但不生效	客户端重试放大流量，刷新周期长	list_quotas确认配额存在，观察日志	调客户端重试策略，调整Refresh周期
RSGroup分组无效果	表的namespace未绑定组内	检查表实际RS位置	执行move_namespaces或move_tables
组内Region大量RIT	组内RS数小于副本数	看Region状态卡在OPEN	加机器，或降低该表副本数
CPU被打满但请求量不高	大scan单请求消耗高，Quota管不住	看scan的scanNext耗时	scan队列隔离，限制单请求扫描数据量

7.3 我常用的几组“保命”配置

最后分享几组我已经在多个集群验证过、效果不错的配置，适合作为基础模板。

配置一：开启scan独立队列，防止大查询阻塞在线读写：

<property> <name>hbase.ipc.server.callqueue.handler.factor</name> <value>0.5</value> </property> <property> <name>hbase.ipc.server.callqueue.read.ratio</name> <value>0.4</value> </property> <property> <name>hbase.ipc.server.callqueue.scan.ratio</name> <value>0.6</value> </property>

配置二：核心业务和普通业务拆成不同RSGroup，并且核心组保留一台机器余量：

add_rsgroup 'group_online' add_rsgroup 'group_normal' move_servers_rsgroup 'group_online', 'rs_online_1,rs_online_2,rs_online_3' move_servers_rsgroup 'group_normal', 'rs_normal_1,rs_normal_2' move_namespaces_rsgroup 'group_online', 'online_ns' move_namespaces_rsgroup 'group_normal', 'report_ns'

配置三：对非核心业务账号限流，并把major compaction错峰关闭，改成手动低峰期执行：

set_user_quota 'report_user', {REQUEST_PER_SECOND => 200}

同时把表级自动major compaction关闭，统一在调度平台里按业务窗口执行。这是成本最低、见效最快的组合之一。

如果说这些年做HBase资源隔离有什么全局体会，我最想说的一点是：不要一开始就上最重的方案。先花一个下午把RPC队列参数调好，给明显超量的业务配好Quota，大概率能解决八成问题。剩下真正需要隔开的核心业务，再上RSGroup分组。等到验证出某个组确实还需要CPU和内存级别的隔离时，才需要引入cgroup或者容器化。隔离的粒度越高，对应的成本和维护复杂度也越高，一上来就全量铺开，往往会把简单问题搞复杂。先从请求层入手，保住核心业务的稳定性，再逐步加码，才是经历过几次线上故障之后我认为最稳妥的节奏。