阿里云官网镜像站：OceanBase、MySQL镜像源

https://developer.aliyun.com/...

概述

OceanBase是阿里巴巴和蚂蚁金服齐全自主研发的通用的分布式关系型数据库，定位为商用企业级数据库。OceanBase能提供金融级别的可靠性，目前次要利用用于金融行业，同时也实用于非金融行业场景。它交融传统关系数据库和分布式系统的劣势，利用一般的PC服务器组成数据库集群，领有杰出的线性扩展性。

通过在底层分布式引擎实现的Paxos多数派协定和多正本个性，OceanBase领有了令人称道的高可用和容灾能力，不负“永不停机”的数据库系统的盛名，能够完满反对多地多活、异地容灾等高可用部署。

OceanBase是一个准内存数据库系统，独有的读写拆散架构和面向SSD固态盘的高效存储引擎，为用户带来了超高性能的体验。

OceanBase定位为云数据库，通过在数据库外部实现多租户隔离，实现一个集群能够服务多个租户，且租户之间齐全隔离，不会相互影响。

OceanBase目前齐全兼容MySQL，用户能够零老本从 MySQL 迁徙到OceanBase。同时OceanBase在数据库外部实现了分区表和二级分区性能，能够齐全取代MySQL罕用的分库分表计划。

OceanBase的存储引擎

OceanBase实质上是一个基线加增量的存储引擎，跟关系数据库差异很大。存储机制是LSM树，这也是大多数NoSQL应用的存储机制。OceanBase采纳了一种读写拆散的架构，把数据分为基线数据和增量数据，其中增量数据放在内存里（MemTable），基线数据放在SSD盘（SSTable）。尽管不是刻意设计的，但OceanBase的确比传统数据库更适宜像双十一、秒杀以及优惠券销售等短时间突发大流量的场景：

短时间内大量用户涌入，短时间内业务流量十分大，数据库系统压力十分大
一段时间（几秒钟、几分钟、或半个小时等）后业务流量迅速或显著回落

OceanBase是“基线数据（硬盘）”+“批改增量（内存）”的架构，如下图所示。

整个数据库以硬盘（通常是SSD）为载体，对数据的批改都是增量数据，只写内存，早先的增、删、改数据（批改增量）在内存，所以DML是齐全的内存操作，性能十分高。而基线数据在保留在硬盘上，因而OceanBase能够看成一个准内存数据库。这样做的益处有：

写事务在内存（除事务日志必须落盘外），性能大大晋升。
没有随机写硬盘，硬盘随机读不受烦扰，高峰期零碎性能晋升显著；对于传统数据库，业务高峰期通常也是大量随机写盘（刷脏页）的高峰期，大量随机写盘耗费了大量的IO，特地是思考到SSD的写入放大，对于读写性能都有较大的影响。
基线数据只读，缓存（cache）简略且成果晋升。

读数据的时候，数据可能会在内存里有更新过的版本，在长久化存储里有基线版本，须要把两个版本进行合并，取得一个最新版本。同时在内存实现了Block Cache和Row cache，来防止对基线数据的随机读。当内存的增量数据达到肯定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘（称为转储，又叫minor freeze）。同时每天晚上的闲暇时刻，零碎也会主动每日合并(简称合并，major freeze)。

OB为何采纳这种非凡架构，简要来说，就是基于这样一条实践根底——只管数据库自身的数据量越来越大，记录数越来越多，但每天的增删改数据量并不大，仅仅只占数据库总量一个很小的比例。这个状况不只是对支付宝的领取数据，对其它大部分数据库理论利用状况也实用，是OB建设上述存储引擎的重要实践根底。

每日合并，必然波及到大量的硬盘读写（IO），因而可能对业务的吞吐量和事务响应工夫（RT）产生影响。如何防止每日合并对业务的影响呢？OceanBase通过“轮转合并”解决了这个问题。

家喻户晓，出于高可用的思考，OceanBase是三机群部署。

依据配置和部署的不同，业务顶峰时能够一个机群、两个机群或者三个机群提供读写服务。OceanBase的轮转合并就是对每个机群轮转地进行每日合并，在对一个机群进行每日合并之前，先把该机群上的业务读写流量切换到另外的一个或两个机群，而后对该机群进行全速的每日合并。

因而在每日合并期间，合并进行中的机群没有业务流量，仅仅接管事务日志并且参加Paxos投票，业务拜访OceanBase的事务响应工夫齐全不受每日合并的影响，仅仅是OceanBase的总吞吐量有所降落：如果先前是三个机群都提供服务则总吞吐量降落1/3，如果先前只有一个或两个机群提供服务则总吞吐量没有变动。

