OceanBase 数据库作为一款原生分布式数据库，其设计精髓在于通过“分布式”技术，同时解决了传统数据库在 扩展性、高可用性和 性能上的瓶颈。

其基石是集群概念，一个集群由多个 OBServer 节点（物理或虚拟机）组成，每个节点兼具计算与存储能力。数据通过多副本机制存储在集群中，并基于 Paxos 协议实现副本间的强一致性同步，这为数据零丢失（RPO=0）打下了坚实基础。在此之上，OceanBase 通过多租户架构将物理集群资源逻辑隔离，每个租户如同一个独立的数据库实例，拥有独立的资源规格、兼容模式（MySQL/Oracle）和数据库对象，实现了资源的精细化管理和隔离。

为了对应用屏蔽底层数据的分布式复杂性，OceanBase 引入了 ODP 作为智能代理层。它是整个数据库集群的统一入口，能够精准地将 SQL 请求路由到存储目标数据的 OBServer 节点，并自动屏蔽故障节点，保障访问的高可用。为了进一步优化性能，OceanBase 提供了 Primary Zone 和表组两大调度策略。Primary Zone 允许通过规则控制数据“主副本”的分布，从而将写流量导向指定的机房或区域，减少跨地域访问延迟；而表组则通过将关联紧密的数据聚集在同一台服务器上，极大提升了分布式关联查询的效率。集群的“大脑”——根服务，则持续在后台进行资源的调度、负载的均衡以及副本的管理，确保系统能够平滑地扩缩容并始终保持高效稳定运行。

最终，所有这些技术共同构筑了 OceanBase 强大的高可用部署架构。多副本与 Paxos 协议确保了单点故障时的数据不丢失与服务快速自愈（RTO < 8s）。仲裁服务机制，使得系统能够以更低的成本部署跨地域容灾方案（如两地三中心、三地五中心），并在发生数据中心级故障时，能自动完成降级与恢复，维持集群的多数派可用。无论是同城双活、同城三中心还是跨地域多活，OceanBase 都能提供灵活、高可用且数据强一致的部署方案，从容应对各种级别的故障挑战，为业务提供持续可用的数据库服务。

一、集群基本概念

1、 基础架构与访问流程

1. 分层架构：OceanBase 的访问流程可分为四层：
   • 应用层：业务应用程序。
   • 负载均衡层：将请求分发到不同的数据库代理。
   • 数据库代理层（OBProxy）：负责 SQL 解析、路由和读写分离，对应用透明。
   • OceanBase 层（OBServer 节点）：由多个 OBServer 节点组成，负责数据的存储与计算。
2. 核心设计理念：
   • 多节点与多副本：通过分布式部署多个 OBServer 节点和数据副本，确保高可用性和数据可靠性。
   • 读写分离：OBProxy 可自动将写请求发往主副本（Leader），将读请求分发到从副本（Follower），优化性能。

2、集群、多租户与高可用机制

1. 集群与可用区：
   • 集群：由多个 OBServer 节点组成的集合，是部署的基本单位。
   • 可用区（Zone）：集群内的逻辑概念，通常对应一份完整的数据副本，用于实现容灾和负载均衡。
2. 多副本与 Paxos 协议：
   • OceanBase 使用 Paxos 协议实现多副本数据同步，确保事务日志在多数派副本持久化后才提交，保证数据强一致性。
   • 为避免“脑裂”，建议部署奇数个副本（如 3 或 5）。从 V4 版本开始，引入仲裁服务，支持在偶数副本下通过仲裁节点完成多数派投票，增强了部署灵活性。
3. 多租户架构：
   • OceanBase 采用原生多租户设计，实现不同租户间资源与数据的隔离。
   • 租户分为三种类型：
     • 系统租户（sys）：管理整个集群，ID 固定，数据私有。
     • 用户租户：由用户创建，承载业务数据，ID 从 1002 开始（偶数）。
     • Meta 租户：系统自动为每个用户租户创建的影子租户，用于存储该用户租户的元数据，ID 为用户租户 ID 减一（奇数），不支持直接连接。

