OceanBase：分布式关系型数据库

可视化演示

交互展示Paxos多副本共识协议、分区数据分布及HTAP统一存储引嵌架构，插示OceanBase高可用与强一致性核心设计。

诞生背景：双11的海啸把小卖部冲垮了

想象你开了一家社区小卖部，平时一天几百个顾客，收银台一台计算机就够用。突然有一天全城大促销，几千万人同时涌进你的小店——收银台前排起长龙，计算机直接死机，账本还差点弄丢。这就是2009年第一次双11时，传统数据库遇到的真实困境：交易量是指数级增长的，而单台“收银机”（数据库服务器）的算力却跟不上。

蚂蚁集团发现，花钱买再大的机器也赶不上剁手党增长的速度。2010年，一群工程师决定从零自研OceanBase。2014年它跑通第一条交易，2017年扛下双11全部流量，2021年对外开源。它不是把一个大数据库拆开，而是天然就设计成多台普通服务器协作的集群，这就是“分布式数据库”的起点。

传统数据库依赖单机算力，扩展靠“换更大的机器”（纵向扩展），贵且天花板明显。OceanBase采用“多台普通服务器组成集群”（横向扩展），数据切片存储、多副本冗余，单机故障不丢数据。双11峰值每秒几十万笔订单，OceanBase都能稳稳接住，靠的就是这套架构。

所以OceanBase从诞生起就想着“把小卖部开成连锁超市”：用多副本机制把MTTR压到最低，让可用性逼近99.99%。双11再大的海啸冲过来，这家超市也能照常结账。

架构总览：连锁超市的集团骨架

连锁超市集团有个明显特点：不是在一条街上开一个超级大店，而是在城市各区开很多分店，每家分店规模适中，但合在一起覆盖全城。OceanBase的架构也是如此。它的基本部署单位叫Zone（可用区），可以理解为一个城市片区；每个Zone里有若干台OBServer节点，也就是一个分店。数据不会只放在一个Zone里，而是同时存到多个Zone的多台OBServer上。

每家分店都存着一份完整的账本副本，这样即使某个Zone因为地震、断电整体“关门”，其他Zone的分店还能继续营业。那多份副本之间怎么保证账目一致？靠的就是后面要讲的Paxos协议。此外，整个集团还有一个“总调度室”——RootService，它负责管理分区的分配、副本的放置和故障后的自动切换。

从高可用设计上看，OceanBase并不要求所有分店都活着才能营业。只要多数派分店存活，系统就能继续提供读写服务。这就是为什么它能做到“城市级容灾”：一个Zone整体不可用，流量自动转移到另一个Zone，业务几乎无感知。

这套“集团骨架”意味着：你不需要买一台超级计算机，而是用一堆普通服务器拼出高可用。每当新开一家分店（扩容节点），RootService会像区域经理一样，把部分货架（分区）调拨过去，让每家分店的负载大致均衡。

Paxos共识：店长投票选出可信决策

假设连锁超市的店长们要决定下周进货单。如果每个店长各写各的，账目必然对不上。Paxos协议就是一套“店长投票规则”：先选出一个Leader（主店长），由他发起提案，其他店长（Follower）收到后表态“同意”或“拒绝”，超过半数同意，提案才算通过。

OceanBase的Paxos实现有几个关键设计。首先是Leader选举：所有节点通过心跳互相探测，发现当前Leader失联就发起新一轮选举，得票过半的新节点成为Leader，避免“脑裂”（两个店长同时发号施令）。其次是日志复制：Leader把写操作记成一条日志，广播给各副本，副本收到后回执确认。最后是多数派提交：只要超过半数的副本确认了这条日志，写入就算成功，不需要等所有副本都写完。

你可能敏锐地发现：5个节点的集群，3个确认就能提交；但如果Leader自己挂了怎么办？没关系——剩下的4个节点中仍然能选出新Leader，而新Leader的数据一定包含了已提交的日志，因为任何已提交的日志都在至少一个存活节点上。这正是“多数派”的精妙之处。

