阳振坤的博客

海量数据时代的到来正在颠覆人们的许多固有观念，例如网络带宽从10Mb/s到100Mb/s乃至1Gb/s和10Gb/s，网络传输的数据量越来越大，基于16位CRC校验的TCP传输可能未必有想象中的那么可靠；磁盘容量越来越大，今天TB级容量磁盘已经普遍使用，存储的数据越来越多，每时每刻访问的数据量越来越大，不知不觉中读到错误数据的可能性也越来越大。更为严重的是，数据正确性在各种各样的软件bug面前更是脆弱无比，不堪一击。

为了防止各种因素导致的数据损毁，OceanBase采取了以下数据校验措施：

• 数据存储校验：每个存储记录(通常是几个KB到几十KB)同时保存64位CRC校验码，数据被访问时，重新计算和比对校验码；
• 数据传输校验：每个传输记录同时传输64位CRC校验码，数据被接收后，重新计算和比对校验码；
• 数据镜像校验：UpdateServer在机群内有主UpdateServer和备UpdateServer，机群间有主机群和备机群，这些UpdateServer的内存表(memtable)必须保持一致。为此，UpdateServer为memtable生成一个校验码，memtable每次更新时，校验码同步更新并记录在对应的commit log中。备UpdateServer收到commit log重放更新memtable时，也同

作为最基础的服务设施之一，数据库必须有非常高的稳定性和可靠性。与经济型的低端服务器相比，中高端服务器通过硬件的冗余和部件热插拔等提供了更高的稳定性和可靠性，比较重要的数据库应用通常也选择这些更加稳定可靠、当然也更加昂贵的服务器。

然而，除了服务器自身硬件之外，许多其他的人为和环境的因素也可能导致服务的中断：

• 软件故障；
• 网络故障；
• 电力故障；
• 数据中心/机房的各种故障；
• 地震、水灾、火灾等；

此外，中高端服务器，虽然可靠性高于低端服务器，仍然可能出现故障，只是概率更低一些。事实上，随着机器数量增加，无论多么可靠的服务器都会出现故障。因此，一些比较关键的数据库应用，除了采用可靠性较高的中高端服务器之外，还不得不通过双机热备(镜像)等手段进一步提高可靠性。

中高端服务器的主要优势在于它们的可靠性(包括硬件的冗余和热插拔等)，其实它们的性价比并不高，双机热备(镜像)则进一步降低了整个系统的性价比。比较而言，低端的经济型服务器的性价比要好得多。

当前云计算技术已经

OceanBase用增量方式保存数据库的修改，为了避免增量数据无限制增长，增量数据需要合并到基线数据。OceanBase有三种途径来触发这种合并：

• 定时触发：OceanBase自动执行，通常设置在业务的低峰期，例如后半夜，每天一次或几次，定时自动执行；
• 手动触发：由DBA(一般通过脚本)进行，与定时触发类似；
• 定量触发：增量数据到一定量后自动触发；

缺省是每天凌晨1:00定时触发，每天一次，所以这种合并被称为每日合并。

每日合并开始时，Update冻结当前的内存表(frozen memtable)并同时开启新的内存表(new memtable)：

图13.1

此后的所有修改都写入新memtable，frozen memtable则在随后被用于

由于只有主UpdateServer才能接受写入，并且首选以内存来记录数据库在一段时间(例如一天)内的修改，因此UpdateServer单机的写入容量也可能成为整个系统的瓶颈。

其实大部分数据库每天的修改次数相当有限，只有少数修改非常频繁的数据库才有每天几亿次的修改次数，此外，数据库平均每次修改涉及的数据量很小，很多时候只有几个字节到几十个字节。

假设数据库一天修改5亿次，平均每次修改需要消耗100字节，那么一天的修改量就是：5亿×100B = 50GB，而当前主流的PC服务器，许多可以配置96GB内存，高档一些的服务器，甚至可以配置192GB，384GB乃至更多内存。

然而，服务器的内存毕竟有限，实际应用中仍然可能出现修改量超出UpdateServer内存的情况：

• 一些特别日子(例如淘宝双11、双12大促销)数据库修改量可能暴增；
• 某些特殊应用每天修改次数特别多，或者每次修改数据量非常大(例如几KB甚至十几KB)；
• DBA对数据库进行订正，可能涉及几十亿乃至几百亿条记录…..

为此，UpdateServer设计实现了几种方式解决上述问题：

• UpdateS

单一UpdateServer使得OceanBase避免了复杂的分布式事务，极大了简化了OceanBase的设计、实现、调试和测试等环节，然而，单一的UpdateServer也容易成为整个系统的性能和容量的瓶颈。由于ChunkServer和MergeServer可以轻松增加，多个UpdateServer备机均可提供读服务，但只有主UpdateServer才能接受写入，因此单机的写入性能可能成为整个系统的瓶颈。

