与过去10年一样，2019年天猫双11再创新高。

这个数字的背后是一代又一代支付宝工程师为突破技术难关而付出的努力。

今年双11前，小编邀请了11位经历过双11的技术同学进行口述，并特地准备了一部纪录片《一颗心，一场战斗》，讲述一路上不为人知的往事。

9分钟的视频根本不够看。分割线

对于技术人员来说，要保持双11一天24小时的稳定和流畅并不容易，但最考验的时刻无疑是午夜刚过的那一刻，人们拿起手机，刷新已经保存的购物车，点击支付！

2011年，零点购物越来越顺畅的双11背后，支付宝进行了一些不为人知的技术探索，今天也凸显出来。

让我们从外部瓶颈开始

让我们从外部瓶颈开始

事情似乎从一开始就不顺利。

2011年双十一期间，高峰期有少数用户无法支付。经调查发现，这是因为少数银行的网上银行系统在压力下出现故障。早年的支付宝交易中，用户点击支付后，必须通过支付宝与银行的接口进行支付。早些年，这个接口的性能很差。每秒只能支持几十到几百笔交易，稳定性也比较差。一旦流量增大，就容易出现故障。

如果这个问题不解决，以后每次重大促销时都将无法支付，极大影响用户体验。然而，这个问题仅靠技术很难解决。银行对于网上银行系统的演进有自己的规划，支付宝不能干预他们的系统。

然而，聪明的运营商想出了一个解决办法。 2012年双十一，支付宝利用活动吸引用户先充值后付款。允许用户先充值到支付宝余额，然后在双十一时直接从余额中扣款。这样，外部瓶颈就切换到了内部。这样做的效果非常显着，大大缓解了支付失败的问题。

然而，外部瓶颈始终存在。面对每年翻倍的流量高峰，对外部支付的依赖始终是一个隐患，不知道什么时候会爆发。

解决这个问题最好的办法就是不走网上银行，让资金在内部系统流动。这就是先充值、后付费的原则。那么，有没有办法吸引用户往支付宝里充钱呢？ 2013年6月，支付宝推出余额宝，解决了这个问题。截至2014年底，余额宝用户规模达1.85亿。 2013年和2014年双十一期间，交易额峰值也分别实现了4倍和3倍。成倍增长。

2018年5月，支付宝接入网联清算平台。与此同时，银行近年来也大力提升系统能力。大中型银行网上银行系统支持的交易笔数已达到每秒2万笔以上。外部问题基本解决。

解决了外部瓶颈后，支付峰值能达到多高，取决于支付宝的系统如何解决逐年加剧的流量高峰。

能力规划：三军不粮草前行

事实上，交易峰值面临的首要问题不是设计一个完美支持水平扩展的架构，而是准确预估可能出现的流量峰值，然后安排相应的机器和资源。如果不进行估算，可能会出现两种情况：准备资源过多，架构过度设计，造成资源浪费；准备资源太少，无法完美支撑大促销，导致部分支付排队或失败。每年双十一的时候，负责大促的决策团队都会根据历史数据和大促目标制定一个交易值，然后把这个值分解成各个系统需要处理的流量，这样以便进行系统容量规划。

双11的场景指标一般包括交易创建数、结账展示数、交易支付数等。总付款目标数量已经可用。运维人员根据总tps/单机tps的算法计算出应用在各个指标下的单机能力。然后，参考历史活动数据，可以计算出应用在不同场景链路下的单机能力。 tps。

但这种方式需要较多的人工干预，且对各个应用的容量估算相对粗粒度。后来支付宝搭建了容量分析平台，可以进行自动化的细粒度容量分析。

它的原理是，如果我们把一条链路理解为一个业务，则链路根节点可以理解为该业务的流量请求源，每条链路上的节点（这里的节点包括应用程序、DB、tair等）可以计算该节点的调用次数相对于根节点的流量的系数。因此，当业务源的QPS确定后，就可以根据链路数据计算出各个节点的QPS。

2018年双十一，支付宝还构建了智能容量模型，不仅可以根据业务流量估算容量，还可以智能产生应用资源部署方案，以便在这个方案下，部署单元能够承载给定的业务流量。能力水平在目标范围内。

智能容量模型是支付宝在系统中实现数据技术和人工智能的探索和实践的一部分。这方面也是目前支付宝技术探索的方向之一。

LDC与弹性架构：大促最有力的武器

估算完流量并进行合理的容量规划后，下一步就是看我们的架构是否能够支撑流量高峰。

首先需要说明的是，流量高峰涉及到系统的方方面面。支付宝整个系统极其复杂，同时针对toC和toB推出了很多服务。即使只关注核心支付系统，也包括支付清算、记账、记账等子系统。

系统的部分组件由通用中间件支持，如负载均衡中间件LVS/、阿里巴巴的分布式缓存中间件Tair等，其他组件由支付宝自研的金融级分布式中间件处理。

支付高峰的本质是高并发问题。​​​​互联网公司解决高并发的思路就是横向扩展、横向拆分，用分布式的方式应对流量高峰，支付宝也不例外。支付宝很早就完成了服务化架构和核心数据库的横向拆分，并成功应对了前几年的双十一。

