一、红包系统的业务场景
红包场景的业务处理流程：
- 包红包：需要查询用户账户金额，需要调用账户查询服务
- 发红包：需要红包服务生成红包订单id
- 抢红包：通过红包订单id实时生成单笔金额凭证
- 拆红包：有两条处理主线，一个是实时计算抢购红包金额，一个是发送方和接收方的转账操作
二、红包系统的技术和架构特点
红包系统的数据读写特点是：写多读少
瞬时对DB和cache的请求并发量非常大，需要解决的是高并发的问题
对于涉及资金的业务，需要考虑资损和异常处理的方案，即需要较高的可靠性保障
在拆红包时，红包金额显示和转账操作可以异步化，即信息流和资金流可以分离
三、整体方案设计
1.业务逻辑层
- 多实例服务和负载均衡策略
部署多实例的红包服务，提升服务的处理能力，有状态的信息抽取到分布式缓存中，在进行服务路由的时候，可以选择红包订单号进行路由，便于后期红包算法的实现。
- 双缓存策略
选择构建本地缓存和分布式缓存双缓存的方案，redis做分布式缓存，主要用来保存全局缓存数据，包括用户信息和群组信息等，本地缓存主要用来保存中间值或状态信息，在红包系统中保存发出的红信息、抢购的红包信息等；
抢红包环节是流量最大的环节，将红包信息预先加载到cache中来，这样就不用再请求DB，降低对DB的压力；
- 异步处理
由于在拆红包的时候并发量肯定非常大，但其实用户首先关注的只是抢到红包的金额等信息，实际钱包中的到账金额不会实时关注，所以抢购的红包信息，比如抢购金额等呈现是同步计算的，但钱包金额转账操作可以异步操作；
2.数据存储层
- 分布分表方案
红包服务需要重点解决的问题就是并发请求量过大，分库是常见的解决方案，可以按照订单号进行分库，将原集中在一个数据库的数据分散到多个数据库，势必会降低对单库的访问压力；
在设计分库的时候需要考虑分片键，在红包场景下可以使用红包订单号来做分片键。
3.异常处理方案
- 流控和降级策略
在发红包的时候处理好流量控制，流量过大需要有流量降级的策略。
- 异常记录入库，后续人工补偿
数据写入失败记录入库，后期人工核查和补账；
- 风控措施
涉及到资金的业务，可能就存在黑产等风险，需要引入风控措施；
4.部署方案
- 集群部署
按照上述的方案，业务服务需要做集群部署，同样数据库服务也需要做集群部署；一方面是提升并发处理的性能，另一份方面是避免单点故障，提高可靠性。
四、重点问题的解决方案
红包生成算法
本地缓存做拆红包的实时处理，红包订单做key，利用redis的原子性做红包分拆的实时处理；红包金额在0.01~剩余用户平局值*2之间
故障处理思路
缓存故障则降级到访问数据库；
实时处理出问题则异步补偿，异步补偿出问题则记录问题，后续凭记录手动补账
五、总结
- 红包的业务场景主要是：包红包-->发红包-->抢红包-->拆红包
- 技术和架构特点：多写少读的场景，瞬时并发量比较大，拆红包和转账可以异步执行，可以实现双缓存操作
- 解决高并发的方案：服务多实例，按照订单号进行动态路由；实现双缓存设计，热点数据可以提前预热；红包算法在内存中进行实时计算；
- 提升高可用的方案：利用异步机制将拆红包和转账操作异步化；利用流控和降级措施避免服务不可用的场景出现；人工干预有问题的记录；对计划内风险因素做好规划和定时处理，计划外风险因素做好演练和预案；
本文由博客一文多发平台 OpenWrite 发布！
