加载中…
个人资料
阿里云基础设施
阿里云基础设施 新浪机构认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:134,742
  • 关注人气:250
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

OceanBase如何解决支付宝数据库的高一致性

(2014-09-09 10:49:49)
标签:

阿里技术保障

数据库

oceanbase

关系型数据库

OceanBase是阿里巴巴自研的可扩展关系型数据库,实现了跨行跨表的业务,支持数千亿条记录、数百TB数据上的SQL操作。不论是商用还是开源,数据库都有很多成熟的选择?阿里巴巴为什么选择一条最艰难的路从底层自研,看OceanBase掌门人阳振坤老师的分享。

为什么支付宝核心数据库需要更高的一致性

数据库在互联网公司的业务系统中广泛使用,互联网巨头,例如Alibaba、Google、Facebook、Amazon、Tencent、Ebay、Baidu、Yahoo等等,都在业务系统中大量使用数据库,并且几乎都使用了开源数据库MySQL或其变种(Google自己的分布式关系数据库Spanner出现后使用了Spanner)。

为什么互联网巨头在业务系统中使用开源数据库而不是商业数据库呢?
最根本的原因可能是互联网业务带来的高并发以及这种高并发带来的商业数据库软硬件的高成本:

  • 传统业务:通过专用设备访问数据库或者访问人数非常有限,例如银行的ATM机器、信用卡POS机和柜台终端,商场的收银台等,这些专用设备要么数量非常有限,要么因为其他原因不会产生很高的并发(例如,全国的POS总数可能比较大,但不大可能同时使用,并且每次刷卡后要等待持卡人签字或输入密码等),几百、几千的并发比较常见,几万的并发就比较少见,更高的并发十分罕见。

  • 互联网业务:网民访问网站或者网上购买商品会直接导致数据库访问,例如网民浏览淘宝和天猫网站,如果对应的内容没有被缓存,就需要访问数据库,网民在淘宝和天猫上购物和支付,就会对应着淘宝和天猫以及支付宝数据库的更新操作。由于网民数量众多,大促销期间同时在线网民数量超过千万,几十万、几百万的并发已经是现实,这使得互联网业务需要传统业务几十倍、几百倍的数据库并发量。

然而,在众多互联网公司中,至少有两家公司,在其核心业务系统中依然使用着商业数据库,他们是支付宝和PayPal。为什么淘宝和天猫能够用MySQL代替其核心业务系统的商业数据库,而支付宝和PayPal却依然使用商业数据库?根本的原因是支付宝和PayPal的支付业务需要的高数据一致性以及商业数据库和其共享存储所带来的高数据一致性:

  • 非支付业务:比如搜索广告点击收费系统或者其他实时计费系统,其数据库也是主备镜像,如果因为主库故障导致主库备库数据少量不一致,那么可以采用“最小收费原则”,即不确定是否收过的费用,就不收费,这种损失的大小是可控的,也不会对客户带来影响(因为客户可能根本就没有感知,或者认为自己人品好被免单了),因此数据库主库的故障不会带来灾难性的影响。

  • 支付业务:系统中的资金不是公司自身的,而是客户的,数据库的很小异常,也常常能够被客户感知:例如,卖家的商品销售出去了却没有收到款,他一定会投诉,买家购买了商品却发现自己的账户没有被扣款、或者卖家销售了商品却发现自己收到了双倍的款项,他们或许不会投诉,但是会对整个系统产生信任危机。因此如果数据库主库出现故障,数据库备库升级为主库后,必须保证与之前的主库完全一致。

出于扩展性和成本的考虑,OceanBase数据库并没有使用共享存储(与MySQL等开源数据库类似)。那么,OceanBase是如何保证支付宝核心数据库的一致性?

OceanBase如何解决支付宝数据库的高一致性

传统数据库通过共享存储保障主备库的数据一致性,去除共享存储后,由于网络、服务器、磁盘等的不可靠,数据库的主库与备库的数据一致性成为很大的挑战(更多信息参见下文“共享存储能否解决互联网数据库的一致性”)。OceanBase立足于互联网,必须解决互联网数据库的数据一致性问题,不仅要为淘宝、天猫等商业系统提供数据库,而且要为支付宝等金融系统提供数据库。

数据库数据一致性问题的根源是软件(操作系统软件、网络软件、应用软件等)和硬件(网络硬件、服务器硬件、磁盘等)的不可靠,因此解决这个问题的根本方法是冗余。传统RAID技术(例如RAID10,RAID5)等提供了较高的可靠性,但如果所在的服务器故障,则数据还是无法访问,因此也无法保证数据的高一致性。为了解决这个问题,OceanBase引入了云计算思路和Paxos协议,通过3个(或者更多节点)的投票来保证数据的高度一致,并兼顾服务的高可用,如下图:


1


上述三个机群构成一个数据库,其中一个是主机群,所有事务都由主机群的UpdateServer(称为主UpdateServer,其他UpdateServer称为备UpdateServer)执行,事务的redo log同步到3个UpdateServer中的超过半数(即至少2个,包括主UpdateServer自己),则事务成功并应答客户。如果3个UpdateServer中有一个故障:
*主UpdateServer故障:剩余的两个UpdateServer会自动选举出一个新的主UpdateServer(参见后文“OceanBase分布式选举的实现”),由于旧的主UpdateServer数据至少在一个活着的UpdateServer中存在,因此数据不会有任何丢失,两个活着的UpdateServer经过很短时间(通常是毫秒级)的相互同步后就可以继续对外服务,保证了数据的一致性和服务的高可用。
*单个备UpdateServer故障:主UpdateServer有全部数据,剩余两个UpdateServer仍然超过半数,数据一致性和服务都不受任何影响。


如果把上述三个机群部署出于三个不同的机房,那么即使一个机房出现电源、网络或者空调等故障,剩余两个机群仍然能够继续工作,数据一致性和服务可用性都不受影响。如果采用5机群部署,则系统甚至可以抵御2个机群的故障。

上述方案已经用于支付宝的交易库并在线上试运行中。

看了阳老师的分享,如果你对OceanBase产生了浓厚的兴趣,可以关注OceanBase的微博,或者上GitHub OceanBase页面了解更多。

作者:阿里巴巴小微金服 基础数据部高级研究员  阳振坤  @阿里正祥 

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有