分布式系统图

这种架构的问题在于，所有子应用程序都需要访问所有数据库库，但数据库连接却受到限制。当时主流商业数据库中，连接不是共享的，这意味着一笔交易必须独占一个连接。然而，连接是数据库非常宝贵的资源，不能无限地增加。当时支付宝面临着无法再扩展应用集群的问题，因为每增加一台机器，每个数据分库就需要几个新的连接，而此时几个核心的连接数数据库已达到上限。应用无法扩展，这意味着支付宝系统的容量已经固定，业务量无法再增加。别说是大销量了，过一段时间，很可能就连日常业务都支撑不了了。

这个问题迫在眉睫。从2013年开始，支付宝开始了新一轮的架构转型，实施了单元化的LDC逻辑数据中心。终于成功顶住了双十一的流量高峰。

单元是完整功能的整个站点的缩小版本。它是通用的，因为所有应用程序都已部署；但它并不全面，因为它只能对部分数据进行操作。这样，只要将数据分区增加一个单位，就可以提高整个系统的处理性能上限。

单元化图

然而，并非所有数据都可以拆分。例如，有些底层数据是全局数据，需要被所有单元应用访问。而且，经过近十年的建设，支付宝的一些结构还不能很好地划分单元。在此前提下，支付宝设计了CRG的单元化架构，既可以发挥单元化的优势，又可以支持现有的架构。

CRG架构图

有关支付宝单元化和 LDC 的更多信息可以在此处找到。

LDC实施后，系统容量得到了横向扩展，成功支撑了2013年及以后的双十一流量高峰，系统不再受单点故障的限制。经过改进，还可以异地多活动，最终形成三地制。五中心金融级架构。

理论上，只要无限扩展LDC的计算资源，就可以应对无限的流量。但这样做的话，大部分机器只能在大促销时使用，平时就会闲置，造成资源浪费。平时最好用少量的资源来支持正常的流量。在大销期间，通过容量规划，可以提前激活一些闲置或第三方资源，应对客流量高峰。这就是弹性架构的由来。

2016年，支付宝为了促销开始对其灵活架构进行改造。弹性架构基于业务链路。由于大促期间只有部分链路出现流量激增，因此只需对大促的关键环节进行弹性扩容。

弹性架构涉及多个层次的转换。首先是弹性机房和弹性单元。需要在LDC逻辑机房架构上根据业务纬度继续进行切片，保证单件业务能够在逻辑单元中独立部署，并保持与非弹性单元的连通性。 ，并且可以随时弹出和回收。

其次是弹性存储，包括管道数据和状态数据的弹性。管道数据包括付款订单。为了支持这些数据的灵活性，创建了弹性位+弹性UID，然后路由根据弹性UID将订单分配给弹性单元进行处理。基于状态的存储，例如用户的账户余额，作为一个整体弹出。具体实现方法是通过DB层的主备切换，将主库的压力分流到备份数据库。

然后是中间件层面的改造，包括路由、RPC、消息队列、流量管理等，应用层面也需要进行相应的改造，因为每个弹性单元需要部署为独立的逻辑单元，所以需要从服务到数据进行排序剥离，还需要增加弹性ID等弹性逻辑处理。

除了这些之外，运维平台和压测工具也需要进行相应的修改。

弹性架构在2016年推出后，成功支撑了当年的双十一，满足了大促的要求和预定目标，节省了机房的物理资源，成为应对流量高峰的最有力武器。重大促销活动。

弹性架构中的弹性单元是新的集群，但它们实际上可以进一步提高资源利用率。方法是离线和在线混合部署技术，因为有些集群是用于离线大数据分析，但并不是24小时满载。当没有任务时，集群资源利用率极低。如果将线下应用和线上业务应用部署在一起，在销售高峰期利用这些资源，就可以减少销售期购买的资源，进一步节省成本。共址技术需要分时调度和运维协调，将资源在不同时间分配给不同的应用。

自2017年起，支付宝开始尝试线下、线上混合、分时调度技术。利用离线技术在大促期间使用的集群资源，大大提高集群资源利用率。

百万级支付：解决数据库扩展瓶颈

2016年双十一，交易峰值达到每秒12万笔，这场高并发之战还在继续。我提到了很多处理大销售的技术手段，但实际上缺少了一个最重要的部分，那就是数据库。在流量高峰期，数据库承受的压力最大。这是因为我们在前台看到一笔成功的交易，但是拆解之后，一笔交易平均可能会产生数百甚至数千个请求，数据库的压力远远大于我们看到的数字。

从一开始，数据库就一直是支付宝系统的瓶颈之一。事实上，数据库的很多升级都是与架构改造相结合的。除了上面提到的灵活变换外，还包括：

1、分库分表，将原来的交易账户库分离为交易库和账户库，通过分布式事务解决数据一致性问题。

2、数据库水平分割，将所有用户按照1%粒度分为100份，并结合单元化逻辑隔离。

3、数据库读写分离、多点写入、数据复制，通过这些方法可以大大提高性能。

