春晚红包活动涉及四个大型系统的联动,包括微信、微信支付、红包系统和财付通系统。以下简单介绍各个系统:
- 红包系统:个人红包的发、抢、拆和列表查看;
- 财付通系统:包括支付订单、异步入账流水的高性能存储,用户余额和账单的实时展示;
- 微信接入:确保微信用户公网接入的质量;
- 微信支付:在线交易的入口。
类似红包系统的分布式事务是关注的热点。举一个典型的例子,『用户 A 给用户 B 发了10美元的红包』,有以下步骤:
- 从 A 帐号中把余额读出来
- 对 A 帐号做减法操作(减10美元)
- 把结果写回A帐号中(一次确认)
- 从 B 帐号中把余额读出来
- 拆开 A 发送给 B 的红包,读出数值
- 对 B 帐号做加法操作(加10美元)
- 把结果写到 B 帐号中
为了保证数据的一致性,上述步骤只有两种结果:都成功完成或者都不成功执行回滚。而且这个操作的过程中,对 A、B 帐号还需引入分布式锁机制来避免脏数据的问题。在微信红包这个庞大的分布式集群内,事情将变的异常复杂。
微信红包系统引入了腾讯云 CMQ 以避免分布式事务增加对系统的开销。同样A用户给B用户发10美元红包的场景,下面介绍引入 CMQ 后的新策略。
- 在上述案例中的第七步,B 用户拆开了红包,红包里有10块钱。在做最后的入账操作时由于当天并发压力大,常出现入账失败的情况。
- 红包团队把入帐失败的请求,全部转入CMQ。当B用户更新账户余额失败时,手机客户端显示等待状态。随后账户系统将不断从 CMQ 重新拉取重试此更新操作。CMQ 保证了这 10 美元的入账消息永远不丢,直至它被取出。
- 在除夕当天,用户红包的发、拆、入账等动作,转化为了十亿级别的海量请求。若使用传统的事务方式,会放大并发压力使系统崩溃。
- CMQ消息队列保证了红包消息的可靠存储、传递,实时写三份保证数据不丢。资金入账失败时可多次重试,避免失败回滚和频繁轮询数据库等传统方式的弊端。
本页内容是否解决了您的问题?