贴士：这是我的OceanBase摘录笔记，文中都是通过百度搜索的资料，我觉得好的案例就留下了。最底下有一些链接来源，可以看原作者的文章。

OceanBase是阿里集团研发的可扩展关系型数据库。2015年4月2日，蚂蚁金服方面宣布，蚂蚁金服及阿里巴巴自主研发的通用关系数据库OceanBase已经开始支撑淘宝、天猫和聚划算的所有日常交易。

开始的OceanBase是应用于淘宝收藏夹数据库，用于存储淘宝用户收藏条目和具体的商品、店铺信息，每天支持4～5千万的更新操作。

淘宝海量数据库之一：来自业务的挑战

数据目标：数百TB数据量、数十万TPS、数百万QPS。

小贴士：TPS=服务器每秒处理的事务数；QPS=每秒的响应请求数。

淘宝收藏夹是淘宝线上应用之一，淘宝用户在其中保存自己感兴趣的宝贝(即商品，此外用户也可以收藏感兴趣的店铺)以便下次快速访问、对比和购买等，用户可以展示和编辑(添加/删除等)自己的收藏。

淘宝收藏夹数据库包含了收藏info表(一条一条的收藏信息)和收藏item表(被收藏的宝贝和店铺)等：

收藏info表保存收藏信息条目，数十亿条

收藏item表保存收藏的宝贝和店铺的详细信息，数亿条

热门宝贝可能被多达数十万买家收藏

每个用户可以收藏千个宝贝

宝贝的价格、收藏人气等信息随时变化

如果用户选择按宝贝价格排序后展示，那么数据库需要从收藏item表中读取收藏的宝贝的价格等最新信息，然后进行排序处理。如果用户的收藏条目比较多(例如1000条)，那么查询对应的item的时间会较长：假设如果平均每条item查询时间是5ms，则1000条的查询时间可能达到5s，若果真如此，则用户体验会很差。

思路二：

参考分布式表格系统做法，比如Google Bigtable系统。

原理是大表划分为无数子表，子表之间按照主键有序分布，如果某台服务器发生故障，它上面服务的数据能够在很短的时间内自动迁移到集群中所有的其他服务器。解决了可扩展性的问题，少量突发服务器故障或增加服务器对使用者基本透明，能够轻松应对突发流量增长，很好解决了范围查询问题。

弊端与问题：无法支持事务是最大的问题。

bigtable只支持单行事务，不支持多条记录的操作。而OceanBase希望希望能够支持跨行跨表事务，最直接的做法是在Bigtable开源实现（HBase或Hypertable）的基础上引入“两阶段提交”协议支持分布式事务，这种思路体现在Google的Percolator系统，然后该系统事务平均响应时间2-5秒（这是有问题的），并且Bigtable的开源实现不够成熟，单台服务器能支持的数据量有限，难保证单个请求的最大响应时间，机器故障等异常处理机制也有很大比较严重的问题。总体上看，这种做法的工作量和难度超出了项目组的承受能力。

Google关于分布式事务的文章(“Large-scale Incremental Processing Using Distributed Transactions and Notifications”)可以拜读一下

因此，根据业务特点做了一些定制。

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

虽然在线业务的数据量十分庞大（几十亿、上百亿），但是最近一段时间的修改量往往不多（几千万、几亿条）。因此OceanBase决定采用单台更新服务器来记录最近一段时间的更改量-增量数据，而以前的数据，即基线数据保持不变。基线数据以类似分布式文件系统的方式存储于多台基线数据服务器中，每次查询都需要把基线数据和增量数据融合后返回给客户端。这样，写事务都集中在单台更新服务器上，避免了复杂的分布式事务，高效地实现了跨行跨表事务；另外，更新服务器上的修改增量能够定期分发到多台基线数据服务器中，避免成为瓶颈，实现了良好的扩展性。

当然，单台更新服务器的处理能力总是有一定的限制。因此，更新服务器的硬件配置相对较好，如内存较大、网卡及CPU较好；另外，最近一段时间的更新操作往往总是能够存放在内存中，在软件层面也针对这种场景做了大量的优化。

---

知乎“正祥(阳振坤博士)”关于OceanBase的介绍

作者：正祥

---

2016年12月-知乎

