今天聊聊OceanBase（以下简称“OB”）的架构演进，在此之前先了解一下OB的发展历程。OB最早是2010年由创始人阳振坤带团队启动的项目，最早应用于淘宝的收藏夹业务，当时还是一个NoSQL数据库。在2012年后，OB又支持了标准SQL，使得它回归到一个通用的关系型数据库。2014年的时候，OB进入支付宝，开始应用于金融业务，例如当年的”双11”大促活动OB就承担了部分交易量。到了2016年，OB的架构做了一个较大的变化，形成了1.0版本，之后几年又在这个架构下进行了多个版本的迭代。一直到2022年，OB发布4.0版本，主打一个单机分布式一体化。整体的版本演进路线如下图所示。
 |
OB架构的演变，也是在业务应用过程中不断改进的结果。从早期的版本到如今的4.x版本，主要的架构可以分为三类：0.5版本架构、1.x~3.x版本架构以及4.x版本架构。
一．OceanBase
0.5版本架构
OceanBase 0.5版本中，主要包括4个组件：ChunkServer、UpdateServer、MergeServer和RootServer。
ChunkServer。存储基线数据。它将表分为分片（Tablet），每个分片有多个副本。它不接受直接的数据写入，数据写入由UpdateServer负责。
UpdateServer。存储增量数据。所有的写入都会发送给它。它是一个Paxos组，其中一个是Leader，其他为Follower。只有Leader才会接受写服务，Leader故障后从Follower中重新选举Leader继续服务。
MergeServer。接收SQL请求并转换为读或写操作。读取数据时，首先访问ChunkServer，ChunkServer去UpdateServer上将相关的增量数据读到，合并起来返回给MergeServer。
RootServer。管理集群所有节点，Tablet数据分布及副本管理。主备强同步。
 |
可以看出，0.5版本架构中，MergeServer充当计算引擎层，UpdateServer+ChunkServer充当存储引擎层，而RootServer充当集群管理层。UpdateServer上的增量数据+ChunkServer上的基线数据，在后续的OB版本中演变为一个两层的LSM Tree结构。在扩展性上，扩展读性能只需要增加MergeServer、ChunkServer，而写是一个单点写，因为始终只有一个UpdateServer的Leader在工作。
二．OceanBase
1.x-3.x版本架构
如上所述，OB 0.5版本存在最大的问题是单点写入，单点写入的好处是避免了分布式事务的实现，不足之处是导致高并发写入时的性能瓶颈。为了解决这个写入扩展性问题，OB在1.0版本中便进行了重构，采用了对等节点架构，并且实现了分布式事务。
对等节点架构中每个节点都是完全对等的，都包含SQL引擎、存储引擎和事务处理模块。数据仍然是按分区Tablet拆分，每个Tablet是一个Paxos组，由于数据库中包含很多个不同的Tablet，因此称为multi-Paxos。在这个架构上，Leader是分散在不同的OBServer上的，因此每个节点都可以承接读写操作，从而解决了单点写入的问题。
 |
1.x-3.x架构除了是一个对等节点架构以外，它还具有单机低延时和多机低时延的特性。OB在这个架构之下针对事务提交机制做了大量优化，比如：
（1）对于单分区事务，直接使用一阶段提交；对于单节点多分区，将两阶段优化为一阶段提交，多个分区的日志合并落盘。
（2）对于多节点多分区，采用参与者即协调者的优化，协调者不需要写日志，协调者无状态。
（3）通过Partition Group功能，将一阶段提交优化为单PG提交。由写多条日志变为写一条日志。
三．OceanBase
4.x 版本架构
虽然OB的1.x-3.x架构通过对等节点架构解决了单点写入的瓶颈问题，但它仍然存在一些问题。由于集群中通常会包含很多Tablet，每个Tablet是一个单独的Paxos组，他们各自都有自己的一个日志复制流。当分区数变的很大时，底层的IO压力也会很大，对内存的消耗也会很大（因为增量数据都是存放在内存中）。因此，这个架构的版本很难部署在小型的单机系统。在OB 4.0版本中，将事务提交单位和数据迁移单位拆分开来，单机上所有分区的事务日志统一到一个日志流当中。
 |
这在OB新版本中称为“自适应日志流”，它是一种融合服务器静态日志流（如MySQL、PostgreSQL）与分区级静态日志流（如CockroachDB）的方案：当系统处于稳定状态时，每台服务器的日志流数量是固定的，但发生迁移时支持将一个分区从一个日志流迁移到另外一个日志流。自适应日志流的优势是一方面大幅降低日志IO的并发冲突，另一方面降低了选举的开销，从原来的分区级降低为单机日志流级。
总结一下，OB从0.5到如今的4.x版本经历了两个主要的架构调整，从0.5到1.x的调整主要是解决单点写入的问题从而提升写入的扩展能力，从3.x到4.x的调整主要是解决单机分布式一体化的问题从而实现更高小资源的部署能力以及更高的性能。