回到超市比喻：店长投票规则保证了“只要多数店长点头，进货单就生效”，而且即使有两家分店联系不上，其他三家也能照常决策。这就是OceanBase数据不丢、服务不停的核心秘密。

分布式事务：跨柜台订单的原子性

顾客在连锁超市买东西，可能同时要结账、积分、开票——分别发生在三个柜台。要么三个柜台都成功，要么全部取消，绝不能出现“钱扣了但积分没加”的情况。在分布式数据库里，这个需求叫分布式事务，OceanBase用两阶段提交（2PC）来解决。

两阶段提交里有个角色叫协调者（相当于总收银台），参与者是各个分店。第一阶段叫“准备”：协调者问所有参与者“这笔账能不能记？”参与者各自把数据锁住、写入日志，回答“准备好了”。第二阶段叫“提交”：协调者收到所有参与者的“准备好了”后，广播“正式提交”，大家才真正落账。只要有一个参与者回答“不行”，协调者就广播“回滚”，大家把之前的准备全部撤销。

OceanBase还引入了全局时间戳（GTS）来给所有事务拍序号，确保分布式事务的先后顺序和真实时间一致。配合MVCC（多版本并发控制），读操作可以读取某个时间点的快照，读写互不阻塞，隔离级别默认支持“可重复读”。

用超市的话说：收银员不会在所有柜台都点头前就盖章，也不会在某个柜台摇头后还强行结算。这套“全员确认再落账”的机制，保证了顾客无论跨几个柜台，账单永远一致。

分区机制：货架分区的摆放艺术

超市不可能把几亿件商品堆在一个仓库里。它会把商品按品类、按品牌分到不同货架，甚至不同分店。OceanBase也是这么干的：一张数据表被拆成很多个分区（Partition），每个分区是表的一部分数据，各自存储在不同的OBServer上。

常见的分区方式有两种。Range分区：按某个列的范围来切，比如订单表按时间分成“2024年1月分区”“2024年2月分区”，查询某个月的数据时只需要扫对应分区。Hash分区：对主键做哈希运算，然后对分区数取模，把数据均匀打散到各个分区，适合订单号、用户ID这类没有自然顺序的键，能有效避免热点集中在某一个分片。

分区还带来一个巨大好处：水平扩展。当集群压力增大时，不需要换更大的机器，只要增加新的OBServer，RootService就会把部分分区迁移过去。整个过程对应用透明，业务侧完全无感知。

像超市把同一位顾客的订单按用户ID哈希到同一家分店，查询和事务都在本店完成，减少了跨店沟通成本。分区就是OceanBase能“无限扩容”的货架系统。

HTAP能力：零售批发两不误

普通超市只做零售，总部想要一份全集团财报，得等各分店下班后盘货上报，第二天才能出来。OceanBase的"HTAP"就像一家既做零售、又同时给餐厅做批发的超市：同一套门店，既能服务进店顾客，又能随时给大客户出批发报价。

在数据库术语里，TP（事务处理）是零售——大量小额、高频的读写，比如转账、下单；AP（分析处理）是批发——复杂的大查询、聚合统计，比如“上月华东区销售额TOP10”。传统方案是搭一套ETL管道，把交易数据同步到数仓再分析，滞后至少一天。OceanBase则在一套引擎里同时支持两者。

实现上，OceanBase用行存格式服务TP：一行数据连续存放，改一笔快；同时用列存格式服务AP：一列数据连续存放，扫全表做聚合快。数据以两种格式各存一份，通过内部同步机制保持一致。查询优化器会根据SQL类型自动选择行存或列存，应用无感知。

这家“双模式超市”的价值在于：业务方不需要把数据搬来搬去，在交易发生的同时就能看到实时分析结果，风控、运营决策因此从“隔天报表”变成“实时驾驶舱”。

存储引擎：仓库的高效存货法

超市仓库有一套聪明的摆放策略：销量最高的商品放在门口，补货频繁的商品放在最外层，定期把滞销商品推到仓库深处。OceanBase的存储引擎LSM-Tree（Log-Structured Merge Tree）也是这个思路。

