OceanBase详解

OceanBase是阿里开发的分布式关系型(SQL)数据库，其目标是支持数百TB的数据量以及数十万TPS、数百万QPS的访问量，无论是数据量还是访问量，即使采用非常昂贵的小型机甚至是大型机，单台关系数据库系统都无法承受。

案例：OceanBase分布式关系数据库渡过了一个成功的双十一：支持了支付宝核心的交易、支付、会员和账务等，并且创造了新的纪录：交易创建17.5万笔/秒、交易支付12万笔/秒、全天累计支付10.5亿笔

1、特性

1.1、高扩展性
传统关系型数据库，比如Oracle或者MySQL功能已经很完善，但数据库本身不可扩展，随着数据量的增大和业务内容的丰富，需要拆库拆表，然后再进行访问路由，将相应的SQL解析路由到指定的数据库中。数据库的运维人员需要花费大量的时间来做数据库扩容，包括读写分离、垂直拆分、水平拆分等等。
OceanBase使用了分布式技术和无共享架构，来自业务的访问会自动分散到多台数据库主机上。在相关技术的支持下，OceanBase还能够采用廉价的PC服务器作为其数据库主机。通过这两个方面的变革，运维人员可以愉快地通过增加服务器数量来增加系统的容量和性能。

1.2、低成本
传统商业企业采用的“IOE”体系，实际上代表了一种高成本、高维护费、非高并发的商用数据库系统。特别是随着数据越来越大，所需要付出的升级硬件和维护的代价也会越来越惊人，阿里巴巴采用数据切分的策略，将部分海量数据应用从集中式Oracle切换到分布式集群，从纵向扩展到水平扩展，解决了数据库扩展性的问题，并用PC服务器替换了小型机。
由此带来的一个重要变革，就是成本的极大降低。与传统数据库公司的产品相比，OceanBase的升级维护不需要昂贵的共享存储、高可靠的服务器、数据库软件的许可费，可以将商业数据库成本降到一半以下。

1.3、高可靠性
数据库系统通常由数据库软件、运行数据库软件的数据库服务器硬件以及保存数据库数据的数据库存储硬件(即共享存储)组成。数据库系统的稳定可靠，也取决于这三个部分。使用PC服务器能够带来高扩展性、降低成本的同时，其硬件的可靠性却对应有些下降。
如何保证系统的可靠性？OceanBase的一个基本假设就是硬件(服务器、存储、网络等)是不可靠的，因此，OceanBase必须保证任何时刻出现的少量硬件(服务器、存储、网络等)异常不影响业务。

为此，OceanBase引入了Paxos协议，每一笔事务，主库执行完成后，要同步到半数以上库(包括主库自身)，例如3个库中的2个库，或者5个库中的3个库，事务才成功。这样，少数库(例如3个库中的1个库，或者5个库中的2个库)异常后业务并不受影响。
分布式事务一致性协议paxos主要用于保证一个数据在分布式系统里是可靠的。当在机器里多数派都成功了之后，只要坏的机器是少数派，三个里少数派是一个，多数派是两个。三个机器里面有两个成功了，那就可以告诉用户这个数据保证不会丢了。这个时候机可能会损坏，但是损坏任何一台机器，至少还有另外一台机器恢复过来，这是在系统内部自动去做容灾。任何一台机器坏了，或者有一台机器落后，比如三个及其是一主拖着另外两个成功了之后，就会把数据补上，肯定会保证另外两份是OK的，最终三份是OK了，坏一台机器都不会有问题。

软件层面，OceanBase区别于传统数据库的一个关键特征是软件版本的灰度升级。
主备方式的传统数据库是“单活”的，只有主库可执行写事务，尽管维护升级时可以先操作备库，操作完成后备库变成主库并且接受用户访问是一步到位的，如果新版本有问题，则业务受到影响：

传统数据库：升级前

传统数据库：升级中

传统数据库：升级后只能一次性地引入全部读写流量
OceanBase则是“多活”设计，即多个库（3个，5个等）每个都可以有部分读写流量，升级时先把要升级的库的读写流量切走，升级后先进行数据对比，正常后逐步引入读写流量，一切正常并运行一段时间后再升级其他的库：