轮转合并使得OceanBase对SSD非常敌对，防止了大量随机写盘对SSD寿命的影响，因而OceanBase能够应用绝对便宜的“读密集型”SSD来代替传统数据库应用的绝对低廉的“读写型”SSD，而不影响性能。此外因为轮转合并对服务器的CPU应用、硬盘IO应用以及耗时长短都不敏感（高峰期的传统数据库在刷脏页的同时还要优先保障业务拜访的吞吐量和事务响应工夫，刷脏页的CPU及IO资源都十分受限），因而OceanBase在每日合并时能够采纳更加高效的压缩或者编码算法（比方压缩或编码速度略慢，但压缩率较高、解压缩很快的算法），从而进一步升高存储老本并晋升性能。

每日合并提供了很多益处，但也须要接受肯定的代价；整体上来说，每日合并会是一个比拟费时的操作，对系统的 IO 和 CPU 会有比拟多的耗费。为了使每日合并应用系统资源对系统带来的影响尽可能的升高，比拟常见的做法是将每日合并的操作放在业务的低峰期间（如夜间时刻）进行。

OceanBase如何保障写的原子性

分布式数据库技术具体难在哪里呢？简略说，要想账头一分钱都不错，数据库要反对事务，事务领有ACID准则，这四个字母别离代表：A原子性、C一致性、I隔离性、D持久性。

原子性：示意事务中的多个操作要么全副实现，要么全副失败，不会呈现中间状态，例如A转给B100块钱，A账户扣除100块的同时，B账户必须减少100块钱。这两件事必须像一个原子一样紧紧抱在一起，决不允许“A曾经扣钱，B还没加钱”的事件产生。
一致性：A转给B100块钱，转账实现的一瞬间，A霎时再查问本人的最新余额，必须显示曾经扣除100之后的金额，B必须霎时查到曾经加上100块之后的余额。所有的账目在任何一个工夫切面必须完完全全对得上。
隔离性：示意多个并发事务之间不相互影响，A转给B100块钱，不能对C有任何影响。
持久性：示意事务一旦胜利就不会失落，A转给B100块钱，这笔转账一旦实现，就永远失效。

其中一致性是目标，原子性隔离性和长久化是伎俩，只有做好ACID中的AID，C天然就能满足。

因为数据散落在多台数据库服务器上，库作了拆分。分布式写最大的难度其实就在于保障ACID中的那个A——原子性。

举个例子，假如A给B转100块钱，因为是“分布式数据库”，A用户的账户数据存在A机器上，B用户的账户数据存在B机器上。

如果交易产生时，负责给A账户扣100块钱的A机器死机,没有扣胜利，而负责给账户B加100块钱的B机器工作失常，加上了100——这就会造成支付宝损失100块。

反之，如果负责给A账户扣100块钱的A机器失常，曾经扣掉100，而负责给账户B加100块钱的B机器死机，100块没加上，那么用户就会损失100——最初支付宝还要抵偿用户100块。

为了保障以上这两种难堪的场面不产生，OceanBase 1.0 采纳了整整一组技术，但最次要的是两个。

投票机制

数据库采纳“三正本”，也就是任何一个账户，都有一个主咖两个备胎共三份雷同的数据。

举例来说：账户A的数据肯定同时存在三台机器上。转账时，至多两台机器执行结束才算转账实现，这意味着，三台机器里有一台坏掉，并不影响转账的执行。同时，三台机器之间互相实时发送“心跳信号”，如果有一台机器挂了，其余两台马上就能感觉到，解决完手头这个交易后，马上向零碎发送警报，零碎主动为他俩匹配一个新搭档，三台机器持续工作。而换下来那个坏机器，交给技术人员培修，修好后从新上架成为备用机器，期待进入战斗序列。

也就是说，除非两台机器在同年同月同日同分同秒同毫秒坏掉，否则数据库的工作不受影响。

即便是这还不够，在要害的节点，OceanBase 会采纳五个节点投票。也就是除非三台机器在同年同月同日同分同秒同毫秒坏掉，否则数据库的工作不受影响。这个概率曾经低到尘土里了。

oceanBase在存储层，通过分区级Paxos日志同步实现高可用和主动扩大，反对灵便的存储架构，包含本地存储，以及存储计算拆散。经典集中式数据库往往采纳主备同步计划，有两种同步模式：第一种是强同步，每个事务操作都须要强同步到备机才能够应答用户，这种形式可能做到服务器故障不丢数据，但必须停服务，无奈保障可用性；另外一种是异步，每个事务操作只须要在主机胜利就能够应答用户，这种形式可能做到高可用，但主库和备库之间数据不统一，备库切换为主库之后会丢数据。