据博士知乎所说，OceanBase团队潜心于研发OceanBase 1.0版本，今年终于上线。应用于支付宝的账务等核心系统，并通过了2016年双11交易支付洪峰的考验，终于摘下了金融系统数据库的皇冠上的明珠，账务数据库。1.0也是OceanBase架构真正确立的第一个版本，消除了之前版本的写入瓶颈，水平线性扩展，兼容MySQL，性价比远远高于MySQL，机房故障时数据零丢失，业务不中断。近期OceanBase对外有一些沟通交流，主要是弥补之前对外沟通交流不足，尽力消除外界对OceanBase的不理解和误解等。

2016年11月-知乎

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

即整个数据库以硬盘（通常是SSD）为载体，新近的增、删、改数据（“修改增量”）在内存，而基线数据在保存在硬盘上，因此OceanBase可以看成一个准内存数据库。这样的好处是：

·写事务在内存（除事务日志必须落盘外），性能大大提升

·没有随机写硬盘，硬盘随机读不受干扰，高峰期系统性能提升明显；对于传统数据库，业务高峰期通常也是大量随机写盘（刷脏页）的高峰期，大量随机写盘消耗了大量的IO，特别是考虑到SSD的写入放大，对于读写性能都有较大的影响

·基线数据只读，缓存（cache）简单且效果提升

·线上OceanBase的内存配置是支撑平常两天的修改增量（从OceanBase 1.0开始，每台OceanBase都可以写入，都承载着部分的修改增量），因此即使突发大流量为平日的10-20倍，也可支撑1~2个小时以上。

一个问题是：修改增量在内存，大概需要多大的内存？即使按双11全天的支付笔数10.5亿笔，假设每笔1KB，总共需要的内存大约是1TB，平均到10台服务器，100GB/台。

另一个问题是：在类似双十一这种流量特别大的场景中，就像前面说到的，OceanBase内存能够支持峰值业务写入1~2个小时以上，之后OceanBase必须把内存中的增删改数据（“修改增量”）尽快整合到硬盘并释放内存，以便业务的持续写入。整合内存中的修改增量到硬盘，OceanBase称为每日合并，必然涉及到大量的硬盘读写（IO），因此可能对业务的吞吐量和事务响应时间（RT）产生影响。如何避免每日合并对业务的影响呢？OceanBase通过“轮转合并”解决了这个问题。

众所周知，出于高可用的考虑，OceanBase是三机群（zone）部署：

根据配置和部署的不同，业务高峰时可以一个机群（zone）、两个机群（zone）或者三个机群（zone）提供读写服务。OceanBase的轮转合并就是对每个机群（zone）轮转地进行每日合并，在对一个机群（zone）进行每日合并之前，先把该机群（zone）上的业务读写流量切换到另外的一个或两个机群（zone），然后对该机群（zone）进行全速的每日合并。因此在每日合并期间，合并进行中的机群（zone）没有业务流量，仅仅接收事务日志并且参与Paxos投票，业务访问OceanBase的事务响应时间完全不受每日合并的影响，仅仅是OceanBase的总吞吐量有所下降：如果先前是三个机群（zone）都提供服务则总吞吐量下降1/3，如果先前只有一个或两个机群（zone）提供服务则总吞吐量没有变化。

轮转合并使得OceanBase对SSD十分友好，避免了大量随机写盘对SSD寿命的影响，因此OceanBase可以使用相对廉价的“读密集型”SSD来代替传统数据库使用的相对昂贵的“读写型”SSD，而不影响性能。此外由于轮转合并对服务器的CPU使用、硬盘IO使用以及耗时长短都不敏感（高峰期的传统数据库在刷脏页的同时还要优先保证业务访问的吞吐量和事务响应时间，刷脏页的CPU及IO资源都非常受限），因此OceanBase在每日合并时可以采用更加高效的压缩或者编码算法（比如压缩或编码速度略慢，但压缩率较高、解压缩很快的算法），从而进一步降低存储成本并提升性能。

---

淘宝：OceanBase分布式系统负载均衡案例分享

2013-02-28 csdn 作者：孙志东

OceanBase系统架构介绍

OceanBase是一个具有自治功能的分布式存储系统，由中心节点RootServer、静态数据节点ChunkServer、动态数据节点UpdateServer以及数据合并节点MergeServer四个Server构成[1]，如图1所示。

Tablet：分片数据，最基本的存储单元，一般会存储多份，一个Table由多个tablet构成；

