17认证网OceanBase 的多租户架构可以类比为“集装箱”或“Docker 容器”。在一个 OB 集群中，资源被划分为多个独立的物理池。
Unit 是资源分配的最小颗粒。它规定了 CPU、内存、磁盘 IO 和连接数 的具体规格。
- 物理隔离： 每一个 Unit 在 OBServer 进程内都有独立的 Cgroup（用于 CPU 隔离）和独立的内存块。
一组 Unit 的集合。一个资源池只能属于一个租户。
租户是业务使用的最高单位。
- 逻辑独立： 每个租户拥有独立的系统表、Schema 和用户权限。
- 完全对等： 租户之间像虚拟机一样互不感知，租户 A 的慢 SQL 不会直接导致租户 B 的内存溢出（OOM）。
在面试中，你要从“降本”和“增效”两个维度来回答：
- 长尾业务整合： 过去你可能有 100 个小业务，需要开 100 个 MySQL 实例，资源浪费极其严重。现在只需一个 OB 集群，为每个业务开一个极小规格的租户，显著降低服务器成本。
- 超卖与错峰： OB 支持 CPU 的超卖（Over-subscription），能像云主机一样利用不同业务的峰谷差异，压榨硬件性能。
- 抗干扰： 某个租户出现“大查询”或“全表扫描”时，资源被严格限制在其 Unit 内，不会抢占同一台物理机上其他租户的 CPU 和内存资源。
- 动态扩容： 如果租户 A 业务量暴增，你可以直接通过一条 SQL 修改其 Unit 规格（如从 4核 16G 改为 16核 64G），秒级生效，业务无感知。
- 跨节点迁移： OB 可以自动将某个租户的 Unit 从一台压力大的 OBServer 迁移到另一台空闲的 OBServer，整个过程数据不断流。
- 一套集群，万种业务： DBA 只需要维护一套集群的备份、升级和监控，而不需要管理成百上千个散乱的单机实例。
“Oracle PDB 虽然实现了逻辑隔离，但在底层 IO 和 CPU 调度上的硬隔离做得不够彻底，并且还是单机的架构。OceanBase 是原生分布式设计基于Sharding Nothing的架构，它的多租户是基于自研的资源调度器和 LSM-Tree 存储引擎，不仅能隔离CPU、内存，还能实现不同租户在Clog的物理配额管理以及IOPS的隔离，是真正的‘租户即实例’。”
1 .在 OCP 服务器上，使用 obclient 客户端工具连接 OceanBase 集群。
2 .创建资源配置 u1 和 u2 如下所示。
3 .使用资源配置 u1 创建资源池 rp1，报 4733 错误：CPU resource not enough。
4 .使用资源配置 u2 创建资源池 rp1，报 4733 错误：MEMORY resource not enough。
5.使用系统视图 GV$OB_SERVERS，查看 observer 可供分配的 CPU、内余额是多少。
6 .鉴于 observer 可分配 CPU、内存小于资源配置 u1、u2 的需要，使用更小的资源配置 u3 来创建资源池。
7.使用资源池 rp1 创建租户 tenant1。
8 .创建租户 tenant2。
9 .查看集群内各个 observer 上租户的资源分配情况。
10. 使用系统视图 GV$OB_SERVERS，再次查看 observer 可供分配的 CPU、内余额是多少。
11查看不同租户的 clog、data 盘以及 cgroup 的隔离情况。
1）在/data/1 目录下查看不同租户间 sstable 数据文件的隔离情况。
2） 在/data/log1 目录下查看各个租户间 clog 日志的隔离情况。
3）在/sys/fs/cgroup/cpu/oceanbase 目录下查看各个租户间 clog 日志的隔离情况。
根据以上实验过程，请判断 OceanBase 为租户实际分配资源是在哪个步骤？是在创建资源配 置时，还是在创建资源池时，抑或是在创建租户时？
想了解更多干货，可通过下方扫码关注
可扫码添加上智启元官方客服微信👇