强统一和高可用作为数据库最重要的两个个性，在主备同步模式下，鱼和熊掌不可兼得。Paxos是一种基于多数派的分布式投票协定，每个事务须要胜利写入超过一半服务器才能够应答用户。俗话说得好，“三个臭皮匠顶过一个诸葛亮”，假如总共有3台服务器，每个事务操作要求至多在2台服务器上胜利，无论任何一台服务器产生故障，零碎中还有1台蕴含了全副数据的服务器可能失常工作，从而做到齐全不丢数据，并在30秒之内选出新的主库复原服务，RPO等于0，RTO小于 30秒。所有保障RPO=0的协定都是Paxos协定或者Paxos协定的变种，Raft协定就是其中之一。

监督机制

监督机制其实是对两阶段提交协定（2PC）的实际，认真想想，除了机器坏掉，还有一些状况会毁坏交易的原子性。

例如：A账户要扣掉100块，然而它的余额只有90块，或者曾经达到了明天的转账限额，这种状况下，如果贸然给B账户加了100块，A账户却不够扣，就会陷入麻烦了。

反之如果B账户状态有异样，不能加100块，同样会有麻烦。解决这个问题的办法，就是引入一位“裁判员”。裁判员站在A账户和B账户旁边，它的工作流程是这样的：

裁判员问A账户：你的三台机器都没问题吧？A账户说：没问题。
裁判员问A账户：你的账户容许扣100吗？A账户说：容许。
裁判员问B账户：你的三台机器都没问题吧？B账户说：没问题。
裁判员问B账户：你的账户状态能承受加100吗？B说：容许。
这时，裁判员吹哨，A、B账户同时解冻。
A扣100，B加100，单方向裁判汇报“胜利”。
裁判员再吹哨，A、B账户同时冻结。

以上7步，都是按工夫程序实现的，卡在任何一步，账目都不会乱，一分钱都不会丢。完全符合“原子化”的要求。

裁判员充当2PC中的协调器角色。

OceanBase如何保障事务的隔离性

数据库系统不能只服务一个用户，须要容许多个用户同时操作数据，即并发。所以须要保障多个并发事务的隔离，这里波及到并发控制技术，常见的并发管制办法有基于锁的并发管制（Lock based Concurrency Controll）和多版本并发管制（Multiple version Concurrency Controll）

基于锁的并发管制

数据库系统对用户在事务过程中操作的每一行数据都加锁，读操作加读锁，写操作加写锁。读写阻塞，写写阻塞。如果两个不同的事务试图批改同一行数据，事务1先加上写锁失常执行，事务2就只能阻塞期待，当事务1执行完结开释写锁后，事务2再继续执行。

以转账操作为例，A账户有100元，B账户有200元，如果事务1执行从A账户转10元到B账户，那么在事务1执行过程中，A B两行账户数据都会被加上写锁。如果事务2执行另一次转账操作，从A账户转50元到B账户，那么给A加写锁时失败，事务2会始终期待直到加写锁胜利为止。

如果在事务1与事务2的执行过程中，又来一个事务3想要查问A B两个账户的余额总和，那么须要读取A B两行，读之前要先加读锁，然而在事务1和事务2操作时，读锁加不胜利，那么事务3就须要期待事务1和事务2都完结了能力执行。

多版本的并发管制

在下面例子中，一个读取A B两账户余额总和的操作，无论事务1和事务2是否执行实现，其后果都是确定的（300元）。但基于锁的并发管制，读写是阻塞的，极大的升高了数据库的并发性能，所以呈现了MVCC的办法来做并发管制。对于数据库的数据，每次批改都保留历史版本，这样读操作能够间接在历史版本上执行，不会被写操作阻塞。

在 MVCC 办法下，每一个事务都会有一个提交版本，持续下面事务三的例子。假如数据的初始版本是98，假设事务1是的版本号100，事务2是101。那么批改都实现后，数据库中的数据状态如下：

每次数据批改的记录都会被串联起来。另有一个全局变量 Global Committed Version(GCV) 标示全局最初提交的版本号。在事务1执行之前GCV是98，事务1提交之后GCV变成100，事务二提交之后GCV变成101。所以，当事务3开始执行时，先获取GCV，而后依据这个版本号去读相应的数据。

MVCC的批改操作仍然会依赖下面提到的锁机制，所以写操作之间的抵触仍然须要期待。然而MVCC最大的劣势就是读操作与写操作齐全隔离开，相互不影响。对于数据库的性能和并发能力晋升十分无益。

