0. 先给你一张全貌图（看不懂先跳过，后面会逐个拆）

3 秒理解：

• • OBProxy 是门卫，负责把 SQL 送到对的机器
• • Cluster 是整个集群（你的整个数据库系统）
• • Zone 通常是机房（容灾单元）
• • Observer 是一个进程，每台机器跑一个，干计算+存储+事务
• • Tenant 是租户（一个”逻辑上的数据库实例”）
• • Partition 是数据分片的最小单位（一张大表被切很多片）
• • Replica 是副本（同一份数据存 3 份，防机器故障）

0.5 如果你熟悉 Kafka（强烈推荐用这个锚点学）

你刚才看全貌图可能觉得”这不就是 Kafka 集群换了个名字吗？”
你说对了。分布式系统在「分片 + 复制 + 容灾」这三件事上用的是同一套思想。

高度相似的概念（你可以直接迁移的认知）

3 个关键差异（别搞错）

差异 1：一致性协议（最核心）

Kafka 用 ISR（In-Sync Replicas）：
   Leader 单点决定顺序，Follower "拉"数据（pull model）
   acks=all 时所有 ISR 都确认才返回
   如果 ISR 缩水（Follower 慢），仍可继续工作

OceanBase 用 Paxos：
   多数派（quorum）决定，不是 Leader 单点
   写入需要 2/3 副本确认（不要求全部）
   严格的强一致，符合数学证明
   更复杂但更可靠

为什么差异：Kafka 优先吞吐（消息偶尔可丢），OB 优先正确性（数据库绝对不能丢）。

差异 2：数据模型

Kafka：Append-Only Log（追加日志）
   - 不可变（immutable）
   - 按 offset 读取
   - 没有索引、没有 UPDATE/DELETE
   - 顺序消费

OceanBase：CRUD 表（可变数据）
   - 可变（mutable）
   - 支持主键、二级索引
   - 用 MVCC 实现多版本
   - 用 LSM-Tree 把"修改"也变成追加（背后原理）

差异 3：存储引擎

Kafka：日志段文件
   /var/kafka/orders-0/
   ├── 00000000000000000000.log      ← 顺序日志
   ├── 00000000000000000000.index    ← 偏移量索引
   └── 00000000000000123456.log      ← 滚动到新段

OceanBase：LSM-Tree（详见后文 3.18）
   MemTable (内存)  →  转储  →  SSTable L0  →  合并  →  SSTable L1/L2...

Kafka → OB 知识迁移表

一句话总结

OB 的集群架构跟 Kafka 是兄弟，差异主要在一致性协议（Paxos vs ISR）和数据模型（CRUD vs Append-only）。

你看 OB 任何分布式概念，都可以问自己：Kafka 里对应的是啥？

想深入这个话题

如果你对”为什么数据库和消息队列用相似的分布式骨架”感兴趣，推荐：

• • Martin Kleppmann《Designing Data-Intensive Applications》 第 5、7、9 章
• • 看完会发现：Kafka、OB、Cassandra、Redis Cluster、ES 都是同一套思想的变体

1. 为什么会有 OceanBase 这种东西

单机 MySQL 的极限

你做电商，订单表数据量到亿级时：

OceanBase 的解法

一句话：OB 是把”数据库”这个软件设计成分布式系统，让一台机器搞不定的事，多台机器一起搞，对外还像一个数据库。

2. OB 的三大基因（这是它的灵魂）

基因 1：分布式 Shared-Nothing

每台机器自己管自己的数据（CPU+内存+磁盘），机器之间不共享存储。

单机数据库（MySQL）：       分布式数据库（OB）：
┌──────────────┐          ┌──────┐ ┌──────┐ ┌──────┐
│  一个数据库   │          │ 节点1 │ │ 节点2 │ │ 节点3 │
│  保存所有数据 │          │  部分 │ │  部分 │ │  部分 │
│              │          │ 数据  │ │ 数据  │ │ 数据  │
└──────────────┘          └──────┘ └──────┘ └──────┘
        ↑                          ↑
   扩容 = 升级硬件            扩容 = 加新节点（便宜 + 在线）

