作为"DBA面试君"，在聊 OceanBase (OB) 的时候，"多租户（Multi-tenancy）" 是你必须拿捏住的核心卖点。在传统数据库（如 MySQL/Oracle）中，多租户通常是通过多个实例或逻辑 Schema 实现的，资源隔离很差。而 OceanBase 在内核层面实现了一套类似"云操作系统"的资源管理机制。
Part 1
OceanBase 多租户架构：数据库里的"虚拟机"
OceanBase 的多租户架构可以类比为"集装箱"或"Docker 容器"。在一个 OB 集群中，资源被划分为多个独立的物理池。
01 资源单元 (Unit)
Unit 是资源分配的最小颗粒。它规定了 CPU、内存、磁盘 IO 和连接数 的具体规格。
- 物理隔离： 每一个 Unit 在 OBServer 进程内都有独立的 Cgroup（用于 CPU 隔离）和独立的内存块。
02 资源池 (Resource Pool)
一组 Unit 的集合。一个资源池只能属于一个租户。
03 租户 (Tenant)
租户是业务使用的最高单位。
-
逻辑独立： 每个租户拥有独立的系统表、Schema 和用户权限。
-
完全对等： 租户之间像虚拟机一样互不感知，租户 A 的慢 SQL 不会直接导致租户 B 的内存溢出（OOM）。
Part 2
多租户架构的核心优势
在面试中，你要从"降本"和"增效"两个维度来回答：
01 极致的资源利用率 (Consolidation)
-
长尾业务整合： 过去你可能有 100 个小业务，需要开 100 个 MySQL 实例，资源浪费极其严重。现在只需一个 OB 集群，为每个业务开一个极小规格的租户，显著降低服务器成本。
-
超卖与错峰： OB 支持 CPU 的超卖（Over-subscription），能像云主机一样利用不同业务的峰谷差异，压榨硬件性能。
02 严格的资源隔离
- 抗干扰： 某个租户出现"大查询"或"全表扫描"时，资源被严格限制在其 Unit 内，不会抢占同一台物理机上其他租户的 CPU 和内存资源。
03 极速弹性伸缩 (Scale-out/in)
-
动态扩容： 如果租户 A 业务量暴增，你可以直接通过一条 SQL 修改其 Unit 规格（如从 4核 16G 改为 16核 64G），秒级生效，业务无感知。
-
跨节点迁移： OB 可以自动将某个租户的 Unit 从一台压力大的 OBServer 迁移到另一台空闲的 OBServer，整个过程数据不断流。
04 管理成本降低
- 一套集群，万种业务： DBA 只需要维护一套集群的备份、升级和监控，而不需要管理成百上千个散乱的单机实例。
Part 03
DBA面试君的"进阶话术"
面试官提问： "OceanBase 的多租户和 Oracle 的 PDB（可插拔数据库）有什么区别？"
专业回答：
"Oracle PDB 虽然实现了逻辑隔离，但在底层 IO 和 CPU 调度上的硬隔离做得不够彻底，并且还是单机的架构。OceanBase 是原生分布式设计基于Sharding Nothing的架构，它的多租户是基于自研的资源调度器和 LSM-Tree 存储引擎，不仅能隔离CPU、内存，还能实现不同租户在Clog的物理配额管理以及IOPS的隔离，是真正的'租户即实例'。"
Part 04
说这么多理论，我们来点租户创建相关的实操加印印象
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 上租户的资源分配情况。
- 使用系统视图 GV$OB_SERVERS，再次查看 observer 可供分配的 CPU、内余额是多少。
11查看不同租户的 clog、data 盘以及 cgroup 的隔离情况。
1）在/data/1 目录下查看不同租户间 sstable 数据文件的隔离情况。
2） 在/data/log1 目录下查看各个租户间 clog 日志的隔离情况。
3）在/sys/fs/cgroup/cpu/oceanbase 目录下查看各个租户间 clog 日志的隔离情况。