范围查询是数据库最基本、最常用的功能之一，同时UpdateServer必须支持动态修改，因此UpdateServer使用了数据库普遍采用的B树保存修改增量。基于Copy-on-write的B树是UpdateServer十分关键的数据结构：

图11.1

以上图为例，假设要修改节点E的内容，B树的修改步

为了抵御机房部分停电甚至全部停电等故障，进一步提升OceanBase的可用性，OceanBase还实现了主备机群：即一个应用可以允许有一主一备(甚至一主多备)两个(多个)机群，主机群接受客户端的写入并自动同步到备机群，主机群故障后备机群可以升级为主机群以便继续提供服务。

主备机群间的RootServer和UpdateServer的同步类似于机群内的主备RootServer和UpdateServer的同步，不同的是，主备机群间的RootServer和UpdateServer的同步允许实时和准实时模式。在实时同步模式下，主机群的RootServer和UpdateServer要等待备机群的RootServer和UpdateServer的应答，适用于两个机群之间的网络的round trip时间较短，比如两个机群在同一机房或者在同城的两个机房，其间的网络延时一般小于一毫秒；准实时模式下，主机群的RootServer和UpdateServer不等待机群的RootServer和UpdateServer的应答，适用于两个机群之间的网络的round trip时间较长，比如主备机群在两个不同的城市，其间的网络延时达到几十毫秒甚至更长。

OceanBase的主备机群也是active-active模式，即主备机群可以同时对外提供查询服务(但只有主机群可以接受写入)，DBA可以随时调

数据库是重要的基础服务，通常需要保证7×24小时可用。UpdateServer既是单点，又是整个OceanBase的关键节点，几乎所有读写请求都需要访问它，因此必须保证UpdateServer7×24小时可用，避免因为UpdateServer故障，例如服务器、网络或者人为故障等，导致整个OceanBase数据库服务不可用。

为了避免单点失效，OceanBase为UpdateServer设计了主备结构：UpdateServer可以配置成单机运行，也可以配置成一主一备(master-slave)甚至一主多备运行。主备模式运行时，一旦主UpdateServer异常，备UpdateServer(或其中之一)就实时升级为主，保证服务的持续性。

数据库系统普遍使用主备模式来提升可用性。主备模式的关键是保证主备的实时同步，否则可能导致主库最后的若干条修改丢失，客户端出现幻读(Phantom Reads)，例如：

1. 主库修改了账户A，B，C的信息并应答了客户端；
2. 客户端读到账户A，B和C的修改后的信息；
3. 由于主备之间不实时同步，账户A，B和C的修改没有立刻同步到备库；
4. 主库宕机，备库成为主；
5. 客户端再次访问数据库，此时新的主库中并没有账号A，B和C最后的修改，因

在OceanBase系统中，客户的读写请求，即读写事务，都发给MergeServer(早期版本中写事务直接发给UpdateServer)。MergeServer解释分析这些读写事务的内容，例如词法和语法分析检查等。只读的事务，由MergeServer执行并应答客户端；非只读的事务，即写事务，由MergeServer进行预处理后，发送给UpdateServer执行，UpdateServer执行后应答MergeServer，MergeServer进行必要的处理后应答客户端。

只读事务需要融合UpdateServer上的最新修改，因此MergeServer首先从相关的ChunkServer获得基线数据，然后从UpdateServer获得修改增量并融合到基线数据中形成最新数据。对于每个读事务，MergeServer首次请求UpdateServer时，UpdateServer会返回当前最新修改的快照的句柄，后续在同一读事务中如果MergeServer需要再次或多次访问UpdateServer，它就带上这个快照句柄，这样不论UpdateServer后续发生了什么修改，都不会影响MergeServer当前的读事务。极端情况下，例如整个数据库回滚到过去某个时刻，相应的快照句柄已经失效，则UpdateServer将返回错误，读事务失败。此外，如果某个MergeServer发生故障，导致其所获得的UpdateServer上的快照句柄无法释放，则这些快

就像在“系统架构(一)”提到的，只有分布式架构才能支撑当前和未来越来越庞大的数据量和访问量，同时OceanBase还必须支持跨行跨表事务，看起来OceanBase似乎需要实现分布式事务。

然而，分布式事务不仅实现复杂，更重要的是它尚未在工业界得到广泛应用，其效率和性能等还有待更多生产实践的检验。

仔细分析诸多业务发现，尽快很多数据库系统数据量十分庞大，例如几十亿、几百亿条甚至更多，但一段时间(例如一天)的修改量并不大，通常不超过几千万条到几亿条，因此OceanBase决定使用单台服务器(称为UpdateServer)来记录这段时间(例如一天)的修改增量，并以内存表(memtable)为主，SSD(固态盘)为辅。修改增量之外的、在此段时间内保持不变的数据称为基线数据。基线数据以类似于分布式文件系统的方式存储于多台服务器(称为ChunkServer)上，每次查询都由Merger