基因 2：Paxos 强一致多副本

同一份数据写 3 个副本，多数派（2/3）写成功就返回成功。

                写入请求
                    ↓
            ┌──────────────┐
            │  副本1（主）  │ ← 立刻写本地
            └──────┬───────┘
                   ↓ 同步复制
        ┌──────────┴──────────┐
        ↓                     ↓
┌──────────────┐       ┌──────────────┐
│ 副本2（从）   │       │ 副本3（从）   │
└──────────────┘       └──────────────┘

  副本1 收到 + 副本2 收到 = 2/3 多数派 → 返回成功
  副本3 慢一点没关系，后台会追上

好处：

• • 任何一台机器坏了，数据不丢（RPO=0）
• • 自动切换到剩下的机器（RTO < 8 秒）
• • 不需要外挂工具（MySQL 需要 MHA/MGR）

基因 3：多租户

一个集群里跑多个”逻辑数据库实例”，每个业务方拿到的是自己专属的实例。

        OceanBase 集群
┌───────────────────────────────────┐
│  ┌─────────┐ ┌─────────┐ ┌──────┐│
│  │租户A     │ │租户B     │ │租户C  ││
│  │电商业务   │ │外卖业务   │ │营销  ││
│  │2CPU+2G  │ │4CPU+4G  │ │1CPU ││
│  └─────────┘ └─────────┘ └──────┘│
└───────────────────────────────────┘

好处：

• • 业务线之间资源隔离（电商大促不影响外卖）
• • 一个 DBA 管多业务（省人力）
• • 资源利用率高（不忙的业务让出资源给忙的）

3. 核心概念详解（这是本文重点）

下面每个概念都用「是什么 / 类比 / 关键点」三段式讲清楚。

3.1 Cluster（集群）

是什么：整个 OceanBase 数据库系统，由多台机器组成。

类比：你家小区（Cluster）里有 3 栋楼（Zone），每栋楼里住着多户人家（Observer）。

关键点：

• • 一个 Cluster 有唯一的 cluster_id
• • 集群名在创建后不能改
• • 所有租户、数据、副本都属于某个 Cluster

3.2 Zone（可用区）

是什么：Cluster 内部的逻辑分组，通常对应一个机房或一个机柜。

类比：小区里 3 栋楼（Zone），每栋楼电力独立（机房故障隔离）。

关键点：

• • 一个 Cluster 至少 1 个 Zone，生产推荐 3 个
• • 同一分区的多个副本必须分布在不同 Zone（这样坏一个机房不丢数据）
• • Zone 之间网络延迟通常 < 1ms（同城）

Zone 设计示例（同城三机房）：
Cluster
├── Zone A  ← 机房 1（北京 - 亦庄）
├── Zone B  ← 机房 2（北京 - 上地）
└── Zone C  ← 机房 3（北京 - 望京）

3.3 Region（地域）—— 可选概念

是什么：地理区域的分组，一个 Region 包含多个 Zone。

类比：北京 Region 包含亦庄 Zone + 上地 Zone + 望京 Zone。

关键点：

• • 用于跨城容灾场景（北京 Region + 上海 Region）
• • 同 Region 内同步复制，跨 Region 异步复制
• • 电商通常一城三机房就够，不用搞跨城

3.4 Server / Observer（节点）

是什么：一个 observer 进程，跑在一台物理/虚拟机上。一个 Server 同时承担计算 + 存储 + 事务三种角色。

类比：一户人家（Observer），既做饭（计算）又存粮（存储）又管账（事务）。

关键点：

• • 跟 MySQL 的 mysqld 不一样：mysqld 是单进程管一个实例；observer 进程管多个租户
• • 一台机器只跑一个 observer
• • observer 监听两个端口：
  • • 2881：SQL 端口（你的 JDBC 连这个）
  • • 2882：RPC 端口（节点之间内部通信用）

3.5 Tenant（租户）⭐ 重点

