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