3、弹性扩缩容与资源管理

1. 扩缩容策略：
   • 水平扩缩容：通过增加或减少可用区或每个可用区内的 OBServer 节点数量，来线性提升或降低集群的整体处理能力。
   • 垂直扩缩容：通过调整租户的资源规格（如 CPU、内存），来改变单个 OBServer 节点上该租户的资源上限。
2. 资源分配模型：
   • 资源规格：定义了一个资源单元（Unit）的 CPU、内存、磁盘等资源大小。
   • 资源池：由多个资源单元组成，定义了租户在某个可用区内可使用的资源总量。
   • 创建租户时，需要指定其兼容模式（MySQL 或 Oracle，不可更改）、同时，必须指定一个已创建好的资源池，这个资源池就定义了该租户所能使用的全部资源给它，从而实现资源的精细化和均衡分配。
   • 整体过程：定义资源单元 (Unit) → 创建资源池 → 创建租户并绑定资源池。
3. 动态调整：OceanBase 支持在线进行水平和垂直扩缩容，资源调整可动态生效，无需停服，保证了业务的连续性和资源利用率。

4、数据一致性、读写与副本类型

1. 读写机制与高可用：
   • 每个数据分区有一个主副本负责处理读写请求，多个从副本用于高可用和读负载均衡。
   • 当主副本故障时，系统会通过 Paxos 协议自动从从副本中选举出新的主副本，实现故障自动切换，服务不中断。
2. 副本类型：
   • 全功能副本：参与 Paxos 协议投票和日志同步，可以升级为主副本，提供强一致性读写服务。
   • 只读副本：通过异步同步数据，不参与 Paxos 投票和 Leader 选举，仅提供弱一致性（最终一致性）的读服务，用于扩展读性能。
3. V4 架构优化：在 OceanBase V4 的单机日志流架构中，事务的参与者由分区转变为 OBServer 节点本身，这简化了分布式事务流程，提升了处理效率，使得使用体验更接近单机数据库。

补充，一些易混淆的点：

• 一个 OBServer 节点就是一个独立的物理服务器、虚拟机或容器，是 OceanBase 集群中提供计算和存储服务的最小物理单元；
• 一个 OBServer 节点（一台服务器）可以同时为多个租户提供资源，即，同时运行着来自多个不同租户的多个数据库的服务。同样，一个租户的资源也可以通过资源单元的形式，分布在多个 OBServer 节点上。这正是 OceanBase 可以实现水平扩展和高可用的基础；
• 数据库的兼容模式是由租户决定的，在创建租户时，就必须通过参数 ob_compatibility_mode 指定其兼容模式（MySQL 或 Oracle），此设置一旦创建，无法更改。一个租户就像一个独立的数据库实例，在这个实例下创建的所有数据库，都自动继承并遵循该租户的兼容模式。数据库的兼容模式与使用的 OBServer 节点无关，OBServer 节点是通用计算存储节点，它本身不关心也不定义兼容模式，可以同时供 MySQL 租户和 Oracle 租户使用。

---

二、路由与负载均衡

1、访问入口：ODP (OceanBase Database Proxy)

1. 核心定位：ODP（也称 OBProxy）是分布式数据库集群的统一访问入口。作为无状态的反向代理，它对应用屏蔽了底层数据的分布式复杂性。
2. 核心功能：
   • 智能路由：通过轻量级 SQL 解析，感知表和分区的 Leader 副本位置，将请求精准路由到正确的 OBServer 节点。
   • 高可用保障：自动感知 OBServer 节点状态，屏蔽故障节点，实现请求的自动容灾切换。
   • 高性能转发：本身不进行数据加工，专注于 SQL 转发，可提供每秒百万级的路由能力。
   • 连接管理：采用两段式连接管理（应用-ODP， ODP-OBServer），简化应用端连接池管理。
