(转载)(收藏)OceanBase深度解析

　　一、OceanBase不需要高可靠服务器和高端存储

　　OceanBase是关系型数据库，包含内核+OceanBase云平台(OCP)。与传统关系型数据库相比，最大的不同点，

是OceanBase是分布式的，支持水平线性扩展;基于PC服务器，无高可靠服务器，无高端存储(共享存储)。与一些传统数据库背后一定要有共享存储相比，这是完全不同的。

　　现在OceanBase已经在天猫、支付宝、淘宝、一淘等多处使用。2014年的双11交易中，只承担了10%流量，但是今年双11中已经承担国内交易100%流量，国际交易100%流量，会员50%流量，支付充值50%流量等。

　　要知道，交易多套核心系统在OceanBase之前都是某商业数据库的，这也是业内广为流传的故事了。

　　(1)2015年双11：

　　(2)00:05:01：交易创建达到峰值14万笔/秒;

　　(3)00:09:02：支付达到峰值8.59万笔/秒。

　　若对这组数字无感，做个对比。Visa支付峰值是1.4万笔/秒(在实验室测试是5.6万笔/秒);MasterCard实验室测试是4万笔/秒。

　　但是现在有个一直困扰业内的问题：支付为何比交易要低?交易创建时，支付宝内部就可以实现。但是要支付，涉及扣款，来源可以是余额宝、花呗与银行渠道，比如信用卡和储蓄卡等，尤其银行渠道方面，其中都需要交互时间。一般来说，传统银行峰值多是在几千笔每秒。

　　这样的交易笔数在全球都是遥遥领先的。

　　当然，过程并非完全一帆风顺。例如去年曾经一块硬盘坏了，还好有容错，自身屏蔽了。今年没有硬盘故障，但是有一个业务在压测环节没有发现，其查询量极大，且随着交易量增加而增加，每整分钟都会有查询产生，指向应该是备库，但是实际是却是指向了主库。因此技术工程师发现每个整分钟都有交易抖动。最后采用了紧急变更的方法，将查询调到备库才得以解决。

　　数据库有很多技术重点。但有几点很重要，第一是可靠性。

　　先分析下传统方式，如传统数据库+高端共享存储，或冗余方式来实现。服务器也要高可靠。所以要实现5个9，软件、存储、服务器都很贵，服务也贵。而为了避免不可控因素，传统数据库形成了主备镜像。有三种方式：

　　(1)Maximize Protection

　　(2)Maximize Performance