是什么：Cluster 内部的”逻辑数据库实例”。从用户视角看，租户 = 一个独立的数据库。

类比：

• • MySQL 视角：你买了一个云数据库 RDS 实例 ← 这就是 OB 的一个租户
• • 现实视角：租了个独立办公室，里面家具（数据）自己管，但水电（CPU/内存）由大楼（Cluster）配额

关键点：

• • 每个租户有自己的：用户、数据库、表、配置
• • 资源（CPU/内存）通过 Unit Config + Resource Pool 分配
• • 租户之间数据完全隔离（不同租户之间看不到对方数据）
• • 内置 sys 租户是系统租户，不能跑业务

电商公司示例：
Cluster
├── sys 租户       （DBA 管理）
├── mall_tenant    （电商业务线）
├── o2o_tenant     （外卖业务线）
└── marketing_tenant（营销业务线）

怎么连进去：用户名 root@mall_tenant（OB 用 @ 区分租户，跟 MySQL 的 @host 完全不是一回事）

3.6 Database（数据库）

是什么：租户内部的命名空间，跟 MySQL 的 Database 概念一致。

类比：你办公室里的不同抽屉（Database），每个抽屉放不同的东西。

关键点：

• • 一个租户可以有多个 Database（比如订单库 order_db、用户库 user_db）
• • Database 内部放 Table、View、Procedure 等对象
• • 跟 MySQL 完全一样，不展开

3.7 Table（表）

是什么：数据存储的逻辑结构，跟 MySQL 的 Table 一样。

关键点：

• • OB 的表必须有主键（没主键会自动生成隐藏主键 __pk_increment）
• • 表会被切成多个 Partition（除非是非分区表，那就只有 1 个 Partition）
• • 表的所有数据都存在 Partition 里

3.8 Partition（分区）⭐ 重点

是什么：表的数据分片单位。一张大表可以按规则切成多个 Partition，分布到不同机器上。

类比：

• • MySQL 视角：跟 MySQL 的 PARTITION 概念接近，但 OB 的 Partition 是分布式单位（可以跨节点）
• • 现实视角：一本厚厚的字典被切成 26 本（按字母 A-Z），每本可以放不同书架

关键点：

• • Partition 是 OB 分布式的最小单位：副本复制、负载均衡、故障切换都基于 Partition
• • 单表也可以有 1 个 Partition（小表）
• • 分区类型：
  • • Range：按范围（订单按月分）
  • • Hash：哈希取模（用户表按 user_id 分散）
  • • List：枚举（按地区分）
  • • Key：自定义键
  • • 组合分区：Range + Hash 等（电商常用）

订单表示例（Range + Hash 组合）：
orders 表
├── P_202601 (1月数据)
│   ├── SubP_0 (user_id % 4 = 0)
│   ├── SubP_1 (user_id % 4 = 1)
│   ├── SubP_2
│   └── SubP_3
├── P_202602 (2月数据)
│   ├── SubP_0 ...
...

电商最常用：

• • 订单表：RANGE(创建时间) SUBPARTITION BY HASH(user_id) ← 月数据 + 用户分散
• • 用户表：HASH(user_id) ← 均衡
• • 商品表：不分区或 HASH(merchant_id)

3.9 Tablet（Tablet）—— OB 4.x 新概念

是什么：Partition 在存储层的实体（每个 Partition 对应一个 Tablet）。

类比：Partition 是”概念”，Tablet 是”实物”。

关键点：

• • 你日常 SQL 不需要管 Tablet
• • 但看 OB 日志、运维时会看到这个词，知道是同一回事就行

3.10 Replica（副本）⭐ 重点

是什么：同一个 Partition 的多份拷贝，分布在不同 Server/Zone 上。

类比：同一份合同打印 3 份，分别放在 3 个保险箱。

关键点：

• • 默认 3 副本（Paxos 协议要求）
• • 副本类型：
  • • 全能型（FULL）：能读能写能投票，最常用
  • • 日志型（LOGONLY）：只存日志，特殊场景
  • • 只读型（READONLY）：只读不投票，扩展读能力