传统数据库用B+树，数据写入时要随机修改磁盘上的多个位置，像在仓库里来回搬货，慢。LSM-Tree则先把所有写入都记到一个内存表（MemTable）里，攒够一批后，再以顺序写的方式一次性刷到磁盘。顺序写比随机写快一到两个数量级，相当于超市把补货商品先堆在收货区，凑满一卡车再统一运进仓库。

随着刷盘次数增多，磁盘上会形成多层SSTable（有序数据文件），查询时可能需要查多层文件。为了加速，OceanBase给每个文件建了布隆过滤器（Bloom Filter）：一个紧凑的“可能含有”名单，快速排除不含目标数据的文件，避免无效扫描。同时，数据块采用压缩存储，节省磁盘又加速IO。

LSM-Tree就是OceanBase的“仓储物流系统”：收货区快速收货，仓库按层堆放，门口放提示牌（布隆过滤器）快速找货。这套设计让它在高并发写入场景下依然保持稳定吞吐。

对比与选型：三家超市怎么选

现在市面上有三家著名的“分布式超市”：TiDB、Spanner和OceanBase。理解它们的差异，就像理解沃尔玛、Costco和本地精品超市的区别——各有各的客群和打法。

TiDB是开源的NewSQL代表，采用Raft协议，用Go和Rust开发，社区活跃、文档友好，适合互联网公司快速上手。Spanner是Google的全球分布式数据库，靠GPS原子钟和TrueTime机制实现跨洲强一致，适合谷歌这种全球规模业务，但技术门槛高、不开源。OceanBase从蚂蚁双11的金融场景打磨出来，跑过最严苛的账户、交易类负载，兼容MySQL协议，且开源。

选型建议：金融、政务、运营商这类对数据一致性和可靠性要求极高的核心系统，OceanBase的Paxos和HTAP能力最契合；互联网业务如果追求开源生态和快速迭代，TiDB更顺手；如果业务本身就是全球多活的超大规模，则需要考虑Spanner思路的云原生方案。

没有最好的超市，只有最合适的超市。做选型时，先画出你的业务地图：数据要放在几个城市？对一致性要求多高？团队熟悉哪种生态？答案自然浮现。

---

AI 应用场景

Python 演示

"""模拟 OceanBase 的 Paxos 多数派提交机制"""import random  class PaxosNode:    """模拟一个数据库节点（分店）"""     def __init__(self, node_id):        self.node_id = node_id        self.accepted_value = None        self.available = True     def fail(self):        self.available = False     def recover(self):        self.available = True     def accept(self, value):        if self.available:            self.accepted_value = value            return True        return False  class PaxosCluster:    """模拟一个 5 节点 Paxos 集群"""     def __init__(self, node_count=5):        self.nodes = [PaxosNode(i) for i in range(node_count)]        self.quorum = node_count // 2 + 1     def propose(self, value):        """Leader 发起一次提案，返回 (是否提交, 确认节点列表)"""        votes = []        for node in self.nodes:            if node.accept(value):                votes.append(node.node_id)        committed = len(votes) >= self.quorum        return committed, votes     def kill(self, count):        """按顺序让前 count 个节点宕机"""        for i in range(count):            self.nodes[i].fail()  def run_demo():    cluster = PaxosCluster(5)    cluster.kill(2)    ok, votes = cluster.propose("转账 100 元")    print(f"宕机 2 台后提交结果: {ok}, 确认节点: {votes}")     cluster2 = PaxosCluster(5)    cluster2.kill(3)    ok2, votes2 = cluster2.propose("转账 200 元")    print(f"宕机 3 台后提交结果: {ok2}, 确认节点: {votes2}")  if __name__ == "__main__":    run_demo()

1. self.quorum = node_count // 2 + 1计算法定票数，5节点就是3票。
2. def accept(self, value)节点投票逻辑：只有存活的节点才会接受提案。
3. committed = len(votes) >= self.quorum确认数达到多数派才算提交成功。
4. cluster.kill(2)模拟2台节点宕机后，剩余3台仍能提交。
5. cluster2.kill(3)模拟3台节点宕机后，确认数不足3票，提交失败。

常见误区

面试题