《大规模分布式存储系统》第8章OceanBase架构初探【8.4】
8.4 架构剖析8.4.1 一致性选择
Eric Brewer教授的CAP理论指出，在满足分区可容忍性的前提下，一致性和可
用性不可兼得。
虽然目前大量的互联网项目选择了弱一致性，但我们认为这是底层存储系统，
比如MySQL数据库，在大数据量和高并发需求压力之下的无奈选择。弱一致性给应
用带来了很多麻烦，比如数据不一致时需要人工订正数据。如果存储系统既能够满
足大数据量和高并发的需求，又能够提供强一致性，且硬件成本相差不大，用户将
毫不犹豫地选择它。强一致性将大大简化数据库的管理，应用程序也会因此而简
化。因此，OceanBase选择支持强一致性和跨行跨表事务。
OceanBase UpdateServer为主备高可用架构，修改操作流程如下：
1）将修改操作的操作日志（redo日志）发送到备机；
2）将修改操作的操作日志写入主机硬盘；
3）将操作日志应用到主机的内存表中；
4）返回客户端写入成功。
OceanBase要求将操作日志同步到主备的情况下才能够返回客户端写入成功，即
使主机出现故障，备机自动切换为主机，也能够保证新的主机拥有以前所有的修改
操作，严格保证数据不丢失。另外，为了提高可用性，OceanBase还增加了一种机
制，如果主机往备机同步操作日志失败，比如备机故障或者主备之间网络故障，主
机可以将备机从同步列表中剔除，本地更新成功后就返回客户端写入成功。主机将
备机剔除前需要通知RootServer，后续如果主机故障，RootServer能够避免将不同步
的备机切换为主机。
OceanBase的高可用机制保证主机、备机以及主备之间网络三者之中的任何一个
出现故障都不会对用户产生影响，然而，如果三者之中的两个同时出现故障，系统
可用性将受到影响，但仍然保证数据不丢失。如果应用对可用性要求特别高，可以
增加备机数量，从而容忍多台机器同时出现故障的情况。
OceanBase主备同步也允许配置为异步模式，支持最终一致性。这种模式一般用
来支持异地容灾。例如，用户请求通过杭州主站的机房提供服务，主站的
UpdateServer内部有一个同步线程不停地将用户更新操作发送到青岛机房。如果杭州
机房整体出现不可恢复的故障，比如地震，还能够通过青岛机房恢复数据并继续提
供服务。
另外，OceanBase所有写事务最终都落到UpdateServer，而UpdateServer逻辑上是
一个单点，支持跨行跨表事务，实现上借鉴了传统关系数据库的做法。
8.4.2 数据结构
OceanBase数据分为基线数据和增量数据两个部分，基线数据分布在多台
ChunkServer上，增量数据全部存放在一台UpdateServer上。如图8-5所示，系统中有5
个子表，每个子表有3个副本，所有的子表分布到4台ChunkServer上。RootServer中维
护了每个子表所在的ChunkServer的位置信息，UpdateServer存储了这5个子表的增量
更新。
图 8-5 OceanBase数据结构
不考虑数据复制，基线数据的数据结构如下：
●每个表格按照主键组成一颗分布式B+树，主键由若干列组成；
●每个叶子节点包含表格一个前开后闭的主键范围（rk1，rk2]内的数据；
●每个叶子节点称为一个子表（tablet），包含一个或者多个SSTable；
●每个SSTable内部按主键范围有序划分为多个块（block）并内建块索引（block
index）；
●每个块的大小通常在4～64KB之间并内建块内的行索引；
●数据压缩以块为单位，压缩算法由用户指定并可随时变更；
●叶子节点可能合并或者分裂；
●所有叶子节点基本上是均匀的，随机地分布在多台ChunkServer机器上；
●通常情况下每个叶子节点有2～3个副本；
●叶子节点是负载平衡和任务调度的基本单元；
●支持布隆过滤器的过滤。
增量数据的数据结构如下：
●增量数据按照时间从旧到新划分为多个版本；
●最新版本的数据为一颗内存中的B+树，称为活跃MemTable；
●用户的修改操作写入活跃MemTable，到达一定大小后，原有的活跃MemTable
将被冻结，并开启新的活跃MemTable接受修改操作；
●冻结的MemTable将以SSTable的形式转储到SSD中持久化；
●每个SSTable内部按主键范围有序划分为多个块并内建块索引，每个块的大小
通常为4～8KB并内建块内行索引，一般不压缩；
●UpdateServer支持主备，增量数据通常为2个副本，每个副本支持RAID1存储。
8.4.3 可靠性与可用性
分布式系统需要处理各种故障，例如，软件故障、服务器故障、网络故障、数
据中心故障、地震、火灾等。与其他分布式存储系统一样，OceanBase通过冗余的方
式保障了高可靠性和高可用性。方法如下所示：
●OceanBase在ChunkServer中保存了基线数据的多个副本。单集群部署时一般会
配置3个副本；主备集群部署时一般会配置每个集群2个副本，总共4个副本。
●OceanBase在UpdateServer中保存了增量数据的多个副本。UpdateServer主备模
式下主备两台机器各保存一个副本，另外，每台机器都通过软件的方式实现了
RAID1，将数据自动复制到多块磁盘，进一步增强了可靠性。
●ChunkServer的多个副本可以同时提供服务。Bigtable以及HBase这样的系统服务
节点不冗余，如果服务器出现故障，需要等待其他节点恢复成功才能提供服务，而
OceanBase多个ChunkServer的子表副本数据完全一致，可以同时提供服务。
●UpdateServer主备之间为热备，同一时刻只有一台机器为主UpdateServer提供写
服务。如果主UpdateServer发生故障，OceanBase能够在几秒中之内（一般为3～5
秒）检测到并将服务切换到备机，备机几乎没有预热时间。
●OceanBase存储多个副本并没有带来太多的成本。当前的主流服务器的磁盘容
量通常是富余的，例如，300GB×12或600GB×12的服务器有3TB或6TB左右的磁盘总
容量，但存储系统单机通常只能服务少得多的数据量。
8.4.4 读写事务
在OceanBase系统中，用户的读写请求，即读写事务，都发给MergeServer。
MergeServer解析这些读写事务的内容，例如词法和语法分析、schema检查等。对于
只读事务，由MergeServer发给相应的ChunkServer分别执行后再合并每个ChunkServer
的执行结果；对于读写事务，由MergeServer进行预处理后，发送给UpdateServer执
行。
只读事务执行流程如下：
1）MergeServer解析SQL语句，词法分析、语法分析、预处理（schema合法性检
查、权限检查、数据类型检查等），最后生成逻辑执行计划和物理执行计划。
2）如果SQL请求只涉及单张表格，MergeServer将请求拆分后同时发给多台
ChunkServer并发执行，每台ChunkServer将读取的部分结果返回MergeServer，由
MergeServer来执行结果合并。
3）如果SQL请求涉及多张表格，MergeServer还需要执行联表、嵌套查询等操
作。
4）MergeServer将最终结果返回给客户端。
读写事务执行流程如下：
1）与只读事务相同，MergeServer首先解析SQL请求，得到物理执行计划。
2）MergeServer请求ChunkServer获取需要读取的基线数据，并将物理执行计划和
基线数据一起传给UpdateServer。
3）UpdateServer根据物理执行计划执行读写事务，执行过程中需要使用
MergeServer传入的基线数据。
4）UpdateServer返回MergeServer操作成功或者失败，MergeServer接着会把操作
结果返回客户端。
例如，假设某SQL语句为："update t1 set c1=c1+1 where rowkey=1"，即将表格t1
中主键为1的c1列加1，这一行数据存储在ChunkServer中，c1列的值原来为2012。那
么，MergeServer执行SQL时首先从ChunkServer读取主键为1的数据行的c1列，接着将
读取结果（c1=2012）以及SQL语句的物理执行计划一起发送给UpdateServer。
UpdateServer根据物理执行计划将c1加1，即将c1变为2013并记录到内存表
（MemTable）中。当然，更新内存表之前需要记录操作日志。
8.4.5 单点性能
OceanBase架构的优势在于既支持跨行跨表事务，又支持存储服务器线性扩展。
当然，这个架构也有一个明显的缺陷：UpdateServer单点，这个问题限制了
OceanBase集群的整体读写性能。
下面从内存容量、网络、磁盘等几个方面分析UpdateServer的读写性能。其实大
部分数据库每天的修改次数相当有限，只有少数修改比较频繁的数据库才有每天几
亿次的修改次数。另外，数据库平均每次修改涉及的数据量很少，很多时候只有几
十个字节到几百个字节。假设数据库每天更新1亿次，平均每次需要消耗100字节，
每天插入1000万次，平均每次需要消耗1000字节，那么，一天的修改量为：1亿
×100+1000万×1000=20GB，如果内存数据结构膨胀2倍，占用内存只有40GB。而当
前主流的服务器都可以配置96GB内存，一些高档的服务器甚至可以配置192GB、
384GB乃至更多内存。
从上面的分析可以看出，UpdateServer的内存容量一般不会成为瓶颈。然而，服
务器的内存毕竟有限，实际应用中仍然可能出现修改量超出内存的情况。例如，淘
宝双11网购节数据库修改量暴涨，某些特殊应用每天的修改次数特别多或者每次修
改的数据量特别大，DBA数据订正时一次性写入大量数据。为此，UpdateServer设计
实现了几种方式解决内存容量问题，UpdateServer的内存表达到一定大小时，可自动
或者手工冻结并转储到SSD中，另外，OceanBase支持通过定期合并或者数据分发的
方式将UpdateServer的数据分散到集群中所有的ChunkServer机器中，这样不仅避免了
UpdateServer单机数据容量问题，还能够使得读取操作往往只需要访问UpdateServer
内存中的数据，避免访问SSD磁盘，提高了读取性能。
从网络角度看，假设每秒的读取次数为20万次，每次需要从UpdateServer中获取
100字节，那么，读取操作占用的UpdateServer出口带宽为：20万×100=20MB，远远
没有达到千兆网卡带宽上限。另外，UpdateServer还可以配置多块千兆网卡或者万兆
网卡，例如，OceanBase线上集群一般给UpdateServer配置4块千兆网卡。当然，如果
软件层面没有做好，硬件特性将得不到充分发挥。针对UpdateServer全内存、收发的
网络包一般比较小的特点，开发团队对UpdateServer的网络框架做了专门的优化，大
大提高了每秒收发网络包的个数，使得网络不会成为瓶颈。
从磁盘的角度看，数据库事务需要首先将操作日志写入磁盘。如果每次写入都
需要将数据刷入磁盘，而一块SAS磁盘每秒支持的IOPS很难超过300，磁盘将很快成
为瓶颈。为了解决这个问题，UpdateServer在硬件上会配置一块带有缓存模块的RAID
卡，UpdateServer写操作日志只需要写入到RAID卡的缓存模块即可，延时可以控制在
1毫秒之内。RAID卡带电池，如果UpdateServer发生故障，比如机器突然停电，RAID
卡能够确保将缓存中的数据刷入磁盘，不会出现丢数据的情况。另外，UpdateServer
还实现了写事务的成组提交机制，将多个用户写操作凑成一批一次性提交，进一步
减少磁盘IO次数。
8.4.6 SSD支持
磁盘随机IO是存储系统性能的决定因素，传统的SAS盘能够提供的IOPS不超过
300。关系数据库一般采用高速缓存（Buffer Cache） 的方式缓解这个问题，读取操
作将磁盘中的页面缓存到高速缓存中，并通过LRU或者类似的方式淘汰不经常访问
的页面；同样，写入操作也是将数据写入到高速缓存中，由高速缓存按照一定的策
略将内存中页面的内容刷入磁盘。这种方式面临一些问题，例如，Cache冷启动问
题，即数据库刚启动时性能很差，需要将读取流量逐步切入。另外，这种方式不适
合写入特别多的场景。
最近几年，SSD磁盘取得了很大的进展，它不仅提供了非常好的随机读取性能，
功耗也非常低，大有取代传统机械磁盘之势。一块普通的SSD磁盘可以提供35000
IOPS甚至更高，并提供300MB/s或以上的读出带宽。然而，SSD盘的随机写性能并不
理想。这是因为，尽管SSD的读和写以页（page，例如4KB，8KB等）为单位，但
SSD写入前需要首先擦除已有内容，而擦除以块（block）为单位，一个块由若干个
连续的页组成，大小通常在512KB～2MB。假如写入的页有内容，即使只写入一个
字节，SSD也需要擦除整个512KB～2MB大小的块，然后再写入整个页的内容，这就
是SSD的写入放大效应。虽然SSD硬件厂商都针对这个问题做了一些优化，但整体上
看，随机写入不能发挥SSD的优势。
OceanBase设计之初就认为SSD为大势所趋，整个系统设计时完全摒弃了随机
写，除了操作日志总是顺序追加写入到普通SAS盘上，剩下的写请求都是对响应时间
要求不是很高的批量顺序写，SSD盘可以轻松应对，而大量查询请求的随机读，则发
挥了SSD良好的随机读的特性。摒弃随机写，采用批量的顺序写，也使得固态盘的使
用寿命不再成为问题，主流SSD盘使用MLC SSD芯片，而MLC号称可以擦写1万次
（SLC可以擦写10万次，但因成本高而较少使用），即使按最保守的2500次擦写次数
计算，而且每天全部擦写一遍，其使用寿命为2500/365=6.8年。
这个机制在Oracle数据库中称为Buffer Cache，在MySQL数据库中称为Buffer Pool，
用于缓存磁盘中的页面。
8.4.7 数据正确性
数据丢失或者数据错误对于存储系统来说是一种灾难。前面8.4.1节中已经提
到，OceanBase设计为强一致性系统，设计方案上保证不丢数据。然而，TCP协议传
输、磁盘读写都可能出现数据错误，程序Bug则更为常见。为了防止各种因素导致的
数据损毁，OceanBase采取了以下数据校验措施：
●数据存储校验。每个存储记录（通常是几KB到几十KB）同时保存64位CRC校
验码，数据被访问时，重新计算和比对校验码。
●数据传输校验。每个传输记录同时传输64位CRC校验码，数据被接收后，重新
计算和比对校验码。
●数据镜像校验。UpdateServer在机群内有主UpdateServer和备UpdateServer，集
群间有主集群和备集群，这些UpdateServer的内存表（MemTable）必须保持一致。为
此，UpdateServer为MemTable生成一个校验码，MemTable每次更新时，校验码同步
更新并记录在对应的操作日志中。备UpdateServer收到操作日志并重放到MemTable
时，也同步更新MemTable校验码并与接收到的校验码对照。UpdateServer重新启动后
重放日志恢复MemTable时也同步更新MemTable校验码并与保存在每条操作日志中的
校验码对照。
●数据副本校验。定期合并时，新的子表由各个ChunkServer独立地融合旧的子表
中的SSTable与冻结的MemTable而生成，如果发生任何异常或者错误（比如程序
bug），同一子表的多个副本可能不一致，则这种不一致可能随着定期合并而逐步累
积或扩散且很难被发现，即使被察觉，也可能因为需要追溯较长时间而难以定位到
源头。为了防止这种情况出现，ChunkServer在定期合并生成新的子表时，也同时为
每个子表生成一个校验码，并随新子表汇报给RootServer，以便RootServer核对同一
子表不同副本的校验码。
8.4.8 分层结构
OceanBase对外提供的是与关系数据库一样的SQL操作接口，而内部却实现成一
个线性可扩展的分布式系统。系统从逻辑实现上可以分为两个层次：分布式存储引
擎层以及数据库功能层。
OceanBase一期只实现了分布式存储引擎，这个存储引擎支持如下特性：
●支持分布式数据结构，基线数据逻辑上构成一颗分布式B+树，增量数据为内
存中的B+树；
●支持目前OceanBase的所有分布式特性，包括数据分布、负载均衡、主备同
步、容错、自动增加/减少服务器等；
●支持根据主键更新、插入、删除、随机读取一条记录，另外，支持根据主键范
围顺序查找一段范围的记录。
二期的OceanBase版本在分布式存储引擎之上增加了SQL支持：
●支持SQL语言以及MySQL协议，MySQL客户端可以直接访问；
●支持读写事务；
●支持多版本并发控制；
●支持读事务并发执行。
从另外一个角度看，OceanBase融合了分布式存储系统和关系数据库这两种技
术。通过分布式存储技术将基线数据分布到多台ChunkServer，实现数据复制、负载
均衡、服务器故障检测与自动容错，等等；UpdateServer相当于一个高性能的内存数
据库，底层采用关系数据库技术实现。我们后来发现，有一个号称“世界上最快的内
存数据库”MemSQL采用了和OceanBase UpdateServer类似的设计，在拥有64个CPU核
心的服务器上实现了每秒150万次单行写事务。OceanBase相当于
GFS+MemSQL,ChunkServer的实现类似GFS,UpdateServer的实现类似MemSQL，目标是
成为可扩展的、支持每秒百万级单行事务操作的分布式数据库。
后续将分为两章，分别讲述OceanBase分布式存储引擎层以及数据库功能层的实
现细节。
页:
[1]