• • 同一 Partition 的多个副本之间用 Paxos 同步

订单表分区 P_202601 的 3 个副本：

Zone A               Zone B               Zone C
┌──────────┐         ┌──────────┐         ┌──────────┐
│  副本1    │         │  副本2    │         │  副本3    │
│ (Leader) │ ←同步→  │(Follower)│ ←同步→  │(Follower)│
│  读写     │         │  只读     │         │  只读     │
└──────────┘         └──────────┘         └──────────┘

3.11 Leader / Follower（主副本/从副本）

是什么：同一 Partition 多个副本中的角色分工。

类比：办公室里 3 个人，1 个组长（Leader）签字拍板，2 个组员（Follower）跟班记录。

关键点：

• • Leader：处理读写请求，对外提供服务
• • Follower：同步 Leader 的日志，待命
• • Leader 挂了，Follower 自动选举成为新 Leader（< 8 秒）
• • 选主过程基于 Paxos 协议（多数派投票）

3.12 Paxos 协议（OB 的一致性根基）

是什么：一种分布式一致性算法，保证多个副本数据一致。

类比：

• • 投票表决：3 个人投票，超过半数（2 票）通过就算决议生效
• • 即使 1 个人睡着了（机器故障），剩下 2 个人也能继续工作

关键点：

• • OB 用 Paxos 保证：写入只要多数派（2/3）成功就算成功
• • 这就是 RPO=0 的来源（数据不会丢）
• • 不需要外挂主从复制工具（MySQL 的痛点）

简单工作流程：

1. 客户端 → Leader："写入数据 X"
2. Leader 写本地日志，给 Follower1、Follower2 发请求
3. Follower1 写入并回复 OK
4. Leader 收到 2 个 OK（自己 + Follower1）→ 多数派达成 → 返回客户端成功
5. Follower2 慢慢追上

3.13 Unit Config（资源单元配置）

是什么：一份”资源套餐”模板，定义了 CPU/内存的上下限。

类比：运营商的流量套餐（10元1G、50元10G），是预定义的资源规格。

示例：

CREATE RESOURCE UNIT mall_unit
  MIN_CPU=4, MAX_CPU=8,           -- CPU 核数范围
  MIN_MEMORY='4G', MAX_MEMORY='8G'; -- 内存范围

关键点：

• • 定义了”规格”，但还没分配给谁
• • 一个 Cluster 可以有多个 Unit Config（不同业务线用不同规格）

3.14 Resource Pool（资源池）

是什么：把 Unit Config 应用到具体的 Server 上，形成可分配的资源池。

类比：

• • Unit Config = 套餐规格（”10 元 1G”）
• • Resource Pool = 实际开卡（”在 A、B、C 机房各开 1 张卡”）

示例：

CREATE RESOURCE POOL mall_pool
  UNIT = mall_unit,
  UNIT_NUM = 1,                    -- 每个 Zone 分配几个 Unit
  ZONE_LIST = ('zone1','zone2','zone3');

关键点：

• • Resource Pool 才是真正”占用”资源的实体
• • 一个 Resource Pool 只能属于一个租户
• • 一个租户可以有多个 Resource Pool

3.15 Unit（资源单元）

是什么：Resource Pool 在每个 Server 上实际分配的资源块。

类比：你办的卡，在每个机房都有一份实际的”资源额度”。

关键点：

• • Unit 是 CPU/内存的实际占用单元
• • 一个 Server 上不同租户的 Unit 是隔离的
• • Unit 数量决定数据副本分布（一般 UNIT_NUM = 1）

3.16 资源三层关系（必须搞懂）

