听阿里技术大神讲解今年双11背后的关键技术

天猫淘宝的双11活动已经过去了十多天，今年的双11有232个国家参与进来成为名副其实的全球疯狂购物节。相信所有的数字大家都已经很清楚了，11日全天的交易额达到912.17亿元，其中在移动端交易额占比68%今年每秒的交易峰值达到14万笔，蚂蚁金服旗下的支付宝交易峰值达到8.59万笔/秒，这一系列的数字，考验的是阿里巴巴背后强大的IT支持能力

天猫淘宝的双11活动已经过去了十多天，今年的双11有232个国家参与进来成为名副其实的全球疯狂购物节。相信所有的数字大家都已经很清楚了，11日全天的交易额达到912.17亿元，其中在移动端交易额占比68%今年每秒的交易峰值达到14万笔，蚂蚁金服旗下的支付宝交易峰值达到8.59万笔/秒，这一系列的数字，考验的是阿里巴巴背后强大的IT支持能力。最近，阿里双11的总导演何导（何云飞）率主要研发工作人员，接受了CSDN记者的采访，解读了今年双11背后都采用了哪些关键技术。

何导主要从今年双11的架构解读了今年的混和云模式

他介绍说，双11已经做了7年，首先要考虑的是如何应对这个交易峰值。从成本的角度考虑，采购非常多的IT资源放在那里为了那最多半小时肯定是不经济的，所以就需要利用云的模式，利用公有云，快速把资源调度过来，迅速投入应对用户的海量访问。等峰值过后，再快速把资源释放。这是云的好处，所以最后选择了公有云+混合云的组合模式，来支撑今年双十一的峰值。

也许有很多小伙伴会觉得，阿里不是有公有云么，直接把阿里巴巴的系统装到公有云上这个架构不就解决了吗？事情没有这么简单。阿里巴巴经过了15年的系统建设，系统非常非常复杂，里面不知有多少个系统在流转，一个订单要流过多少系统、数据库交互，这个复杂程度一般人是想象不到的。所以就算是用公有云支撑系统，最快的方式也是用混合云联系起来。所以阿里把核心交易系统、支付系统干干净净地放到公有云上，还有一些复杂的业务系统在里面互相调用。

何导认为，除了用混合云来应对双11这种极端的峰值情况外，常规的企业也可以运用混合云，因为它是一个快速、安全、弹性、低成本的利用公有云的方式。每个企业的系统全面上云的话，大家需要考虑一下。因为这个企业里面系统订单、商品、交易、财务、支付，这些系统要能全部搬上去是非常复杂。当然了有些系统非常简单，比如说网站没有交易的是速度很快，一个服务器、一个数据库就搞定了。

如果客户想用公有云，何导认为这里存在一个兼容性的问题。用户想要用公有云去支撑业务，那么内部的系统跟公有云的系统一定是兼容的，整个基础设施应该是平滑过渡。阿里所有云上的产品是能让电商核心系统运行起来，包括从操作系统、中间件、数据库需要完全兼容。这些产品在aliyun.COM上可以看到云服务器、负载均衡、RDS云数据库，这是企业里面最常用的三大件。在不久的将来，用户还会看到阿里自研的大数据产品ODPS，还有OceanBase数据库产品，未来都会在云上开放。

经过此次双11的展现，阿里混合云的好处，同时也是云计算的本质，那就是对于用户来说是随时可得，尽可能去突破距离、地域、规则的限制，来争取人们最珍贵的东西——时间和资源。云计算技术就是在不断优化资源调度，不断让用户的时间节省下来。云平台的本质是调度系统连接网络去做好，让这样的技术是可以流转起来的。

颜然分享了OceanBase数据库的使用情况

第二个分享技术经验的就是OceanBase数据库的研发人员，蚂蚁金服的高级技术专家韩富晟（颜然）。他首先简单介绍OceanBase到底是什么。

OceanBase到底是什么？

1、完全自主研发的关系数据库。它是一个关系数据库系统。然后是在阿里内部从第一行代码开始自己写的，完全自己研发的一个关系数据库系统。

2、金融级别的可靠性。因为数据库支撑的是支付宝、余额宝里的真实交易，是不能出错的，所以对于可靠性的要求是非常高的。

3、有更低的成本。因为我们采用的技术能把硬件本身的效率发挥得更好，所以我们可以获得更低的成本。