OceanBase之3机群(3库)部署：升级前

OceanBase之3机群(3库)部署：切走读写流量，准备升级

OceanBase之3机群(3库)部署：升级一个机群(库)

OceanBase之3机群(3库)部署：升级一个机群(库)后切回全部读写流量

基于硬件不可靠的假设并且能够容忍少量服务器的故障，OceanBase使用了相对廉价的PC服务器代替高可靠服务器并且不再使用昂贵的共享存储，从而不仅提供了比使用高可靠服务器和共享存储低得多的成本，容忍少数服务器乃至少数机群故障意味着比传统数据库更高的可靠性。
通过灰度升级，OceanBase避免了传统数据库的“一锤子买卖”的升级，极大地降低了数据库维护升级的风险。

1.4、数据准确性
许多的互联网服务可以允许有一定的数据差错，但是电子商务(如交易、金融领域等)与一般的互联网公司不太一样，它对于数据的一致性要求非常高，比如要确保钱的进入与流出要对得上账，不能丢失任何一条支付数据（阿里巴巴将OceanBase用于支付宝系统）。
OceanBase设计与经典关系数据库有所不同，其读事务基本是分布式并发执行的，写事务目前是集中式串行执行的，即serializable，且任何一个写事务在commit之前对其他读写事务都是不可见的，因此OceanBase是强一致的。这样，在设计方案上能够保证不丢数据。
几种常见的一致性类型有：
强一致性：系统中的某个数据被成功更新(事务成功返回)后，后续任何对该数据的读取操作都得到更新后的值。这是传统关系数据库提供的一致性模型，也是关系数据库深受人们喜爱的原因之一。
弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作得到的不一定是更新后的值，这种情况下通常有个“不一致性时间窗口”(inconsistency window)存在：即数据更新完成后在经过这个“不一致性时间窗口”，后续读取操作就能够得到更新后的值。
最终一致性：属于弱一致性的一种，即某个数据被更新后，如果该数据后续没有被再次更新，那么最终所有的读取操作都会返回更新后的值。（如果主备库数据同步存在时间差，一旦主机出现异常，恢复无法实时进行，同样有可能会出现数据一致性问题）

如图，上述三个机群构成一个数据库，其中一个是主机群，所有事务都由主机群的UpdateServer(称为主UpdateServer，其他UpdateServer称为备UpdateServer)执行，事务的redo log同步到3个UpdateServer中的超过半数(即至少2个，包括主UpdateServer自己)，则事务成功并应答客户。由于集群中只有一台主UpdateServer提供写服务，因此，OceanBase也很容易地实现了跨行跨表事务。
如果3个UpdateServer中有一个故障： *主UpdateServer故障：剩余的两个UpdateServer会自动选举出一个新的主UpdateServer(参见后文“OceanBase分布式选举的实现”)，由于旧的主UpdateServer数据至少在一个活着的UpdateServer中存在，因此数据不会有任何丢失，两个活着的UpdateServer经过很短时间(通常是毫秒级)的相互同步后就可以继续对外服务，保证了数据的一致性和服务的高可用。 *单个备UpdateServer故障：主UpdateServer有全部数据，剩余两个UpdateServer仍然超过半数，数据一致性和服务都不受任何影响。
（如果把上述三个机群部署出于三个不同的机房，那么即使一个机房出现电源、网络或者空调等故障，剩余两个机群仍然能够继续工作，数据一致性和服务可靠性都不受影响。）
然而，TCP协议传输、磁盘读写都可能出现数据错误，程序Bug则更为常见。为了防止各种因素导致的数据损毁，OceanBase采取了以下数据校验措施：
数据存储校验。每个存储记录（通常是几KB到几十KB）同时保存64位CRC校验码，数据被访问时，重新计算和比对校验码。
数据传输校验。每个传输记录同时传输64位CRC校验码，数据被接收后，重新计算和比对校验码。
数据镜像校验。UpdateServer在机群内有主UpdateServer和备UpdateServer，集群间有主集群和备集群，这些UpdateServer的内存表（MemTable）必须保持一致。为此，UpdateServer为MemTable生成一个校验码，MemTable每次更新