微信红包机制浅析

春节到了，抢红包这一全民运动再次兴起。昨天看到了B站up毕导发的《如何抢到大红包》这一视频，因此我想简单的分析一下微信红包机制。毕导在两年前的一次演讲中就谈到了这一问题，他又炒了一次冷饭。

微信红包架构

当有人在群里发了一个N人的红包，总金额M元，后台大概发生的事情如下：

发红包

在数据库中增加一条红包记录，存储到CKV，设置过期时间；
在Cache（可能是腾讯内部kv数据库，基于内存，有落地，有内核态网络处理模块，以内核模块形式提供服务））中增加一条记录，存储抢红包的人数N

抢红包

此操作分为抢和拆两部分

抢

抢操作在Cache层完成，通过原子减操作进行红包数递减，到0就说明抢光了，最终实际进入后台拆操作的量不大，通过操作的分离将无效请求直接挡在Cache层外面。这里的原子减操作并不是真正意义上的原子减操作，是其Cache层提供的CAS，通过比较版本号不断尝试，存在一定程度上的冲突，冲突的用户会放行，让其进入下一步拆的操作，这也解释了为啥有用户抢到了拆开发现领完了的情况。

拆

拆红包在数据库完成，通过数据库的事务操作累加已经领取的个数和金额，插入一条领取流水，入账为异步操作，这也解释了为啥在春节期间红包领取后在余额中看不到。拆的时候会实时计算金额，其金额为1分到剩余平均值2倍之间随机数，一个总金额为M元的红包，最大的红包为 M * 2 /N（且不会超过M），当拆了红包后会更新剩余金额和个数。财付通按20万笔每秒入账准备，实际只到8万每秒。

以上即为微信红包的简要架构，我们所要知道的一点就是：每个人能抢到的金额，服从0.01到二倍剩余均值间的均匀分布。所以理论上后抢出大包的概率大，抢红包时应该先憋一会儿，去抢那个最大的。但是憋久了那就。。。