oceanbase 中的OBServer 是什么

郑全

OBServer 是 OceanBase 分布式数据库集群的核心服务节点，是运行 OceanBase 数据库核心进程的物理 / 虚拟服务器实例，也是集群中实际承担数据存储、SQL 执行、分布式计算、Paxos 一致性同步的最小工作单元，OceanBase 集群的所有核心能力均由多个 OBServer 节点协同实现。

简单来说，OceanBase 集群的物理载体就是一组 OBServer 节点，集群的规模、性能、容灾能力完全由 OBServer 节点的数量、配置、部署方式决定，生产环境中集群至少包含 3 个 OBServer 节点（满足 Paxos 3 副本共识要求），且节点数必须为奇数。

一、OBServer 的核心定位与作用
OBServer 是 OceanBase 集群的计算 & 存储一体化节点（OceanBase 采用存算一体化架构，区别于部分分布式数据库的存算分离），单个 OBServer 节点同时承担以下核心工作，所有节点对等协同，无主从之分：

• 数据存储：存储 OceanBase 集群的数据分片（Tablet），每个分片会以 3 副本形式分布在不同 OBServer 节点，实现数据高可用；
• SQL 处理：接收并解析业务侧的 SQL 请求，完成查询优化、执行计划生成、数据读写、结果返回等全流程；
• 分布式协同：参与 Paxos 分布式一致性协议，完成数据副本的同步、主副本选举、故障节点检测与切换；
• 事务管理：执行 OceanBase 自研的分布式事务协议，保证跨节点、跨分片事务的ACID 特性；
• 资源管理：为集群内的租户分配独立的 CPU、内存、磁盘资源，实现租户间的资源隔离。
  

二、OBServer 的核心组成（进程 & 目录）
单个 OBServer 节点上仅运行一个核心进程 observer，无其他额外进程，架构极简，所有功能均由该进程实现，同时包含固定的目录结构用于存储数据、日志、配置等，无需外部中间件依赖。

1. 核心进程：observer

• 是 OBServer 节点的唯一运行进程，由 OceanBase 自研，基于 C++ 开发，占用资源低、性能高；
• 进程包含网络层、SQL 层、事务层、存储层、Paxos 层等核心模块，一站式实现数据库所有能力；
• 进程管理：可通过 systemctl、OBD、OCP 实现启动、停止、重启、升级，故障时会被自动检测并重建。
  

2. 核心目录（部署时指定，生产建议独立挂载 SSD）

目录类型	作用	部署要求
home_path	主目录，存储 observer 程序、配置文件	本地磁盘，≥10G
data_dir	数据目录，存储实际业务数据分片（Tablet）	SSD/NVMe  磁盘，生产≥200G / 节点，独立挂载
log_dir	日志目录，存储运行日志、审计日志、Paxos  同步日志	SSD/NVMe  磁盘，生产≥100G / 节点，独立挂载

三、OBServer 节点的核心特性

• 节点完全对等：集群内所有 OBServer 节点配置一致、功能相同，无主节点 / 从节点之分，逻辑上的主副本会在节点间动态选举，故障时自动切换；
• 存算一体化：每个节点既做计算（SQL 执行）又做存储（数据分片），无需单独的存储节点，架构简洁，故障点少；
• 弹性扩缩容：集群支持在线新增 / 删除 OBServer 节点，新增节点后，集群会自动将数据分片均匀迁移至新节点，实现负载均衡，性能随节点数线性提升；
• 故障无感知：单个 OBServer 节点故障后，其负责的数分片会由其他节点的副本接管，秒级完成故障切换，业务侧无感知，数据不丢失；
• 资源隔离：基于租户实现资源隔离，每个 OBServer 节点会为不同租户分配独立的资源池，租户间的 CPU、内存、磁盘资源互不干扰。
  

四、OBServer 与 OceanBase 集群的关系
OBServer 是集群的基础组成单元，二者是「个体」与「整体」的关系，核心关联规则如下：

• 集群由 OBServer 组成：1 个 OceanBase 集群 = N 个 OBServer 节点（N≥3，奇数，生产推荐 3/5/7）；
• 副本分布在 OBServer：数据分片的 3 副本必须分布在不同的 OBServer 节点，保证单节点故障不丢失数据；
• 集群能力随 OBServer 线性提升：增加 OBServer 节点，集群的存储容量、QPS/TPS 处理能力会同步线性提升；
• OBServer 故障不影响集群：单个 / 少数 OBServer 节点故障，集群仍可正常提供服务，仅性能略有下降，故障节点恢复后会自动重新加入集群并同步数据。
  

五、OBServer 与集群其他组件的配合
OceanBase 集群的完整运行，除核心的 OBServer 节点外，还会搭配 OBProxy、OCP/OBD 等组件，OBServer 与这些组件的核心配合逻辑如下：

• 与 OBProxy 的配合：OBProxy 是数据库代理，对外提供统一的访问入口，业务侧只需连接 OBProxy，由 OBProxy 将 SQL 请求负载均衡路由至对应的 OBServer 节点，业务侧无需感知底层 OBServer 节点的数量和地址；
• 与 OBD 的配合：OBD 是底层部署运维工具，直接操作 OBServer 节点，实现OBServer 节点的部署、启动、停止、升级、状态检查；
• 与 OCP 的配合：OCP 是企业级可视化管理平台，通过纳管 OBServer 节点实现集群管控，可在界面上直观查看所有 OBServer 节点的状态、资源使用率、性能指标，同时实现OBServer 节点的在线扩容 / 缩容。
  

六、OBServer 节点的生产部署要求
OBServer 作为集群的核心，其部署配置直接决定集群性能，生产环境需严格遵循以下要求，测试环境可适当降低：

1. 硬件配置（x86_64 架构）

配置项	生产最低要求	生产推荐要求
CPU	16  核（物理核）	32  核 / 64 核（物理核）
内存	64G	128G/256G
磁盘	1TB  SSD	2TB/4TB  NVMe
网卡	10G  千兆网卡	25G  万兆网卡

2. 系统配置

• 操作系统：CentOS 7.6+/8.x、Anolis OS 7/8、openEuler 20.03+（Linux 内核≥3.10.0）；
• 内核优化：关闭透明大页、优化文件句柄数（≥65535）、优化网络参数（如 TCP 队列、连接数）；
• 存储要求：数据 / 日志目录必须使用SSD/NVMe 磁盘，避免机械磁盘（性能瓶颈），建议独立挂载；
• 时间同步：所有 OBServer 节点需同步同一 NTP 时间源，时间偏差≤100ms。
  

3. 部署规则

• 节点数：必须为奇数（3/5/7），满足 Paxos 投票共识要求；
• 容灾部署：生产环境建议跨可用区部署（3 节点对应 3 个可用区），避免单机房宕机导致集群不可用；
• 配置一致性：所有 OBServer 节点的硬件、系统、软件版本必须完全一致，避免性能不均。
  

总结
OBServer 是 OceanBase 分布式集群的核心执行单元，是数据存储、SQL 计算、分布式协同的载体，集群的所有能力均由多个对等的 OBServer 节点协同实现；
生产环境中，OceanBase 集群的运维本质上就是对 OBServer 节点的运维（部署、扩容、监控、故障处理），配合 OBProxy 实现访问层高可用，配合 OCP/OBD 实现高效管控。