根据历史经验，实现的功能越复杂，依赖会变多，对应的稳定性风险就越高，那么如何保证高依赖的系统稳定性呢？
解决方案：
现金红包入账最基础要保障的功能是将用户得到的红包进行入账，同时支持幂等与预算控制（避免超发），红包账户的幂等设计强依赖数据库保持事务一致性。但是如果极端情况发生，中间的链路可能会出现问题，如果是弱依赖需要支持降级掉，不影响发放主流程。钱包方向发红包最短路径为依赖服务实例计算资源和 MySQL 存储资源实现现金红包入账。
发红包强弱依赖梳理图示：
psm | 依赖服务 | 是否强依赖 | 降级方案 | 降级后影响 |
资产中台 | tcc | 是 | 降级读本地缓存 | 无 |
bytkekv | 否 | 主动降级开关，跳过 bytekv，依赖下游做幂等 | 无 | |
资金交易层 | 分布式锁 | 否 | 被动降级，调用失败，直接跳过 | 基本无 |
token | 否 | 主动降级开关，不调用 Redis | 用户能感知到入账有延迟，会有很多客诉 | |
MySQL | 是 | 主有问题，联系 dba 切主 | 故障期间发红包不可用 |
需求背景：
春节活动除夕晚上 7 点半会开始烟火大会，是大流量集中发券的一个场景，钱包侧与算法策略配合进行卡券发放库存控制，防止超发。
具体实现：
（1）钱包资产中台维护每个卡券模板 ID 的消耗发放量。
（2）每次卡券发放前算法策略会读取钱包 sdk 获取该卡券模板 ID 的消耗量以及总库存数。同时会设置一个阈值，如果卡券剩余量小于 10%后不发这个券（使用兜底券或者祝福语进行兜底）。
（3） 同时钱包资产中台方向在发券流程累计每个券模板 ID 的消耗量（使用 Redis incr 命令原子累加消耗量），然后与总活动库存进行比对，如果消耗量大于总库存数则拒绝掉，防止超发，也是一个兜底流程。
具体流程图：
优化方向：
（1）大流量下使用 Redis 计数，单 key 会存在热 key 问题，需要拆分 key 来解决。
（2）大流量场景下操作 Redis 会存在超时问题，返回上游处理中，上游继续重试发券会多消耗库存少发，本次春节活动实际活动库存在预估库存基础上加了 5%的量级来缓解超时带来的少发问题。
4.5 难点五：高 QPS 场景下的热 key 的读取和写入稳定性保障需求背景：
在除夕晚上 7 点半开始会开始烟火大会活动，展示所有红包雨与烟火大会红包的实时累计发放总额，最大流量预估读取有 180wQPS，写入 30wQPS。
这是典型的超大流量，热点 key、更新延迟不敏感，非数据强一致性场景（数字是一直累加），同时要做好容灾降级处理，最后实际活动展示的金额与产品预计发放数值误差小于 1%。
提供 sdk 接入方式，复用了主会场机器实例的资源。高 QPS 下的读取和写入单 key，比较容易想到的是使用 Redis 分布式缓存来进行实现，但是单 key 读取和写入的会打到一个实例上，压测过单实例的瓶颈为 3w QPS。所以做的一个优化是拆分多个 key，然后用本地缓存兜底。
具体写入流程：
设计拆分 100 个 key，每次发红包根据请求的 actID0 使用 incr 命令累加该数字，因为不能保证幂等性，所以超时不重试。
读取流程：
与写入流程类似，优先读取本地缓存，如果本地缓存值为为 0，那么去读取各个 Redis 的 key 值累加到一起，进行返回。