蚂蚁金服的高级技术专家韩富晟(颜然)介绍OceanBase

我们现在之所以还能去做一个OceanBase，更重要的一点是现有常见的一些几大厂商的数据库，诞生的时间大概是在40年前左右。那个时候大家面临的硬件环境是单纯的主机，然后在主机上编写相应的软件来做数据的存储。现在如今云计算的发展使得我们开发软件的时候面临的不是单台机器，而是集群的环境，面对着很多台机器，大家共同去满足业务的需求。面临的硬件背景不一样了，所以才有更新的架构来实现很高的可靠性、更高的性能、更低的成本。

OceanBase是2010年5月份开始立项的，到今天为止有五年多的时间，从去年“双十一”开始使用了，有10%的交易流量是留在OceanBase数据库系统上，到今年百分之百已经全部切过来了。

今年的“双十一”百分之百流量迁过来之后，其实表明获得了所有人的认可，大家愿意把关于钱、关于金融相关的事情放在了OceanBase数据库上，这就是今天能站在这里去跟大家介绍系统的原因。

今年的“双十一”，支付宝整个核心链路是运行在OceanBase上面。这两个数字大家在外面都见过，一个是14万每秒的订单创建，还有8.59万笔每秒支付。创建是当用户在天猫、淘宝页面上点机立即购买或在购物车结算的时候会创建订单，订单会有相当复杂的流程把数据显示在数据库里面，，然后跳到支付宝页面去付钱。因为大家都在0点准备抢东西，所以那个时候峰值最高的。支付往后稍微错一点，有一点错的效应，所以是8.59万笔，比14万低一点，全部会落在OceanBase里面。以交易系统为例，在“双十一”一天写进数据库的数据量有10TB。

这么多年来，已经陆陆续续有特别多的系统开始用OceanBase系统。像国际交易是阿里供应商系统也在用了。收藏夹是大家在收藏商品的时候，淘足迹是有一个页面看你所有浏览的产品，这些交易已经慢慢开始使用OceanBase了。今年“双十一”除了核心链路关注比较高的之外，这些业务也是使用OceanBase作为后台的数据库了。

毕玄：异地多活技术 三年心血终于成功

另外一个阿里自己的技术就是异地多活技术，阿里巴巴技术保障部研究员林昊（毕玄）经历了三年的研发，今年终于把这个技术完全应用到双11中，而这次，也是把整个异地多活技术研发经历讲得清清楚楚。

林昊说：“对于阿里的交易以及支付来讲，做异地多活最重要的目的除了灾备之外，更重要的点是追求持续可用，整个支付交易的体量对于用户来讲是持续可用。”

阿里之所以做异地多活主要是觉得两地三中心并不是最好的模式，它存在弊端。

两地三中心对于阿里来讲是有问题的，最重要的问题是：

1、这个模式不一定Work。比如说某些地方用了两地三中心之后，当一地的数据中心出问题的时候，是不敢流量切往异地的备份数据中心，原因是异地的备份数据中心是冷的，平时是没有用户流量进去的。如果要把流量切到那边起来之后，其实没有人有多强的信心能够保障起用以后是可以正常服务的，毕竟平时都是冷的。因为是冷的，就意味着整个起用的过程需要时间，不可能说起用就起用，一定会有时间周期。这是两地三中心的最大问题，看起来模式是很安全的，也是可用的，但是事实上不一定是这样。

2、异地备份中心因为不对外提供服务，所以整个资源会处于浪费状态，成本比较高企。

3、对于阿里的规模来讲有一个很大的问题，在两地三中心中，数据一定是单点去写。其实数据只在一个地方去写，这个时候如果整个压力比较高，比如像“双十一”的场景中压力非常高的情况下，就意味着在两地三中心的情况下所有的数据还是写上的单个点，对于存储成本压力会不断增加。比如去年8万、今年14万意味着每年压力都在增加，这时候数据库整个伸缩和外层业务的伸缩都面临着更大挑战。

对于我们来讲这三个问题是比较明显的。

阿里在整个高可用上也经历过了一段时间，主要是做了三个步骤。第一个是做了同城的双活，第二个做了异地只读及冷备，第三个是做了异地多活，经历了三代体系的演进才走到了今天。

阿里决定开始做异地多活，要的目标是：