RootServer：负责集群机器的管理、Tablet定位、数据负载均衡、Schema等元数据管理等。 

UpdateServer：负责存储动态更新数据，存储介质为内存和SSD，对外提供写服务；

ChunkServer：负责存储静态Tablet数据，存储介质为普通磁盘或者SSD。

MergeServer：负责对查询中涉及多个Tablet数据进行合并，对外提供读服务；

在一个集群中，Tablet的多个副本分别存储在不同的ChunkServer，每个ChunkServer负责一部分Tablet分片数据，MergeServer和ChunkServer一般会一起部署。

双十一前期准备

对于淘宝的大部分应用而言，“双十一”就是一年一度的一次线上压测。伴随流量不断刷新着历史新高，对每个系统的可扩展性提出了很大的挑战。为了迎战双十一各产品线对有可能成为瓶颈部分的流量进行预估和扩容成为刻不容缓的任务。在本文要分享的案例中，应用方根据历史数据预估读请求的访问峰值为7w QPS，约为平时的5-6倍，合计每天支持56亿次的读请求。当时OceanBase集群部署规模是36台服务器，存储总数据量为200亿行记录，每天支持24亿次的读请求。

当前集群的读取性能远不能满足需求，我们首先进行了一次扩容，上线了10台Chunkserver/Mergeserver服务器。由于OceanBase本身具有比较强的可扩展性，为集群加机器是一件非常简单的操作。中心节点Rootserver在新机器注册上线后，会启动Rebalance功能以Tablet为单位对静态数据进行数据迁移，见下图的示意，最终达到所有ChunkServer上数据分片的均衡分布。

表1.某Table的Tablet列表

图2.1 Tablet在三台ChunkServer的分布 图2.2加入一台机器Tablet迁移后的分布

扩容完成后引入线上流量回放机制进行压力测试，以验证当前集群的性能是否可以满足应用的双十一需求。我们使用了10台服务器，共2000-4000个线程并发回放线上读流量对集群进行压测，很快发现集群整体的QPS在达到4万左右后，压测客户端出现大量超时现象，平均响应延迟已经超过阈值100ms，即使不断调整压力，系统的整体QPS也没有任何增大。此时观察整个集群机器的负载状态发现只有极个别服务器的负载超高，是其他机器的4倍左右，其他机器基本处于空闲状态，CPU、网络、磁盘IO都凸现了严重的不均衡问题。

负载不均衡导致了整体的吞吐取决于负载最高的那台Server，这正是前文提到的典型 “短板理论”问题。

负载不均问题跟踪

客户端连接到OceanBase之后一次读请求的读流程如下图所示：

图3 客户端到OceanBase的读流程图

Client 从RootServer获取到MergeServer 列表；

Client将请求发送到某一台MergeServer；

MergeServer从RootServer获取请求对应的ChunkServer位置信息；

MergeServer将请求按照Tablet拆分成多个子请求发送到对应的ChunkServer；

ChunkServer向UpdateServer请求最新的动态数据，与静态数据进行合并；

MergeServer合并所有子请求的数据，返回给Client；

OceanBase的读请求流程看起来如此复杂，实际上第1步和第3步中Client与RootServer以及MergeServer与RootServer的两次交互会利用缓存机制来避免，即提高了效率，同时也极大降低了RootServer的负载。

分析以上的流程可知，在第2步客户端选择MergeServer时如果调度不均衡会导致某台MergeServer机器过载；在第4步MergeServer把子请求发送到数据所在的ChunkServer时，由于每个tablet会有多个副本，选择副本的策略如果不均衡也会造成ChunkServer机器过载。由于集群部署会在同一台机器会同时启动ChunkServer和MergeServer，无法简单区分过载的模块。通过查看OceanBase内部各模块的提供的监控信息比如QPS、Cache命中率、磁盘IO数量等，发现负载不均问题是由第二个调度问题引发，即MergeServer对ChunkServer的访问出现了不均衡导致了部分ChunkServer的过载。

ChunkServer是存储静态Tablet分片数据的节点，分析其负载不均的原因包含如下可能：

数据不均衡： ChunkServer上数据大小的分布是不均衡的，比如某些节点因为存储Tablet分片数据量多少的差异性而造成的不均衡；

流量不均衡：数据即使是基本均衡的情况下，仍然会因为某些节点存在数据热点等原因而造成流量是不均衡的。

