支付宝红包稳定性实践与思考--讲座思考

SDCC 2016架构峰会纪要（一）

关键词：深度、干货、大牛、火爆、一线、图书

题目 主讲人 主讲人个人简介 支付宝红包稳定性实践与思考 王 俊 蚂蚁金服支付清算平台架构师 宅米网技术架构变迁与实践 李智慧 宅米CTO 携程下一代无线App架构设计 陈浩然 携程旅行网无线开发总监 新型架构实践与应用 孙子荀 腾讯手Q公众号后台负责人 从概率和用户感知出发实现高可用架构 史海峰 当当网架构部总监 高可用系统在点评的实践与经验 陈一方 大众点评交易平台技术团队负责人 微服务架构设计与实践 黄 勇 特赞CTO 大型电商网站中的通用精准化推荐平台的搭建 陈 兀 1号店担任推荐团队架构负责人 从0到1，手腕上的人工智能 范超霏 出门问问高级系统架构师

支付宝红包稳定性实践与思考–蚂蚁金服支付清算平台架构师王俊

2015年双11，支付宝主要挑战是：

1. 有限的DB资源承载着不同业务，如何权衡资源保护和用户体验以应对可能的高流量？
2. 红包本身的业务特点使得容量模型复杂度高，如何准确地评估出大促峰值时刻的资源消耗？
3. 从狂换城、红包雨、到密令、C2C，支付宝红包承接了各种新的活动形式，今年红包承接了数倍于去年的发放和峰值支付量，而服务器/数据库资源未明显增加，如何优化性能支撑大促？

他们的解决办法基本基于这三个方面：

1. 性能：拆分vs合并、读写分离、异步化、DB操作优化等；
2. 容量评估：基于全链路的压测手段、数据分布的模拟方法、关键场景调用量预估方法；
3. 稳定性：限制流量、削峰、降级和体验的权衡

但是由于时间限制，支付宝架构师王俊主要是介绍了根据业务需求进行性能优化这部分内容

架构师王俊先介绍了双11中遇到的挑战（基本都是上面所说的那些），其次介绍支付宝红包的业务类型（因为架构是要基于业务来说，脱离业务的架构就是扯淡）并深度剖析了在发放、渲染、使用这二个典型阶段所遇到的技术难点，最后针对这些问题进行优化。

发放即发放红包、渲染即计算使用多种红包规则快速判断、使用则是金额支付

对于红包的商业模式，王俊总结了三个模式，个人红包、商户红包、天猫/淘宝红包。

1. 第一个模式，支付宝红包是要起到推广平台的作用，希望一定程度上形成对用户的黏性，最后它的钱是最终体现在各位的现金里面，使用是没有任何限制的，可以提现，也可以转为余额宝。
2. 第二个模式，就是商户发红包，这是存在商户让利，这跟商户的代金券、折扣券没有区别，商户让出权益给用户，用户购买物品的时候就会享受到一定的优惠，这个可能只能在商户或者是门店使用，而商户自己让利是没有真实资金流动的。商户门店类发红包，希望推广品牌提升它的黏性。
3. 第三种，这种形式资金的出让方是淘宝或者是天猫，也可能是在天猫上的商家。这些红包从发放的目的来讲，是希望能够促进交易的。

他选择的是商户红包这个场景来介绍细节优化。商户红包会同时有上百上千商家在发送红包，并且第一要求是钱不能发多，第二是能够支持海量发红包活动。

0.总体阶段

对于机房/连接池瓶颈，对硬件进行机房级拆分，即：

1. 本地化：一个机房包含一次业务请求的全部数据和服务器
2. 全站同分布：不同业务请求根据数据分布路由到不同机房；但是该业务请求，全链路的所有系统数据（有状态主体）数据分布相同
3. 共享数据副本：无法同分布的共享类数据读写分离，每个机房本地访问副本。

a.发红包阶段

由于金额数据需要存储在数据库，而主要瓶颈点在于与数据库的交互，优化前能够支持的能力是50tps，是远不够发送红包活动，那么他们接下来一系列工作就是围绕优化与数据库交互数据的能力

1. 获取数据库数据之前使用的是悲观锁，这里根据业务理解，改用乐观锁。50tps->800tps
2. 由于加锁时间主要消耗在网络交互，故对数据库读写进行优化，DB端更新后直接提交事务释放锁。800tps->4000tps
3. 到现在这个情况，单个数据库已经无法支撑更高的负荷，所以需要将预算集（因为这里发的是商家提供的预算，所以叫预算集）拆分成多个子预算集进行发送。4000tps->50000tps
4. 最后直接水平将多个预算子集水平拆分至多个机房，这样基本就能力实现了成倍增长

在上面第三个解决方案中，存在拆分后子集碎片问题（以及需要保持一致性）和子预算路由性能问题。

1. 对于子集碎片问题产生是因为发送到后来，肯定有的子集金额会很少，会造成钱还没发完，但是红包发不出去，这就是碎片问题。对于碎片问题，采用后台有定时补偿机制，即子集金额低于一定数值，就把子集进行合并，为了确保金额一致性，所以合并子集时，由一个唯一的控制点来进行合并控制管理。
2. 子预算路由问题，这里的问题主要是，子预算扣减的时候更新单点和子预算选择的时候需要查询单点。对于这两个单点能力问题，采用减轻负担和增加能力的方式进行优化。减轻负担，DB更新频率优化、读写分离、多级缓存；增加能力，索引优化、交互信息优化、数据分组。

b.渲染（红包使用）阶段

红包由于有非常多的种类，导致红包的使用规则维度非常大；另外由于使用红包也较频繁，所以也要保证计算红包使用的响应速度要快。这里的解决办法是对各种红包使用规则进行冗余、拆维、固化操作

（多个维度是指，红包使用会受到支付场景、使用时间、以及禁用商品三个影响，所以指多维度）

1. 冗余：少量的红包规则使用枚举的方式冗余、缓存
2. 拆维：不同规则，按照维度来拆分并存储
3. 固化：对常用的红包规则进行固化，并且压缩这种规则值域
4. 最后，对进行完上述三个操作后的数据，小量规则，利用缓存，尽量消除DB操作。

红包规则缓存这里，使用分级缓存。

1. 红包规则按照用户分库，模板分布在共享库中

2. 前面所说有三种红包，个人红包（C2C红包）、商户红包（商家红包）、天猫/淘宝红包（平台红包），不同的红包有不同的使用特征，依据不同特征采用不同方式缓存

个人红包（C2C红包）：数量巨大，预估接近百万级以上，但是信息简单、规则基本固定，采用字段冗余的方式。

天猫/淘宝红包（平台红包）：红包规则数量是可以枚举完的，但是其信息复杂且红包规则是需要可变，所以采用固定内存缓存方式

商户红包（商家红包）：数量级别估计为十万级别的压力，且商户类型众多，规则极为复杂，这里采用LRU内存缓存方式。

c.支付阶段

支付阶段就是使用红包，主要问题在于同时使用多个红包时会进行多次查询数据库。但是频繁查询数据库会降低性能，这里需要对其进行优化。

1. 应用层支持自己计算多个红包使用，使得更新每个红包余额时，只需1~2次SQL交互即可

以上便是支付宝红包在双11挑战中的实践