这是 OB 多租户最容易混淆的地方，看这一张图就懂：

   定义规格               应用到机房              分配给租户
   ──────────            ──────────              ──────────

 ┌────────────┐       ┌──────────────┐       ┌──────────────┐
 │Unit Config │  ──→  │Resource Pool │  ──→  │   Tenant     │
 │(套餐规格)   │       │(开卡)         │       │  (使用)       │
 │            │       │              │       │              │
 │MIN_CPU=4   │       │ZONE_LIST=    │       │ mall_tenant  │
 │MAX_CPU=8   │       │ ('z1','z2',  │       │              │
 │MIN_MEM=4G  │       │  'z3')       │       │              │
 │MAX_MEM=8G  │       │UNIT_NUM=1    │       │              │
 └────────────┘       └──────────────┘       └──────────────┘
                              │
                              ↓ 在每个 Zone 上
                       ┌──────────────┐
                       │  Unit (实例)  │
                       │  zone1: 1个   │
                       │  zone2: 1个   │
                       │  zone3: 1个   │
                       └──────────────┘

实战 SQL（创建一个完整租户的流程）：

-- 1. 定义套餐规格
CREATE RESOURCE UNIT mall_unit
  MIN_CPU=4, MAX_CPU=8,
  MIN_MEMORY='4G', MAX_MEMORY='8G';

-- 2. 在 3 个 Zone 上各开 1 张卡
CREATE RESOURCE POOL mall_pool
  UNIT = mall_unit,
  UNIT_NUM = 1,
  ZONE_LIST = ('zone1','zone2','zone3');

-- 3. 把卡分配给新租户
CREATE TENANT mall_tenant
  RESOURCE_POOL_LIST=('mall_pool')
  SET ob_tcp_invited_nodes='%';

-- 4. 用 root@mall_tenant 连进去用

3.17 OBProxy（接入层）

是什么：一个无状态的 SQL 路由代理，部署在应用服务器或独立机器上。

类比：

• • 餐厅前台：你（应用）告诉前台要点哪桌的菜（哪个 Partition），前台把你领到对的桌位（Observer）
• • 像酒店的礼宾部：你不直接找房间，礼宾部带你去

关键点：

• • 无状态：可以水平扩展（部署多个 OBProxy）
• • 路由规则：根据 SQL 里的租户、Partition 信息，把请求发到 Leader 所在的 Observer
• • 不能没有：生产环境必须有 OBProxy，应用不直连 observer
• • 默认监听 2883 端口

应用 ──→ OBProxy (2883) ──→ Observer (2881)
                            │
                            ├─ zone1-observer
                            ├─ zone2-observer
                            └─ zone3-observer

⚠️ 单机版（Docker 那个）可以不用 OBProxy，应用直连 observer 的 2881 即可。生产环境必须用 OBProxy。

3.18 MemTable + SSTable（存储引擎）

是什么：OB 用 LSM-Tree 存储数据，分两层：

• • MemTable：内存里的可读写区（最新数据）
• • SSTable：磁盘上的不可变区（持久化数据）

类比：

• • MySQL 的 B+Tree = 你的衣柜（找衣服时翻整个衣柜）
• • OB 的 LSM-Tree = 桌面 + 文件柜：
  • • 桌面（MemTable）：刚买的衣服随手放，找最新的快
  • • 文件柜（SSTable）：定期整理归类放进去

写入流程：

1. INSERT 一条数据
2. 先写 clog（commit log，保证不丢）
3. 写入 MemTable（内存）
4. 立即返回成功（写内存极快）

— 后台异步 —
5. MemTable 满了 → 转储（Minor Freeze）到 SSTable
6. 多个 SSTable → 合并（Major Compaction）成大 SSTable

关键点：

• • 写性能极快（写内存）
• • 读需要合并 MemTable + 多个 SSTable（性能稍复杂）
• • 转储/合并是后台任务，对应用透明
• • 这是 OB 跟 MySQL 最大的存储层差异

3.19 clog（Commit Log）

是什么：OB 的提交日志，类似 MySQL 的 redo log + binlog 二合一。

类比：你每天记账写在小本本上，万一电脑坏了，本本还在就能恢复。

关键点：

• • 强一致保证：写入必须先持久化 clog（Paxos 多副本同步 clog）
• • 不能丢、不能漏（这是 RPO=0 的根基）
• • 跟 MySQL binlog 不同：clog 是 Paxos 复制的载体