3. 高可用部署：通过部署多个 ODP 实例，并搭配 F5、SLB 等负载均衡设备为其分配统一的 VIP 或域名，实现 ODP 层自身的高可用与负载均衡。

2、数据路由：OBServer 节点的路由与转发

1. 计算与存储一体化：每个 OBServer 节点兼具计算和存储功能，能够执行本地数据操作。
2. 分布式查询处理：在执行多表关联等复杂查询时，OBServer 节点作为协调者，能将子请求分发到涉及的其他节点，并汇总结果。
3. 请求转发：当 ODP 因元信息未及时更新等原因路由失败时，收到请求的 OBServer 节点具备转发能力，可将 SQL 请求再次发送到正确的节点执行，确保查询成功。

3、流量调度：Primary Zone 策略

1. 设计目的：在跨可用区/数据中心部署时，通过控制 **主副本（Leader）**的分布，将写业务流量集中到指定区域，减少跨中心网络延迟，优化性能。
2. 配置语法：
   • 分号（;） 表示优先级。例如 "Z1; Z2" 表示优先选择 Z1，Z1 不可用时才选择 Z2。
   • 逗号（,） 表示同一优先级。例如 "Z1, Z2" 表示 Z1 和 Z2 优先级相同，Leader 会均匀分布在这两个 Zone。
3. 最佳实践：根据业务架构，合理设置租户级 Primary Zone，是实现跨地域部署性能优化的关键手段。

4、数据局部性：表组 (Table Group)

1. 设计目的：通过将业务关联紧密的表或分区聚集到相同的 OBServer 节点上，减少分布式查询带来的跨节点访问，极大提升关联查询性能。
2. Sharding 模式：
   • NONE：表组内不同表的不同分区可聚集在同一节点。适用于无强分区关联性但希望数据集中的场景。
   • PARTITION：要求表组内各表分区方式和数量完全相同，相同编号的分区聚集在同一节点。适用于分区键一致且需要频繁关联的大表。
   • ADAPTIVE：一种更灵活的模式，同样要求分区方式一致，能在特定场景下提供更好的适应性。

5、全局大脑：根服务 (Root Service, RS)

1. 核心角色：RS 是系统租户的内置服务，运行在系统租户的 Leader 节点上，是集群的**“管理大脑”**。
2. 核心职责：
   • 资源与生命周期管理：负责租户、资源单元（Unit）、资源池的创建、分配与扩缩容管理。
   • DDL 与元数据同步：负责执行 DDL 语句并确保集群元数据的一致性。
   • 负载均衡：
     • 在节点扩缩容、Primary Zone 变更、日常运行时，自动生成并执行负载均衡计划。
     • 均衡目标包括：分区数量、数据量大小、Leader 副本分布等，确保业务负载均匀分摊到每个 OBServer 节点。
   • 容灾与高可用：自动监控节点状态，在节点故障时，调度其上的副本迁移到健康节点，恢复服务与冗余。

---

三、高可用部署架构

1、高可用核心指标：RTO 与 RPO

1. RTO - 恢复时间目标：指数据库故障后，服务恢复所需的时间。该值越短，服务中断时间越短，服务可靠性越高。
2. RPO - 恢复点目标：指数据库故障后，允许丢失的数据量所对应的时间范围。RPO=0 意味着数据零丢失。
3. 指标关系与意义：RTO 总是大于零（服务恢复需要时间），而 RPO 可以为零。这两个指标是衡量数据库容灾能力的核心，需根据业务容忍度进行规划。
4. OceanBase 高可用表现：凭借其原生分布式多副本架构，OceanBase 可实现 RTO < 8秒 和 RPO = 0，满足金融级容灾标准。

2、高可用基础：多副本与 Paxos 协议

