SSDC_支付宝红包-双十一挑战与应对

支付宝红包-双十一挑战与应对

个人详细理解已经整理好，链接地址

http://blog.csdn.net/qq_15437667/article/details/50963770

流程

红包发放-》查询红包-》红包渲染&支付

介绍内容：

链路梳理、性能优化、容量评估、业务量评估、系统保护

链路梳理：

硬件高频热点

红包内部热点：

存储分片热点、

数据库记录热点、

连接池/线程池依赖、

关键链路

优化

预算控制单点

乐观锁，从逻辑上处理；

数据库优化

预算单拆分，子预算集可以拆分：存在问题，碎片（定时合并，分布式合并，最后判断是单点），子预算路由性能

支付规则管理、模板数据跨库

单笔支付多红包

消费类红包

任何支付行为

脉脉

抢红包，

资金形式-，个人-》个人，个人-》多人
稳定性问题：

1. 把各种金额渠道转换到红包中，
2. 抢红包时参与者，

资金流变成
商户-》个人（商户资金已经准备好）

模式，三种

红包种类很多，纯粹现金、代金券等，平台券

定向红包，

环节

红包发起，展现，使用

业务挑战

海量容量，某一时刻，上百万能力，（期望低成本，需要极致优化，不仅仅是数据库、缓存，还需要链路上精简）；
低成本
资金安全；
快速恢复能力，10分钟内快速恢复

三个阶段的问题

预算问题，两个问题：一红包不可以超发，二海量容量

展现，渲染：规则，定向到平台或者红包定向-》

使用阶段，用户的很多红包是在很多时候同时使用掉，（支付宝，一笔支付里支持10个红包）

预算问题

1. 一致性问题，抽象出一个预算中心，强一致性；但是有的时候，没有强一致性。预算是否必须要发完，刚开始是单记录模式，瓶颈很大。支付宝刚开始是悲观锁，

优化点？mysql，修改patch，减少锁时间；减少网络（交互）开销，最后一次执行使用commit（应用层）。

单节点有上限，4000，故升级到多节点，

多记录的问题，预算是否用完。会把预算进行自动伸缩，定时检测，低于阈值合并。（遇到热点问题，需要手动规避）

使用数据库，肯定会受到数据库限制，；内存与数据库模式的优劣权衡。该patch有没有开源；会针对营销活动进行限流；热点预警；自动伸缩容，不能导致同样热点产生。

展现，渲染阶段

规则，规则是多维度，大概是一个三维维度，规则如何，使用分布式多级缓存。规则信息冗余在红包之上（冗余会导致难以修改，主要是针对个人进行冗余）。使用固定的内存缓存，淘宝、天猫，营销活动少，会将这种提前加载到内存中。对待商户，使用LRU的方式，规则离散，量巨大，。

支付问题、红包个数问题

根据红包个数问题，识别user属性，红包个数越多，消费越频繁

红包的支付个数，越多，产生的redo log越多。节约CQ环境，避开高峰期。

全局支付缓冲队列，异步化非关键SQL调用，SQL合并，批量SQL提交。

汇总任务游标化。需要有个任务回收红包。（任务越多，压力越大）尽量把任务拆的更碎，减少每次任务时间，增加任务频率。

还需要能够在线解决热点问题，自身异构保护

海量容量提升/验证手段

服务弹性伸缩，依赖阿里云

数据弹性伸缩，分库分表，读写分离，数据无限可伸缩，OceanBase，红包跑在该之上。

单元化，用户在访问支付宝，所有的请求，都会限定在一个逻辑机房内，尽量减少机房交互。机房级容灾，对应用连接有帮助

验证手段

全路径压测，影子手段方法，线上压测。通过这个发现系统中问题。

资金安全

事前体系

安全编码、一致性，

资金平衡，内部处理资金是平衡的，期望的值与实际值相等

调用下游系统，是不是我所希望的？？？

防篡改、CTU

工具花识别手段

事中体系

业务监控，识别流量是否产生暴增，能够分钟级之别到，

业务熔断，资金监控。

事后体系

秒级全路径核对（不能全部核对），T+1，T+H（实时核对）核对。

快速恢复机制

分层恢复机制，全力确保，分钟级恢复。

灰度是日常保证核心，一键容灾

双11保障：

提前预案，动态限流措施，非关键服务降级

应急预案，

活动监控维度，用户反馈非常重要。需要用小二快速回答为啥红包不可用。

• 最简化
• 数据化，数据分析
• 最精细，不能放过任何一个稳定性风险
• 最佳体验，产品体验的平衡。