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逻辑上是一个单点，支持跨行跨表事务，实现上借鉴了传统关系数据库的做法。