1、需要多个跨地域的数据中心。异地多活是跨地域的，而且距离一定要做到1000公里以上的范围，其实在中国范围内全国城市都可以去布了。

2、每个数据中心都要承担用户的读写流量。如果只是备或只读业务来讲，作用不是很大。

3、多点写。因为每个数据中心去承担用户读写流量的话，如果读或写集中到全国一个点的话，整个延迟是没有办法承受的。

4、任意一个数据中心出问题的时候，其他中心都可以分钟级去接管用户的流量。

这个是阿里在做异地多活项目的时候，希望在这四点上都能够做到，然后也只有这样的情况下才认为是一个异地多活的业务。

异地多活对于我们来讲，其实很多人都可以看到异地多活最大的挑战是什么？

1、距离。看起来距离没有什么，比如说1000公里以上也就是30毫秒的网络延迟，来回一次是30毫秒左右。30毫秒对于用户来讲，如果只是给你增加30毫秒，用户其实没有感受。但是当你打开一个淘宝页面的时候，事实上当你在商品页面看到一个商品点立刻购买的时候，页面的背后大概有100多次以上的后端交互，如果100多次全部跨地域完成的话，就意味着页面的响应时间将增加3秒。如果增加3秒，用户绝对会有明显感受。因为对于阿里来讲，很多页面就出不来了，3秒已经超时了。对于我们来讲，这第一点是直接带来用户体验的不可用。

成本，当系统响应时间增高的时候，意味着每年“双十一”增加的QPS将付出更大的成本，因为吞吐量在下降，这个时候的成本也是很难接受的。距离带来的延时问题是最大的问题。

2、既然要解决掉距离的问题，多点写是解决距离的问题，如果没有延时问题可以不多点写。只要开始多点写了就会带来第二个最复杂的问题，其实我们认为第一点延时问题一定程度也许可以强制接受，也就是能够打开，打不开就有问题了。如果一旦出现多点写带来的数据正确性问题，这对我们来讲是最致命的。多点写，比如说出现这一次访问在A数据中心写的数据，然后再访问的时候到B数据中心又写了一条数据，两条数据如果合不到一起的话。对于大家最直观的感受是有可能买了一个东西付了钱，然后看到可能是没付钱。或者干脆买了一个东西，压根就没有看到购买。对于阿里来讲，这是最大的一个问题。

对于我们来讲，在多点写的情况下最大的挑战是怎么保证用户写入的数据一定是在正确的地方，另外看到的一定是一致的，这是整个异地多活中最大的挑战。

针对这两个个问题，对于延时的问题来讲，其实延长时的问题意味着最好的解决方案是什么呢？如果这一次访问页面的整个操作全部在当前机房内完成的，自然就不存在延时问题，因为没有跨出去。

针对第二个问题，异地。在全国部署的时候，意味着是不是要把整个业务全部全国部署，因为这有成本因素。大家知道阿里的业务非常庞杂，其实没有必要把所有的业务都在全国部署，因为不是所有的业务都有足够的量。

因为不是整个业务全国部署，所以决定起另外一个名字叫单元化。意味着我是把业务划成了各种各样的单元，比如有交易的单元，这个单元是完成交易业务，所以在内部代号是单元化项目。

为了解决延时问题，能在一个机房内完成就不存在延时问题。另外一个核心思想是单元封闭，需要让单元内的应用访问和数据的读写操作全部处于封闭状态，这就是最完美的状况。如果能做到这样，其实在全国任意城市部署都不会有问题。

开始多点写以后，怎么去保障整个数据写入的正确性以及一致性。阿里确实做了非常多的东西，因为一个用户访问阿里的时候，其实阿里的背后是庞大的分布式系统，你访问了一层可能只访问了一个系统，事实上背后牵涉进来几十个系统。咱们把整你在访问每一层的时候路由都是正确的，比如这个用户访问数据中心A，但是由于某个原因访问到数据中心B，怎么在保证后面访问不同系统的时候准确跳转到正确的地方去，因为每个数据中心的数据不太一样。

为了保证一个用户真正写数据的时候不要写错，写入数据库之前都会做保护动作，确保用户写的数据没有写错一个地方。如果写错一个地方，可能就无法恢复了，所以在那个地方有最后的一层保护。同时有实时数据校验系统检查是否符合我们的期望。

