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