通过对RootServer管理的所有tablet数据分片所在位置信息Metadata进行统计，我们发现各个ChunkServer上的tablet数据量差异不大，这同时也说明扩容加入新的Server之后，集群的Rebalance是有效的（后来我们在其他应用的集群也发现了存在数据不均衡问题，本文暂不解释）。

尽管排除了数据不均衡问题，流量不均衡又存在如下的几种可能性：

存在访问热点：比如热销的商品，这些热点数据会导致ChunkServer成为访问热点，造成了负载不均；

请求差异性较大：系统负载和处理请求所耗费的CPU\Memory\磁盘IO资源成正比，而资源的耗费一般又和处理的数据量是成正比的，即可能是因为存在某些大用户而导致没有数据访问热点的情况下，负载仍然是不均衡的。

经过如上的分析至少已经确定ChunkServer流量不均衡问题和步骤4紧密相关的，而目前所采用的tablet副本选择的策略是随机法。一般而言随机化的负载均衡策略简单、高效、无状态，结合业务场景的特点进行分析，热点数据所占的比例并不会太高，把ChunkServer上的Tablet按照访问次数进行统计也发现并没有超乎想象的“大热点”，基本服从正太分布。

可见热点Tablet虽访问频率稍高对负载的贡献率相对较大，但是热点tablet的占比很低，相反所有非热点tablet对负载的贡献率总和还是很高的，这种情况就好比“长尾效应”[3]。

负载均衡算法设计

如果把热点ChunkServer上非热点Tablet的访问调度到其他Server，是可以缓解流量不均问题的，因此我们设计了新的负载均衡算法为：以实时统计的ChunkServer上所有tablet的访问次数为Ticket，每次对Tablet的读请求会选择副本中得票率最低的ChunkServer。

同时考虑到流量不均衡的第二个原因是请求的差异较大问题，ChunkServer对外提供的接口分为Get和Scan两种，Scan是扫描一个范围的所有行数据，Get是获取指定一行数据，因此两种访问方式的次数需要划分赋予不同的权重(α,β)参与最终Ticket的运算：

除此之外，简单的区分两种访问模式还是远远不够的，不同的Scan占用的资源也是存在较大差异的，引入平均响应时间（avg_time）这个重要因素也是十分必要的：

负载均衡算法要求具有自适应性和强的实时性，一方面新的访问要实时累积参与下次的负载均衡的调度，另一方面历史权重数据则需要根据统计周期进行非线性的衰减（y 衰减因子），减少对实时性的影响：

采用新的算法后，很好的缓解了负载不均衡的问题，整体负载提升了1倍，整体QPS吞吐提升到了8w。

小结

负载均衡问题是老生常谈的问题，解决不好就会出现“短板效应”，更甚至引发分布式系统中的连锁反应即“雪崩”，从而演化成系统的灾难。负载均衡的算法也层出不穷，有的出于成本最优，有的是为了最小延迟，有的则是最大化系统吞吐，目的不同算法自然各异，不存在包治百病的良方，并不是越复杂的算法越有效[4]，要综合考虑算法所需数据获取的Overhead，更多的是遵循“简单实用”的法则，根据业务场景进行分析和尝试。

正是这种灵活性的策略，对我们的系统设计提出了新的需求，要有一定的机制来监控和验证问题：比如可以实时获取系统运行的各种内部状态和数据，允许选择不同负载均衡算法进行试验等。

---

其他学习资料来源于百度搜索：

1）CSDN:http://www.csdn.net/article/2015-04-02/2824402 杨振坤博士文章

2）CSDN：http://blog.csdn.net/u010359965/article/details/49795047

3）知网空间：http://www.cnki.com.cn/Article/CJFDTotal-JSJX201610012.htm

4）知乎：https://www.zhihu.com/question/19841579

5）阿里2016年线上测试邀请：https://help.aliyun.com/noticelist/articleid/13072677.html?spm=5176.789004749.n2.12.sEHGHY

6）http://tech.it168.com/a2012/0302/1319/000001319239.shtml

7）http://blog.sina.com.cn/s/blog_3fc85e260100mwsg.html 正祥新浪博客

8）http://www.csdn.net/article/2013-02-28/2814303-sharing-OceanBase-distributed-system-load-balance-case 孙志东