1.一致性选择

Eric Brewer教授的CAP理论指出，在满足分区可容忍性的前提下，一致性和可用性不可兼得。虽然目前大量的互联网项目选择了弱一致性，但我们认为这是底层存储系统，比如MySQL数据库，在大数据量和高并发需求压力之下的无奈选择。弱一致性给应用带来了很多麻烦，比如数据不一致时需要人工订正数据。如果存储系统既能够满足大数据量和高并发的需求，又能够提供强一致性，且硬件成本相差不大，用户将毫不犹豫地选择它。强一致性将大大简化数据库的管理，应用程序也会因此而简化。因此，OceanBase选择支持强一致性和跨行跨表事务。

OccanBase UpdateServer为主备高可用架构，修改操作流程如下：
1)将修改操作的操作日志（redo日志）发送到备机；
2)将修改操作的操作日志写入主机硬盘；
3)将操作日志应用到主机的内存表中；
4)返回客户端写入成功。

OccanBase要求将操作日志同步到主备的情况下才能够返回客户端写入成功，即使主机出现故障，备机自动切换为主机，也能够保证新的主机拥有以前所有的修改操作，严格保证数据不丢失。另外，为了提高可用性，OceanBase还增加了一种机制，如果主机往备机同步操作日志失败，比如备机故障或者主备之间网络故障，主机可以将备机从同步列表中剔除，本地更新成功后就返回客户端写人成功。主机将备机剔除前需要通知RootServer,后续如果主机故障，RootServer能够避免将不同步的备机切换为主机。

OceanBase的高可用机制保证主机、备机以及主备之间网络三者之中的任何一个出现故障都不会对用户产生影响，然而，如果三者之中的两个同时出现故障，系统可用性将受到影响，但仍然保证数据不丢失。如果应用对可用性要求特别高，可以增加备机数量，从而容忍多台机器同时出现故障的情况。

OccanBase主备同步也允许配置为异步模式，支持最终一致性。这种模式一般用来支持异地容灾。例如，用户请求通过杭州主站的机房提供服务，主站的UpdateServer内部有一个同步线程不停地将用户更新操作发送到青岛机房。如果杭州机房整体出现不可恢复的故障，比如地震，还能够通过青岛机房恢复数据并继续提供服务。

另外，OceanBase所有写事务最终都落到UpdateServer，而UpdateServer逻辑上是一个单点，支持跨行跨表事务，实现上借鉴了传统关系数据库的做法。

2.数据结构

OccanBase数据分为基线数据和增量数据两个部分，基线数据分布在多台ChunkServer上，增量数据全部存放在一台UpdateServer上。如图8-5所示，系统中有5个子表，每个子表有3个副本，所有的子表分布到4台ChunkServer上。RootServer中维护了每个子表所在的ChunkServer的位置信息，UpdateServer存储了这5个子表的
增量更新。

不考虑数据复制，基线数据的数据结构如下：

• 每个表格按照主键组成一颗分布式B+树，主键由若干列组成；
• 每个叶子节点包含表格一个前开后闭的主键范围（rk1，rk2]内的数据；
• 每个叶子节点称为一个子表（tablet），包含一个或者多个SSTmble；
• 每个SSTable内部按主键范围有序划分为多个块（block）并内建块索引（block index)；
• 每个块的大小通常在4~64KB之间并内建块内的行索引；
• 数据压缩以块为单位，压缩算法由用户指定并可随时变更；
• 叶子节点可能合并或者分裂；
• 所有叶子节点基本上是均匀的，随机地分布在多台ChunkServer机器上；
• 通常情况下每个叶子节点有2~3个副本；
• 叶子节点是负载平衡和任务调度的基本单元；
• 支持布隆过滤器的过滤。

增量数据的数据结构如下：

• 增量数据按照时间从旧到新划分为多个版本；
• 最新版本的数据为一颗内存中的B+树，称为活跃MemTable；
• 用户的修改操作写入活跃MemTable，到达一定大小后，原有的活跃MemTable
  将被冻结，并开启新的活跃MemTable接受修改操作；
• 冻结的MemTable将以SSTable的形式转储到SSD中持久化；
• 每个SSTable内部按主键范围有序划分为多个块并内建块索引，每个块的大小通常为4~8KB并内建块内行索引，一般不压缩；
• UpdateServer支持主备，增量数据通常为2个副本，每个副本支持RAID1存储。

3.可靠性与可用性

分布式系统需要处理各种故障，例如，软件故障、服务器故障、网络故障、数据中心故障、地震、火灾等。与其他分布式存储系统一样，OceanBase通过冗余的方式保障了高可靠性和高可用性。方法如下所示：

• OccanBase在ChunkServer中保存了基线数据的多个副本。单集群部署时一般会配置3个副本；主备集群部署时一般会配置每个集群2个副本，总共4个副本。
• OceanBase在UpdateServer中保存了增量数据的多个副本。UpdateServer主备模式下主备两台机器各保存一个副本，另外，每台机器都通过软件的方式实现了RAID1，将数据自动复制到多块磁盘，进一步增强了可靠性。
• ChunkServer的多个副本可以同时提供服务。Bigtable以及HBase这样的系统服务节点不冗余，如果服务器出现故障，需要等待其他节点恢复成功才能提供服务，而OccanBase多个ChunkServer的子表副本数据完全一致，可以同时提供服务。
• UpdateServer主备之间为热备，同一时刻只有一台机器为主UpdateServer提供写服务。如果主UpdateServer发生故障，OceanBase能够在几秒中之内（一般为3~5秒）检测到并将服务切换到备机，备机几乎没有预热时间。
• OceanBase存储多个副本并没有带来太多的成本。当前的主流服务器的磁盘容量通常是富余的，例如，300GB×12或600GB×12的服务器有3TB或6TB左右的磁盘总容量，但存储系统单机通常只能服务少得多的数据量。