OceanBase应用的计划

应用MVCC计划时GCV的批改须要顺次递增，如果GCV被批改成了101，示意101及之前的所有事务都提交了。OceanBase应用了分布式事务后，这个保障变得艰难，例如，版本号为100的事务可能是分布式事务，101可能是单机事务，分布式事务的提交过程要显著长于单机事务。后果，版本号101的事务先实现，GCV就被批改成了101。然而此时版本号为100事务还在提交过程中，并不能被读取。

所以，OceanBase采纳了MVCC和Lock-based联合的形式，读取操作先获取GCV，而后依照这个版本号读取每一行数据。如果这行数据上没有批改，或者有批改然而批改的版本号会大于GCV，那么这行数据能够间接依照版本号读取。如果这行数据上有一个正在提交中事务，并且版本号有可能小于读取应用的版本号，那么读取操作就须要期待这个事务完结，就如同Lock-based计划中读锁期待写锁一样。然而，这个产生的概率极低，所以整体的性能还是像 MVCC一样好。

OceanBase的高可用

高可用是数据库的根本需要之一，传统数据库容许通过日志同步实现主备镜像；然而，因为主备镜像中主库与备库无奈齐全同步，因而传统数据库的高可用其实是建设在传统的高牢靠服务器和高牢靠共享存储之上的。

OceanBase同样应用性价比较高、可靠性略低的服务器，但同一数据保留在多台（>=3）服务器中的半数以上服务器上（例如3台中的2台，5台中的3台等），每一笔写事务也必须达到半数以上服务器才失效，因而当多数服务器故障时不会有任何数据失落。不仅如此，传统数据库主备镜像在主库产生故障时，通常须要内部工具或人工把备库升级成主库，而OceanBase底层实现了Paxos高可用协定，在主库故障后，残余的服务器会很快主动选举出新的主库，并持续提供服务，OceanBase数据库能做到主动切换且齐全不丢数据。

OceanBase与MySQL的比拟

1、 OB的redo log是应用分布式一致性算法paxos实现的。所以在CAP实践中，尽管OB应用的是强统一模型，然而OB能在肯定网络分区的状况下做到高可用（艰深点讲就是多余半数机器还活着的时候就能干活），官网的MySQL目前做不到这一点。

2、OB的存储构造应用的是两级的LSM tree。其中内存中的C0 Btree叶节点不须要和磁盘上的btree一样大小，所以能做得比拟小，对CPU的Cache比拟敌对，并且不会有写入放大的问题。使得OB的写性能有极大的晋升。同时磁盘上的C1 tree不是一个传统意义上的Btree（Btree未经压缩可能节约一半空间）。空间利用率大大提高。简略来说就是速度快，省老本。

3、数据库主动分片性能（反对hash/range，一级二级等等分片形式），提供独立的proxy路由写入查问等操作到对应的分片。这意味着数据量再大也不须要手动分库分表了。并且分片能在线的在各个server之间迁徙，解决热点问题（资源分配不均的问题，做到弹性加机器和减机器）。每个分片（确切的说是被选为主的分片）都反对读写，做到多点写入（高吞吐量，性能可线性扩大）。

4、数据库外部实现的无阻塞的两阶段提交（跨机事务）。

5、数据库原生的多租户反对，能间接隔离租户之间的cpu、mem、io等资源。

6、高可用，对OceanBase而言，同一数据保留在多台（>=3）台服务器中的半数以上服务器上（例如3台中的2台），每一笔写事务也必须达到半数以上服务器才失效，因而当多数服务器故障时不会有任何数据失落，可能做到RPO等于零。不仅如此，OceanBase底层实现的Paxos高可用协定，在主库故障后，残余的服务器会很快主动选举出新的主库，实现主动切换，并持续提供服务，在理论的生产零碎中做到RTO在20秒之内。

7、扩大能力。MySQL在数据库中间件的帮忙下，能够通过分库分表来实现程度扩大。这种计划解决了传统数据库须要垂直扩大的通病，但还是存在相当的局限性，比方扩容和缩容艰难、无奈反对全局索引，数据一致性难以保障等。OceanBase则从数据库层面提供了真正意义上的程度扩大能力。OceanBase基于分布式系统实现，能够很不便地进行扩容和缩容，且能做到用户无感知。同时，OceanBase所具备的集群内动静负载平衡、多机分布式查问、全局索引的能力更进一步增强了其可扩展性。对于用户的分库分表计划，OceanBase提供了分区表和二级分区的性能，能够齐全取而代之。

原文链接：https://blog.csdn.net/fuzhong...