支付宝早年所使用的商业数据库可以做的改进是有限的。由于成本原因，不可能为一年只持续几天的重大促销活动购买额外的数据库系统和设备。

早在2014年双十一，支付宝自研数据库就开始承担双十一10%的核心交易流量，随后逐步承担了交易、支付、记账等核心系统100%的流量，并经受住了极端的条件。严格的测试。

从第一天起就规划成为分布式关系型数据库，天然支持大规模、高并发的场景。但支付宝用户数量太大，双十一面临的系统压力太大。到2017年双十一时，即使使用额外的弹性库，数据库CPU压力也已接近上限。成为持续扩张的瓶颈。

2018年双十一期间，支付宝内部提出了百万支付架构，这意味着该架构可以支撑每秒百万笔交易的系统压力。该架构的核心是2.0分布式分区方案。

对于以往架构下的DB扩容，由于单台DB机器的限制，而一个UID最多对应一台机器，这里的扩容能力是通过在DB中添加新的集群以及在应用中添加数据源来实现的。这会带来应用内存增长、多个数据源导致的费时费力的弹窗弹跳、多个DB集群日常维护成本高等一系列问题。为了解决这个问题，可以考虑让DB像应用程序一样动态扩展，必须突破一台机器最多一个UID的限制，让应用程序和DB可以同时扩展，无需实现新的容量支持添加新的数据库集群。能力。

基于DB的分区功能极大地增强了DB的可扩展性，避免了必须添加集群来扩容的尴尬。同时，对应用进行了相关升级改造，如整个站点序号架构的升级、系列中间件的改造、任务获取场景的改造等。

分区架构

传统数据库弹性架构将数据物理拆分到不同的机器上，这使得业务在数据接入/研发/后期维护以及数据支撑设施方面非常繁琐；同时，拆分后资源难以快速恢复，无法实现数据拆分和聚合。没有生意损失。与传统数据库的弹性架构相比，2.0架构完全不侵入业务。它内部通过分区实现数据分片的自组织和负载均衡，通过生成列和分区规则实现自动路由，并通过分区聚合消除分布式事务性能（）开销以提高性能以实现无损线性扩展。另外，数据分片之间的架构实现了高可用架构，隔离分片故障，消除单点故障。

2018年双十一，2.0成功上线，支持全交易、支付流量。而且，这种基于.0分区方案的架构可以轻松扩展以支持数百万笔交易，应对流量高峰的战斗暂时告一段落。

技术保障：大力推进技术标准化

双十一是新技术的练兵场，那么如何保证这些技术能够有效支撑流量高峰呢？尤其是支付宝，涉及到人们的资金安全。一旦出现问题，后果将极其严重，所以一定要谨慎。

2014年，支付宝推出全链路压测，成为系统技术验证的神器；从2017年开始，支付宝开始构建自动化、智能化的技术风险防控体系； 2018年双十一推广中控在线，大促相关的技术已经开始趋于标准化。

大促中控图

大促中控是一站式大促保障解决方案。其目的是积累以往大促销的经验，形成套路和标准，最终向无人值守的方向发展。大促销不需要技术人员。又熬夜了。

随着中央控制的大提升，可以进行自动化无损压力测试。在线压测可以在不影响正在进行的业务的情况下获得理想的结果。其核心技术能力是环境、机器、线程的隔离，以及压测异常时的智能熔断。

压测并不是万能的，有些问题在压测过程中可能很难暴露出来。 2018年以来，支付宝还开展了红蓝攻防演练，检查销售异常高峰时的应急策略、组织保障和反应速度。到位，并验证新技术的稳定性是否符合标准。

为了重大促销期间的资金安全，支付宝开发了实时资金验证系统，实现峰值资金安全的实时验证，验证每一笔资金都是准确的。

当所有技术都准备就绪时，这还不够。每次大促前需要切换的配置有很多。一旦出现错误，将会造成严重的后果。因此，支付宝为最终状态构建了技术风险检查能力。在大促销前一天进行数百或数千次自动配置检查，以确认所有系统均处于促销状态，以确保不会出现任何问题。

随着时钟逐渐归零，大甩卖即将开始。

未来可期，我们一起并肩前行

综上所述，双十一流量高峰考验的是架构的可扩展性、数据库的承载能力、运维强大的调度能力、完整的技术支撑能力。为了保证推广顺利完成，需要做的技术准备远远多于文中提到的。全链路压测等幕后功臣还有很多。由于篇幅限制，这里就不一一介绍了。

支付宝也在持续更新其技术设备库。今年双十一期间，支付宝还测试了多项新能力：2.2上线，该版本在TPC-C基准测试中获得第一名，稳定支持新大促；自主研发的Mesh首次亮相大促舞台，目前100%覆盖支付宝核心支付环节，是业内最大的Mesh集群。

随着普惠金融的落地和万物互联的发展，支付平台面临的流量压力将进一步加大。我们现在看到的高峰，未来可能会很常见；未来的峰值可能比现在高出几个数量级。高峰支付之战还将继续，技术也将不断发展。未来，双十一的科技大战将更加精彩。

专注于此！小蚂蚁送福利啦！

【参与方式】

关注蚂蚁金服科技公众号（蚂蚁-）