1. 数据一致性保障：OceanBase 通过 Paxos 协议在多副本间同步数据，确保事务日志必须在多数派副本持久化后才提交，从根本上保证了数据的强一致性和零丢失（RPO=0）。
2. 快速故障恢复：当主副本（Leader）所在节点发生故障时，系统会自动在剩余的可用从副本（Follower）中基于 Paxos 协议选举出新的 Leader，实现秒级（<8s）服务切换，保证业务连续性。
3. 与传统数据库对比：传统主从复制采用异步或半同步模式，无法保证 RPO=0，且故障切换多需人工干预，RTO 常超过30分钟。

3、核心机制：仲裁服务

1. 角色定位：仲裁服务是一个不存储数据的特殊角色，仅作为“中立第三方”参与 Leader 选举投票，资源消耗极低。
2. 核心价值：
   • 支持偶数副本：在部署奇数个全功能副本成本过高时，可通过“偶数全功能副本 + 仲裁节点”的配置，在保证多数派决策的同时，降低部署成本。
   • 自动降级：在网络分区或数据中心故障时，仲裁服务能配合系统自动调整有效副本数，确保集群仍能形成多数派，避免服务不可用。
3. 典型场景：在“两地三中心”部署中，两个数据中心部署全功能副本，第三个站点仅部署仲裁服务，即可以较低成本实现城市级容灾。

4、自动运维：故障恢复与副本管理

1. 自动故障切换：任何包含 Leader 副本的节点故障，系统都会在秒级内自动完成 Leader 重选举，对应用透明。
2. 自动副本修复：
   • 当节点故障时间超过阈值，系统会自动将其上的副本标记为不可用。
   • 随后，系统会在资源允许的同 Zone 内其他节点上自动重建（补）副本，使集群恢复完整的冗余能力。
3. 负载均衡：Root Service 会持续监控集群状态，在扩缩容、节点增减或数据分布不均时，自动调度副本分布，保持集群负载均衡。

5、高可用部署模式

1. 同城双中心主备库
   • 两个数据中心各自运行独立的 OceanBase 集群。
   • 集群间通过租户级的主备关系进行数据同步。
   • 优势：每个集群的主租户均可对外提供服务，实现了双活部署，解决了传统备库闲置的问题，资源利用率高。
2. 同城三中心
   • 在三中心部署全功能副本（如 3 副本或 5 副本），提供最高级别的同城可用性。
   • 低成本方案：采用 2F1A（两个全功能副本 + 一个仲裁），在第三个中心仅部署仲裁服务，在保证高可用的同时显著降低成本。
3. 三地五中心
   • 在两个城市部署四个全功能副本，在第三个城市部署一个仲裁服务（4F1A 模式）。
   • 容灾能力：
     • 可容忍单个数据中心故障。
     • 可容忍单个城市（包含两个数据中心）故障。故障后，剩余两个副本与仲裁节点仍能形成多数派，保证集群可用。
   • 通过仲裁服务的自动降级机制，灵活应对不同级别的故障场景。

---

四、用“大型商场”比喻理解 OceanBase 核心架构

为了直观理解 OceanBase 的分布式架构，我们可以将其想象成运营一个超大型的现代化商场。

第一部分：商场的建筑与高可用基石（物理与容灾层）

首先，我们要确保商场大楼本身坚不可摧，即使部分区域出问题，整体也能照常营业。

• 集群：就是整个商场大楼。它是我们提供的完整、独立的购物中心（数据库服务）。
• 可用区：是商场里功能独立的营业区域，比如一楼 A 区、二楼 B 区、三楼 C 区。每个区域有独立的供电和安保。一个区域出事，其他区域不受影响，保证了商场整体不停业。
• OBServer 节点：是商场里一个个具体的商铺或柜台。它们是真正为顾客提供商品和服务（数据存储与计算）的基本单位。
• 副本：是热门商品的多个库存仓库。比如一款畅销手机，我们会在一楼、二楼、三楼的仓库各存一批。这样，任何一个仓库失火，我们都能从其他仓库调货，保证商品不缺货（数据不丢失）。
• Paxos 协议：是各仓库间的分布式共识机制。
  • 流程：当作为主仓库（Leader）的一楼仓库要卖出一台手机时，它执行以下步骤：
    1. 它首先更新自己的库存。
    2. 然后立即通知二楼和三楼的仓库也更新库存。
    3. 它必须收到至少一个其他仓库的成功确认（例如二楼仓库回复“已更新”）。
    4. 此时，加上它自己的成功，就获得了**至少两个仓库（多数派）**的确认。
  • 效果：只有在获得多数派确认后，这笔销售才被最终确认。这确保了整个系统在任何时候，多数派仓库的数据状态都是完全一致的。即使少数仓库（比如只有一个）数据丢失或损坏，我们也能从多数派中恢复出完整、正确的数据，从而实现 RPO=0（数据零丢失）。