对于异地多活来讲，还有数据一致性中很大的挑战会出现在流量切换的动作中，比如说AB两个数据中心，A开始是承担20%的流量，8承担80%的流量。当把流量从一个地方切到另外一个地方的时间，有可能出现切换过程中你还在A数据中心写，但其实写完之后到B了，有可能看到出现的数据是不一致的。怎么保证在整个流量切换过程中数据是绝对一致的，我们也做了很多的东西。

在异地整个数据中心还有另外一个非常重要的核心技术产品，就是我们需要一个数据同步的东西。因为大家知道阿里现在除了OB以外，很重要的一块是MySQL，MySQL自己的主备是没有办法满足要求，在异地做到延时是没有办法满足的，我们决定做了自研的数据同步产品。在2015年“双十一”中，所有数据同步控制在1秒以内，1秒以内是可以接受的。

阿里为了做到整个异地多活，其实自己也折腾了很多年。这个项目在阿里内部总共花了三年的时间，自己在最近的一封总结邮件中也写到，经历了三年的磨炼，我们终于把异地多活变成了阿里电商架构级的能力，意味着在整个架构中具备异地多活的能力，在以前也许不一定具备。

我们为了整个过程中是比较平滑的，因为不能对业务产生太大影响，所以分了三年的时间去完成。在2013年首先采用的是在同城起用了两个单元双活，真正意义的双活，因为那两个单元都是写自己的数据库的，两个单元都是双写。

在2014年觉得可以往前更进一步，选择了距离更近的城市，其实还是有延时。如果没有做过单元化改造业务部署到异地的时候，页面会超时，有些页面打不开。但是因为单元化在背后就没有太大问题，在2014年成功在两个相距有一定距离的城市起用了异地双活，在去年“双十一”中两个城市分别承担了50%的用户流量，有些用户会访问一个城市，有些用户访问另外一个城市，当下单的时候会下在同一个城市里面。

在今年单元化可以宣告能力基本成熟的阶段，所以在今年开始起用了距离在1000公里以上的另外一个数据中心，然后今年数据中心是多点部署。从2015年从2个变成3个或4个以后，对于我们来讲的另外一点是因为距离增加到了1000公里以上，基本上意味着阿里整个电商以及支付是可以在全国任意一个城市去部署，并且可以部署多个，意味着以后的“双十一”整个扩充能力是会变得很容易。

对于我们来讲，当阿里整个架构能力进一步提升到了异地多活时代以后，对于我们来讲带来了两个好处：

第一、有极强的水平伸缩能力。以前做“双十一”的时候，都必须去算，比如去年8万笔，今年14万笔的时候，必须要算增加的6万。还有因为每年业务模式的变化需要算每个应用加多少机器。但是在单元的情况下，一组单元就是多大的能力，然后只要按照单元扩充就结束了。假设一个单元可以做到2万笔，其实14万笔对于我们来讲是建设7个单元就结束了，整个伸缩能力会比以前强大非常多。而且每个单元都是写自己的数据库和存储层，包括cache全部写自己的，这个时候伸缩规模是可控的，不像以前不断加，数据库有可能抗不住。在抗不住的时候可能会做分布等等，但其实也是比较复杂的，现在我们改变了伸缩力度的模式。

第二、异地多活怎么去应对故障。比如在阿里内部会按照这样的等级去划分所有业务能够支持故障应对能力，比如说单实例出故障在多久能恢复，或者单机房或单城市或全局的服务，比如DNS等等，我们会按照这个对每个业务，然后就知道每个业务当出现故障时整个应对能力是怎样的。

在阿里做完以后，希望整个异地多活的能力能逐渐演变成业界的，比如说在阿里做了整个多活以后，其实金融行业也不再希望自己只是一个两地三中心而已，希望更加往前前进一步，对于他们来讲整个投入会更加划算。另外容灾能力会更强。阿里把自己异地多活的能力沉淀成不同的东西，比如支付宝、蚂蚁金服把自己的能力承担到金融云里，就意味着在金融云上搭建的金融系统会自然具备异地多活的能力。

编辑总结

通过上面几位技术大拿的讲解，我们会发现，由于中国网民数量是世界之最，中国互联网公司所面对的技术问题是其他国家很难想象的，所以我们的技术也都需要自己去研发。以阿里为主的互联网人，通过双11这种残酷的考验来锻炼自己的技术和产品，从而用这种产品为更多的用户服务。

欢迎扫描中云网 官方微信公众号