3.20 Major / Minor Freeze（合并/转储）

是什么：LSM-Tree 的后台维护操作。

类比：

• • 转储 = 桌面放不下了，先塞抽屉
• • 大合并 = 周末大扫除，把所有抽屉重新整理一遍

电商运维提示：大合并期间业务可能有轻微影响，电商大促前要确认合并时间窗口。

3.21 GTS（Global Timestamp Service）—— 事务核心

是什么：全局唯一时间戳服务，用于分布式事务排序。

类比：电商订单系统需要一个”全局时间”来排序交易（即使订单来自不同机房）。

关键点：

• • 分布式事务的核心：让跨多个 Partition 的事务有一个统一的可见性顺序
• • OB 用 GTS 实现全局一致性读
• • 不用 GTS 也行（用本地时间戳），但会有跨节点一致性问题

3.22 OBProxy vs OBClient vs mysql client

4. 数据写入流程（一个 INSERT 怎么走）

┌──────┐
│ App  │  INSERT INTO orders VALUES (...)
└──┬───┘
   │ 1. 通过 JDBC 发 SQL
   ↓
┌──────────┐
│ OBProxy  │  2. 解析用户名（root@mall_tenant）
│          │  3. 找到 orders 表对应 Partition 的 Leader
└──┬───────┘
   │ 4. 转发到 Leader 所在 Observer
   ↓
┌──────────────────────┐
│ Observer (Leader)    │
│                      │
│ 5. 解析 SQL          │
│ 6. 开启事务           │
│ 7. 写 clog（Paxos）   │ ← 同步给 2 个 Follower
│   ↓                  │   多数派（2/3）写成功才继续
│ 8. 写 MemTable       │
│ 9. 返回 OBProxy      │
└──┬───────────────────┘
   │
   ↓
┌──────┐
│ App  │  10. 收到成功响应（< 10ms）
└──────┘

— 后台异步 —
• MemTable 满了 → 转储到 SSTable
• 每天凌晨 → 大合并

关键认知：

• • 写入非常快（写内存 + 多数派 clog 同步）
• • 应用看到的”成功” = clog 多数派持久化 + MemTable 更新
• • 真正的磁盘 SSTable 是后台异步刷的

5. 数据查询流程（一个 SELECT 怎么走）

┌──────┐
│ App  │  SELECT * FROM orders WHERE user_id=123
└──┬───┘
   │
   ↓
┌──────────┐
│ OBProxy  │  1. 路由：根据 user_id 找到所在 Partition
└──┬───────┘
   │
   ↓
┌──────────────────────┐
│ Observer             │
│                      │
│ 2. 解析 SQL          │
│ 3. 优化器生成执行计划 │
│   - 单 Partition 查询？直接查
│   - 跨 Partition？分布式执行
│ 4. 执行：             │
│   - 查 MemTable（内存最新）
│   - 查 SSTable（磁盘历史）
│   - 合并结果          │
│ 5. 返回结果          │
└──────────────────────┘

关键认知：

• • 单 Partition 查询 = 单机查询性能
• • 跨 Partition 查询 = 触发分布式执行（慢一些）
• • 分区裁剪（Partition Pruning）：优化器识别只查某个 Partition，跳过其他

6. 高可用原理（电商最关心）

6.1 三机房容灾

机房 A          机房 B          机房 C
┌──────┐       ┌──────┐       ┌──────┐
│ 副本1 │       │ 副本2 │       │ 副本3 │
│Leader│ ←→    │Follow│ ←→    │Follow│
└──────┘       └──────┘       └──────┘

场景：机房 A 整个挂了
  ↓
1. Follower1（机房 B）和 Follower2（机房 C）发起选举
2. 多数派达成（2/3 还在）→ 选出新 Leader
3. OBProxy 自动路由到新 Leader
4. 业务恢复（< 8 秒）
5. 数据零丢失（机房 A 挂之前，多数派已经持久化）

6.2 电商典型容灾架构

7. OB vs MySQL 终极对比（你熟悉的视角）

8. 常见名词速查表