文档中心 消息队列 CMQ 案例分享 春晚微信红包案例

春晚微信红包案例

最近更新时间:2019-08-01 11:06:07

春晚红包活动涉及四个大型系统的联动,包括微信、微信支付、红包系统和财付通系统。以下简单介绍各个系统:

  • 红包系统:个人红包的发、抢、拆和列表查看;
  • 财付通系统:包括支付订单、异步入账流水的高性能存储,用户余额和账单的实时展示;
  • 微信接入:确保微信用户公网接入的质量;
  • 微信支付:在线交易的入口。

类似红包系统的分布式事务是关注的热点。举一个典型的例子,『用户A给用户B发了10元的红包』,有以下步骤:
1) 从A帐号中把余额读出来
2) 对A帐号做减法操作(减10元)
3) 把结果写回A帐号中(一次确认)
4) 从B帐号中把余额读出来
5) 拆开A发送给B的红包,读出数值
6) 对B帐号做加法操作(加10元)
7) 把结果写到B帐号中

为了保证数据的一致性,上述步骤只有两种结果:都成功完成或者都不成功执行回滚。而且这个操作的过程中,对A、B帐号还需引入分布式锁机制来避免脏数据的问题。在微信红包这个庞大的分布式集群内,事情将变的异常复杂。

微信红包系统引入了腾讯云 CMQ 以避免分布式事务增加对系统的开销。同样A用户给B用户发10元红包的场景,下面介绍引入 CMQ 后的新策略。

  • 在上述案例中的第七步,B 用户拆开了红包,红包里有10块钱。在做最后的入账操作时由于当天并发压力大,常出现入账失败的情况。
  • 红包团队把入帐失败的请求,全部转入CMQ。当B用户更新账户余额失败时,手机客户端显示等待状态。随后账户系统将不断从 CMQ 重新拉取重试此更新操作。CMQ 保证了这 10 元的入账消息永远不丢,直至它被取出。
  • 在除夕当天,用户红包的发、拆、入账等动作,转化为了十亿级别的海量请求。若使用传统的事务方式,会放大并发压力使系统崩溃。
  • CMQ消息队列保证了红包消息的可靠存储、传递,实时写三份保证数据不丢。资金入账失败时可多次重试,避免失败回滚和频繁轮询数据库等传统方式的弊端。