再聊OceanBase多副本和高可用

上一篇文章 [[20250221 OceanBase 是如何实现高可用的]] 中介绍了 OceanBase 高可用特性，分布式架构不依赖于某个单一节点，其中最为关键的点在于数据的多副本和集群选举机制，当出现异常情况时，能够快速切换到正常节点提供服务，不影响上层应用系统的正常访问。但分布式和多副本引入了多个节点的写数据同步，往往又会成为性能和可靠性带来更多的不确定因素。

在这种背景下，OceanBase 将 Paxos 共识算法与数据库架构深度整合，实现了 RPO(恢复点目标)=0 与 RTO(恢复时间目标)<30秒的金融级可靠性，在2020年TPC-C基准测试中以7.07亿tpmC的成绩刷新当时的世界纪录。可谓是高可用和性能二者兼得，OceanBase 是如何实现的呢？

Multi-Paxos 实现多日志流数据同步

分区是 OceanBase 数据库的基本单元，为了数据安全和提供高可用的数据服务，每个分区的数据在物理上存储多分，称为副本。副本根据负载和 Zone 的配置策略，由系统自动调度分散在多个 Server 上。OceanBase 采用两级分区架构，将数据表按哈希、列表或范围划分为多个分区，每个分区又可以根据不同维度划分为若干子分区。这种设计既保证单个分片的数据量可控，又通过并行处理提升整体吞吐量。

不同于经典 Paxos 算法理论模型，OceanBase 采用 Multi-Paxos 进行日志数据同步，为每个分区的多个副本创建 Paxos 日志组进行日志和状态同步，从而实现不同副本之间的数据一致性。

通过将日志提交过程分解为并行流水线，OceanBase 实现了多轮 Paxos 协商叠加。主副本持续接收客户端请求生成连续日志序列，异步线程池批量推送日志到从副本，采用滑动窗口机制确认多数派(N/2+1)副本的持久化。

通过 Multi-Paxos 优化日志复制流程、减少网络交互、提升并行度，在保证强一致性的同时实现了高吞吐和低延迟，是其 TPC-C 测试打破世界纪录的关键基础。

故障恢复与自动选主

多副本是高可用的基础，故障期间的选举机制则是实现快速故障切换的重要手段。

经典的 Paxos 协议每次 Propose 都需要任意节点发起，通过 Prepare 和 Accept 两阶段达成共识，但未定义稳定的 Leader 角色。

OceanBase 采用 Multi-Paxos 协议选举出长期稳定的 Leader，由 Leader 统一处理客户端请求并驱动日志复制，并且采用 Leader 租约 (Lease) 机制，当选的 Leader 通过租约机制维持其权威，租约期间其他节点不会发起选举，避免频繁的 Prepare 操作，从而实现 “一次 Prepare，多次 Accept”优化连续日志复制，减少网络交互。

当网络分区发生时，从副本检测到主副本失联后，发起选举请求，从幸存的从副本中协商出新的主副本，对外承接业务。整个故障切换时间为秒级，中间过程无需人工干预系统自动完成。

写在最后

分布式架构的发展始于互联网时代对高并发与高可用需求的爆发，从早期的集中式单体系统逐步演变为以水平扩展为核心的分布式体系。通过引入数据分片、副本容错、共识算法（如Paxos/Raft）等技术，解决了单点故障与性能瓶颈。随后，微服务、容器化（如Kubernetes）和云原生技术进一步推动架构解耦与弹性伸缩，而Serverless与边缘计算则拓展了分布式边界。如今，结合AI与大数据，分布式架构正朝着智能化、自适应方向演进，成为支撑全球数字化浪潮的核心基石。