支付宝红包-双十一挑战与应对
个人详细理解已经整理好,链接地址
http://blog.csdn.net/qq_15437667/article/details/50963770
流程
红包发放-》查询红包-》红包渲染&支付
介绍内容:
链路梳理、性能优化、容量评估、业务量评估、系统保护
链路梳理:
硬件高频热点
红包内部热点:
存储分片热点、
数据库记录热点、
连接池/线程池依赖、
关键链路
优化
预算控制单点
乐观锁,从逻辑上处理;
数据库优化
预算单拆分,子预算集可以拆分:存在问题,碎片(定时合并,分布式合并,最后判断是单点),子预算路由性能
支付规则管理、模板数据跨库
单笔支付多红包
消费类红包
任何支付行为
脉脉
抢红包,
资金形式-,个人-》个人,个人-》多人
稳定性问题:
- 把各种金额渠道转换到红包中,
- 抢红包时参与者,
资金流变成
商户-》个人(商户资金已经准备好)
模式,三种
红包种类很多,纯粹现金、代金券等,平台券
定向红包,
环节
红包发起,展现,使用
业务挑战
海量容量,某一时刻,上百万能力,(期望低成本,需要极致优化,不仅仅是数据库、缓存,还需要链路上精简);
低成本
资金安全;
快速恢复能力,10分钟内快速恢复
三个阶段的问题
预算问题,两个问题:一红包不可以超发,二海量容量
展现,渲染:规则,定向到平台或者红包定向-》
使用阶段,用户的很多红包是在很多时候同时使用掉,(支付宝,一笔支付里支持10个红包)
预算问题
- 一致性问题,抽象出一个预算中心,强一致性;但是有的时候,没有强一致性。预算是否必须要发完,刚开始是单记录模式,瓶颈很大。支付宝刚开始是悲观锁,
优化点?mysql,修改patch,减少锁时间;减少网络(交互)开销,最后一次执行使用commit(应用层)。
单节点有上限,4000,故升级到多节点,
多记录的问题,预算是否用完。会把预算进行自动伸缩,定时检测,低于阈值合并。(遇到热点问题,需要手动规避)
使用数据库,肯定会受到数据库限制,;内存与数据库模式的优劣权衡。该patch有没有开源;会针对营销活动进行限流;热点预警;自动伸缩容,不能导致同样热点产生。
展现,渲染阶段
规则,规则是多维度,大概是一个三维维度,规则如何,使用分布式多级缓存。规则信息冗余在红包之上(冗余会导致难以修改,主要是针对个人进行冗余)。使用固定的内存缓存,淘宝、天猫,营销活动少,会将这种提前加载到内存中。对待商户,使用LRU的方式,规则离散,量巨大,。
支付问题、红包个数问题
根据红包个数问题,识别user属性,红包个数越多,消费越频繁
红包的支付个数,越多,产生的redo log越多。节约CQ环境,避开高峰期。
全局支付缓冲队列,异步化非关键SQL调用,SQL合并,批量SQL提交。
汇总任务游标化。需要有个任务回收红包。(任务越多,压力越大)尽量把任务拆的更碎,减少每次任务时间,增加任务频率。
还需要能够在线解决热点问题,自身异构保护
海量容量提升/验证手段
服务弹性伸缩,依赖阿里云
数据弹性伸缩,分库分表,读写分离,数据无限可伸缩,OceanBase,红包跑在该之上。
单元化,用户在访问支付宝,所有的请求,都会限定在一个逻辑机房内,尽量减少机房交互。机房级容灾,对应用连接有帮助
验证手段
全路径压测,影子手段方法,线上压测。通过这个发现系统中问题。
资金安全
事前体系
安全编码、一致性,
资金平衡,内部处理资金是平衡的,期望的值与实际值相等
调用下游系统,是不是我所希望的???
防篡改、CTU
工具花识别手段
事中体系
业务监控,识别流量是否产生暴增,能够分钟级之别到,
业务熔断,资金监控。
事后体系
秒级全路径核对(不能全部核对),T+1,T+H(实时核对)核对。
快速恢复机制
分层恢复机制,全力确保,分钟级恢复。
灰度是日常保证核心,一键容灾
双11保障:
提前预案,动态限流措施,非关键服务降级
应急预案,
活动监控维度,用户反馈非常重要。需要用小二快速回答为啥红包不可用。
- 最简化
- 数据化,数据分析
- 最精细,不能放过任何一个稳定性风险
- 最佳体验,产品体验的平衡。