OceanBase 集群架构详解：从图书馆比喻到原理剖析
OceanBase 是蚂蚁集团自主研发的分布式关系型数据库，其集群架构包含集群、Zone、Observer、租户、分区、Tablet、日志流、副本等多个概念。这些概念相互关联，初次接触容易混淆。本文将用"图书馆"作为贯穿比喻，逐一拆解每个组件的职责，最后串联成完整的架构图景。
阅读本文前，建议先了解前文《数据库核心机制详解》中的 WAL、MVCC、Redo Log 等基础知识，这些是理解 OceanBase 底层机制的前提。
一、核心组件的形象比喻
在深入细节之前，先用一个"大型图书馆系统"的比喻建立直观印象：
| 概念 | 图书馆类比 | 核心功能 |
|---|---|---|
| 集群 | 整个图书馆系统（含所有分馆、书籍、管理员） | 管理所有资源，对外提供统一服务 |
| Zone | 不同城市的分馆（如北京馆、上海馆、深圳馆） | 物理隔离的独立区域，用于容灾和资源分配 |
| Observer | 分馆内的书架（每个书架含多排书籍） | 物理服务器，存储和处理数据 |
| 租户 | 不同类型的借阅者（如学生、教师、员工） | 逻辑隔离的用户组，拥有独立资源配额和权限 |
| 分区 | 书籍按类别划分的区域（如小说区、科技区、历史区） | 将大表数据分散到多个 Observer，提升扩展性 |
| Tablet | 每个类别中的具体书架排（如小说区第 1-10 排） | 数据的最小存储单元 |
| 日志流 | 书籍借阅/归还的记录台账 | 记录 Tablet 的所有变更，保证一致性 |
| 副本 | 同一本书的多个复本 | 数据冗余备份，保证高可用 |
二、组件关系的深度解析
1. 集群与 Zone：全球图书馆网络
集群（Cluster） 是整个 OceanBase 实例的最高层级，包含所有 Zone、Observer、租户和数据。一个集群对外提供统一的数据库服务。
Zone 是物理隔离的独立区域，通常对应不同的数据中心或机房。每个 Zone 有独立的供电、网络和冷却系统，可以应对城市级灾难。
典型的部署模式：
- 三地五中心：三个城市五个 Zone，适合金融级高可用场景
- 同城三中心：同城三个 Zone，延迟低，容灾能力适中
- 两地三中心：两个城市三个 Zone，平衡成本和可用性
图书馆比喻：集群是整个图书馆系统，Zone 是分布在不同城市的分馆。当北京馆因火灾关闭时，深圳馆的副本数据仍可提供服务，实现城市级容灾。
2. Observer 与租户：书架与借阅者
Observer 是 OceanBase 的运行节点，运行在物理服务器或容器上，负责数据的存储和计算。每个 Zone 包含多个 Observer。
租户（Tenant） 是逻辑隔离的资源单元，类似于数据库实例的概念。每个租户拥有独立的 CPU、内存和 IO 资源配额，以及独立的账户权限体系。
租户类型：
- 系统租户：
sys租户，管理集群元数据 - 用户租户：普通业务租户，支持 MySQL 或 Oracle 兼容模式
图书馆比喻：Observer 是分馆内的书架，每个书架存储特定类型的书籍。租户是不同的借阅者群体——学生租户只能借阅小说区，教师租户可借阅科技区。不同租户的资源完全隔离，互不干扰。
3. 分区与 Tablet：书籍分类与书架排位
分区（Partition） 是将大表按一定规则（如哈希、范围、列表）拆分成多个更小的管理单元。例如，用户表按 ID 哈希分为 16 个分区，每个分区存储约 1/16 的数据。
Tablet 是分区在物理存储层面的进一步切片。每个分区由一个或多个 Tablet 组成，Tablet 是数据复制、迁移和负载均衡的最小单位。
图书馆比喻：分区类似于将书籍按类别分区（小说区、科技区），而 Tablet 是每个类别中具体的书架排位。用户 ID 1-10000 的数据存放在 Observer1 的 Tablet1，ID 10001-20000 的数据存放在 Observer2 的 Tablet2。
4. 日志流与副本：台账与复本
日志流（Log Stream） 是 OceanBase 最核心的创新之一。每个 Tablet 的写入操作被组织成日志流，记录所有的数据变更（类似 MySQL 的 Redo Log）。日志流通过 Paxos 协议在多个副本间同步。
副本（Replica） 是 Tablet 的冗余备份。每个 Tablet 通常有 3 个副本，分布在不同的 Zone。副本类型：
- 全能型：提供完整的读写能力
- 只读型：仅提供读能力，用于扩展读性能
- 日志型：仅参与日志同步，不存储数据
图书馆比喻：日志流是每排书架的借阅台账，记录所有变更。副本是同一本书在不同分馆的复本。当北京馆的 Observer 故障时，系统自动切换到深圳馆的副本继续服务。
三、动态管理机制
1. 数据均衡：书架整理
随着业务增长，不同 Observer 的负载可能不均衡。OceanBase 的负载均衡组件会自动检测各节点的负载情况，通过 Tablet 迁移来均衡：
- 场景：深圳馆的书架负载过高
- 机制：系统自动将部分 Tablet 迁移到上海馆的空闲书架，并调整日志流归属
2. 故障恢复：书籍补录
当 Observer 发生故障时，系统自动检测并触发恢复流程：
- 场景：北京馆的 Observer1 硬盘损坏，Tablet1 数据丢失
- 机制：系统通过深圳馆的副本和日志流，自动恢复数据并重建 Observer1 的 Tablet1
3. 高可用保障：副本冗余
OceanBase 采用 Paxos 协议实现副本间的数据一致性：
- 每个 Tablet 的 3 个副本分布在不同 Zone
- 写入操作需要多数派（2/3）副本确认才算成功
- 当少数派副本故障时，系统自动降级，不影响正常服务
示例：当北京馆和上海馆同时故障时，深圳馆的副本仍可提供服务（拥有多数派副本）。
四、与单体数据库的对比
| 特性 | OceanBase（分布式） | MySQL（单体） |
|---|---|---|
| 存储上限 | 理论上 PB 级，可动态扩展 | 单机上限，受磁盘限制 |
| 高可用 | 多副本 + Paxos，RPO=0 | 主从复制，可能丢数据 |
| 扩展方式 | 动态增加 Observer，在线扩缩容 | 垂直扩容为主，分库分表成本高 |
| 读写能力 | 读写分离，每个副本可提供读服务 | 主库承担读写，从库只读 |
| 兼容性 | 兼容 MySQL/Oracle 协议 | MySQL 生态 |
五、典型应用场景
金融核心系统
工商银行的对公理财系统采用 OceanBase 三地五中心集群部署，通过五副本机制实现秒级故障切换，满足金融级可用性要求。
电商订单系统
小米的订单数据库按用户 ID 分区，每个分区包含多个 Tablet，支持每秒数万笔交易。分区设计让系统可以线性扩展，大促期间动态增加 Observer 即可承接流量洪峰。
基金清算系统
平安基金的 TA 系统通过 OceanBase 的分布式架构将清算耗时从 2 小时缩短至 30 分钟。分布式并行处理能力是提升性能的关键。
六、总结
| 层级 | 组件 | 职责 | 核心特性 |
|---|---|---|---|
| 物理资源 | Zone + Observer | 提供计算和存储能力 | 水平扩展、故障隔离 |
| 逻辑隔离 | 租户 | 资源隔离和权限管理 | CPU/内存/IO 隔离 |
| 数据分片 | 分区 + Tablet | 数据拆分与分布 | 动态均衡、在线迁移 |
| 数据同步 | 日志流 + 副本 | 保证一致性和可用性 | Paxos 协议、多副本容灾 |
OceanBase 的架构设计体现了分布式数据库的核心思想：通过数据分片实现扩展性，通过多副本和一致性协议实现高可用，通过日志流实现高效的数据同步。理解这些组件的分工与协作，有助于更好地进行架构设计、性能调优和故障排查。