　　(30Maximize Availability

　　上面三种方式各有利弊。事实上，传统方式的可靠性很好，但是在可扩展能力、成本(性价比)上才是制约。

　　相比之下，PC服务器集群，性价比高、水平扩展、易于采购和维护等，亮点多多。但制约只有一个，稳定性可用性不如高端服务器和高可靠存储。如果说高端服务器和存储可以做到5个9，那x86 PC服务器能做到3个9就不错了。所以机器不可靠，但系统就必须要可靠。这就是云计算的思路。同一数据存在多地。那么每个事务到达超过半数库时，少数库故障肯定就不会影响业务。

　　再引用一段博客内容的分析，如下所示：

　　为此，OceanBase引入了Paxos协议，每一笔事务，主库执行完成后，要同步到半数以上库(包括主库自身)，例如3个库中的2个库，或者5个库中的3个库，事务才成功。这样，少数库(例如3个库中的1个库，或者5个库中的2个库)异常后业务并不受影响

　　如图1所示：

　　图1

　　那么现在有个问题：存了3份数据，是否只利用了三分之一的服务器?不是的，由于磁盘空间会有浪费，但是比共享存储要少的多。而且备份服务器也是其他系统的主服务器。要实现高可靠性，这一点浪费是必须的。

　　二、版本升级是数据库故障最大发生处

　　传统数据库的版本升级是最要注意的。一些大的故障多是由于这样。业内有些做法是先升级备库，升级完成后，将主库迁移过来。但是这一过程也要打问号。由于版本升级造成数据库问题，业内屡见不鲜。例如2013年某国有大商业银行因为数据库版本升级，造成业务停顿近1小时。再如2014年某国的签证数据库罢工(后查明是因为一个小补丁)，20万份签证被拖延几星期。

　　相对这些传统数据库，几年才出一个版本，内核开发测试团队就有千人，只有觉得很可靠时，才会对外发布。但是互联网节奏不容许如此，因此OceanBase面临的挑战更大。为了快速响应业务需求，OceanBase最初一个星期会发几个版本，现在则是1-2周发布一个版本。

　　OceanBase开发之初就开始思考这个问题。即使到现在，从1个测试人员到现在十几，OceanBase的测试团队连人家零头都不算。问题始终存在，办法总要想去来——灰度升级。

　　我们来详细分析下：

　　与传统数据库相比，OceanBase的另外一个关键特征是软件版本的灰度升级。主备方式的传统数据库是“单活”的，只有主库可执行写事务，尽管维护升级时可以先操作备库，操作完成后备库变成主库并且接受用户访问是一步到位的，如果新版本有问题，则业务受到影响。而OceanBase则是“多活”设计，即多个库(3个，5个等)每个都可以有部分读写流量，升级时先把要升级的库的读写流量切走，升级后先进行数据对比，正常后逐步引入读写流量(白名单，1%，5%，10%......)，一切正常并运行一段时间后再升级其他的库。如下图所示：

　　图2

　　图3

　　图4

　　例如出现新版本异常，赶快将新版本上的流量切走。对业务的影响是可控的。另外，每个事务带64位校验码，每个表及每个列带64位校验码，都来保证事务与表列的正确性。

　　三、OceanBase与传统数据库的技术区别

　　OceanBase与传统数据库(如mysql)的技术区别，有三个问题值得关注，如下所示。

　　(1)为什么像mysql这样的传统数据库难以灰度升级?因为传统数据库备库就是备库，不是Active的，只有出现问题或者升级替换时才会变成主库。而OceanBase每个库都是Active。

　　(2)为什么传统数据库不可以用PC服务器代替高端服务器和存储?一方面是一台普通PC服务器不能撑住传统数据库，且出现故障几率大，另一方面是软件机制需要做很大更新，而传统数据库是将这些硬件可靠性通过高端产品来实现，而专心做SQL优化、IO优化、排序优化等。

　　(3)为何数十年来，数据库方面很少有能够挑战某商业数据库的统治地位?由于数据库事务(ACID)实现非常复杂，业务对数据库的稳定性要求极高。也因为磁盘IO瓶颈严重制约着数据库的性能，用同样的技术实现途径，其他厂商很难超越它，而全内存数据库成本太高。

　　那么OceanBase的切入点是在哪里?

　　随着发展，现在的数据库存储的数据量越来越大，多是以TB来统计。但是一天修改量并不大，增删改(修改)只是很少的一部分，比如账务库、全国人口数据库、交易库都是这样。基于这样的原则，OceanBase用磁盘存储数据库，但是用内存数据库来存储修改数据，没有额外成本。还消除了随机写磁盘，批量来写入，非常适合SSD(固态盘)【进一步解释下，普通磁盘最怕随机读，但SSD很适合。利用这一特性，OceanBase每天一次真正同步修改到磁盘上】。修改增量融合也采用了多库异步的方式，避免了对业务的影响。我们要知道，以块为单位来设计的数据库是很难做到这一点的。

　　目前，OceanBase已经广泛使用在阿里集团的金融领域，比如支付、交易、清算等。今年双11还成功承担了开篇时提到的任务。

　　要注意的是OceanBase 1.0还消除了UpdateServer单点，且正从语义+协议方面完全兼容MySQL，DBA可以将MySQL完全替换成OceanBase，但是应用层是完全感知不到的。对业务完全透明，这样至少能将数据库服务器减少一半。

　　OceanBase即将在2016年放到阿里云上对外提供服务。最后，技术同学们喜欢将OceanBase称为OB。

转载自：（http://transcoder.baidu.com/from=844b/bd_page_type=1/ssid=0/uid=0/pu=sz%401320_2001%2Cta%40iphone_1_10.1_3_602%2Cusm%401/baiduid=CAD12093536B7F67F1A154DC022C9A4F/w=0_10_/t=iphone/l=3/tc?ref=www_iphone&lid=15345513068300911445&order=5&fm=alop&tj=www_normal_5_0_10_title&vit=osres&m=8&srd=1&cltj=cloud_title&asres=1&title=深度解析OceanBase&dict=32&w_qd=IlPT2AEptyoA_yiqH5KgJS1trABVp8Iou6kYfxq&sec=16616&di=8572ff84896d639e&bdenc=1&tch=124.399.96.871.2.565&nsrc=IlPT2AEptyoA_yixCFOxXnANedT62v3IEQGG_89GQTq5jo39h47aUbB3YyPuMnaJJjb9rXGPfQoDln_d_mMskNYWgK&eqid=d4f636d4e430c000100000015826d2b0&wd=&clk_info=%7B%22srcid%22%3A%221599%22%2C%22tplname%22%3A%22www_normal%22%2C%22t%22%3A1478939326718%2C%22xpath%22%3A%22div-a-h3%22%7D）