春晚微信红包案例

Recent Pages

春晚微信红包案例

最后更新时间：2024-12-18 16:08:11

春晚红包活动涉及四个大型系统的联动，包括微信、微信支付、红包系统和财付通系统。以下简单介绍各个系统：
红包系统：个人红包的发、抢、拆和列表查看；
财付通系统：包括支付订单、异步入账流水的高性能存储，用户余额和账单的实时展示；
微信接入：确保微信用户公网接入的质量；
微信支付：在线交易的入口。
﻿
类似红包系统的分布式事务是关注的热点。举一个典型的例子，『用户 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消息队列保证了红包消息的可靠存储、传递，实时写三份保证数据不丢。资金入账失败时可多次重试，避免失败回滚和频繁轮询数据库等传统方式的弊端。