作为一个技术人,我眼中的天猫双11

       双11渐渐成为了一个全民狂欢的购物节，今年更是创造了912亿的交易额，对阿里技术的挑战是不小的，下面我就从一些技术层面来分析，阿里技术人是如何做到的。

       在双11开始之前，定的标准是1212 6，即每秒最多创建12万笔订单，12万支付宝确认支付页，6万笔支付宝付款，其他的请求会被直接限流，服务器不会处理也就不会占用服务器资源，买家看到的就是那句友好的提示，然后再重试一下基本就ok了。

       技术架构

       去年是支持6万笔订单创建，而今天提升了一倍，那在技术上是如何做的呢。今年整体的部署结构从去年的杭州上海两单元升级成了3地四单元，分别是：杭州单元、上海单元、深圳单元、深圳阿里云单元。加入了阿里云单元，是为了告诉广大开发者和公司，阿里自己最核心的业务也跑在阿里云上，大家可以放心购买阿里云的服务。

       从架构上来看，1s中12万创建订单请求，杭州承担4万笔，上海4万笔,这两个单元仍是所有单元中最重要的。大家一定会问什么是单元，为什么要进行单元化。下面简单介绍一下背景，2011年左右的时候，将应用按细粒度进行划分，订单创建、订单履行、购物车、商品中心、用户中心、优惠、物流、库存、积分等都拆成了单独的应用，一次下单，会发出上百个请求，涉及的应用有几十个。这就出现了一个问题，如果这些应用和数据库服务器都部署在同地同一个机房是没什么问题的，但是对于一个这么大的互联网企业，这样的部署是不安全的，但是异地部署又不希望应用间调用有大量网络开销，所以就提出了单元化。一个用户的请求（包括购物车、下单、订单查看）都在同一个单元处理，而单元内的应用访问和数据库访问都在同地同一机房，数据库通过drc进行同步，避免了糟糕地跨机房访问。很多人以为这就完事大吉了吗，其实不然，有一个东西是和用户没有关系的，那就是库存，全局唯一，且变化频繁。如果每个单元都存有库存中心的数据库，那各个单元的库存数据的一致性很难保证，一但出问题就会造成超卖和资损。

       如何保证双11没有问题，需要做些什么？

      

                      (单元内架构图)

       要做的：

        1.应用支持横向扩展

2.缓存的大量使用

3.领域内水平拆分

4.单元内封闭

5.分布式事务一致性

6.容量评估、保护

7.容错性、强弱依赖、预案

8.监控

       说白了要准备的就这么多，今天不一一展开了，会在后面的文章中来介绍是如何做到的，请关注我的csdn。

       最后做到了这些，如何能保证双11当天没有问题呢，这就是公司内强大的全链路压测了，模拟线上正式请求，看看上下游各个系统的表现是否达标，这个系统目前还处于保密阶段。

       双11 对于每个人来说都是一次挑战，但每个人过来都会有很大的成长。stay hungury,stay foolish.

 

 

                                                    王志勇    

20151214