• 仲裁服务：是一位不管理库存的德高望重的总经理。当两个仓库因故无法沟通时，由他快速裁决哪边可以继续营业。他的存在，让“两个仓库+一位总经理”达到了“三个仓库”的容灾效果，成本却更低。

第二部分：商场的招商与资源管理（资源隔离层）

大楼建好了，现在要把它租给不同的品牌，并分配资源。

• 租户：是商场里一个独立的品牌总公司（如“优衣库公司”或“星巴克公司”）。
  • 租户是一个逻辑概念，是管理和访问数据库服务的统一入口。连接到的是这个“总公司”，而不是某个具体分店。
  • 资源隔离：总公司之间资源（店员、水电预算）独立。
  • 体验独立：每个总公司可以规定自己的服务流程（兼容 MySQL 或 Oracle 模式）。
• 资源规格：是给一个店铺制定的建设标准，比如“标准店配置10名店员、200平米面积”（4核CPU、16G内存）。
• 资源单元：是按照资源规格，在某个可用区里实际开出的一家分店。
• 资源池：是定义一个品牌在整个商场所有分店的集合。例如，“优衣库资源池”规定在A、B、C三个区各开一家标准店，确保其服务能力遍布全场。

第三部分：顾客的购物体验（访问路由与性能优化层）

商场运营起来，需要高效引导顾客，优化体验。

• ODP：是商场入口的金牌导购台。你告诉导购想买什么（SQL），他会根据实时情况，直接把你带到最合适的店铺（正确的OBServer 节点），你无需自己记地图。
• Primary Zone：是品牌商的主力店偏好设置。比如优衣库要求“优先在客流量最大的东翼（Z1）设主力店和总仓”。这样，导购（ODP）会优先把重要顾客（写请求）引到东翼的店，因为那里货最全、响应最快。
• 表组：是商场的**“关联商品主题区”**。比如把家具店、灯具店、家居店集中在一起。你想一次性置办家居时，不用跑遍整个商场，在这个区域就能一站式购齐，极大提升效率（减少分布式查询开销）。
• Root Service：是商场的总控管理中心，是幕后大脑。它负责：招商与铺位分配（资源管理）、在人流不均时引导顾客分流（负载均衡）、以及在任何店铺出问题时迅速调度重建（故障恢复与副本管理）。

总结：一次完整的购物流程

把这些角色串联起来，形成一个完整的业务场景：

1. 你（应用）来到商场，想买一件限量版 T 恤（执行查询）。
2. 金牌导购 ODP 根据优衣库设置的 Primary Zone，精准地将你指引到三楼 C 区的优衣库店铺（OBServer 节点）。
3. 这家店能快速服务你，是因为它的商品（数据）在一楼和二楼的仓库（副本） 通过 Paxos 协议 实时同步，保证你看到的信息是绝对准确的。
4. 突然，三楼停电（节点故障）。幕后大脑 Root Service 在几秒钟（RTO < 8s）内，将服务无缝切换到二楼正常营业的优衣库分店，你几乎无感知。而且由于数据实时同步，没有任何购买记录或库存会丢失（RPO=0）。

---

补充

PPT 材料及视频，链接：OceanBase 在线课程。