微信红包的随机算法是怎样实现的？

我们在一个20人的群中，自己发红包以及结合其他人发出红包的情况，整合成两轮的数据。每次金额设置都是20块并且有20个，第一轮是发了15次，第二轮是发了19次，总结成表格，然后为了避免突发的数据影响判断，我们将两轮数据杂糅从而生成了其他的三轮数据，一共是五轮数据。罗列如下表，高亮的数据为最佳手气。每一列的数据最早抢到红包的在最底端，越往上越晚抢。

从所有黄色的数值（最佳手气金额）可看出，所有最佳手气值都在平均值*2的前后附近（平均值=总金额/红包总个数，这里平均值=20/20=1），事实上确实如此，可通过微信红包分发算法得到验证，算法具体见后文

然后我们选取部分数据开始制作散点图。横轴为1-20，分别表示抢到红包的人的编号，随递增而越早。也就是20代表最早抢到的人。纵轴为金额。同样的形状颜色的点代表一次发红包，然后我们抓取部分数据显示为散点图，越密集代表该顺序位的用户得到的金额越稳定。散点图如下：

规律一：我们可以看到，所有红包大多数金额分布在0.5到1.5元之间，显示为图中方框所示，大部分点都分布在这个位置。然后是顺序位密集程度的对比，可以发现20、19，也就是最先抢到红包的人，小圆圈所示基本的点都集中在小范围，说明先抢红包的人得到的金额会比较稳定，但同时最佳手气的概率也比较低。大圆圈所示的是极不稳定，飘忽的金额分布，表示越晚抢红包得到的金额会飘忽不稳，但同时，抢到最佳手气等大金额的红包概率也比早抢的高。

根据上面的分析，我们又写了一个过滤计数函数，针对金额的分段的红包个数进行统计：

比如2.0-2.5

得到如下金额分布：

折线图：

规律二：绝大多数的红包的金额都集中在1-1.5，也就是说20块钱发20个红包的金额分布集中在比平均数大一点点的附近，同时较大幅超过平均数金额的红包大大少于低于于平均数的红包数量。

那我们继续扩大数据的规模，将几轮数据的均值和标准差分别做成折线图：

综合上面各个折线图的情况，我们可以得到越早抢红包的标准差越小，越晚抢红包的标准差越大，但同时，由均值和总额可以看出来，越早抢红包的均值往往要更高，红包金额得到最佳手气概率也会相对较小，越晚抢红包的人则得到最佳手气等大手气的概率更大。

为了得到更为趋近规律的曲线和规律，我们决定将两轮真实数据合并起来，然后给出幂函数的趋近线（虚线），如下图：

由于均值受极值波动影响较大，所以我们去除一些因为偶然差产生的极端点（圆圈的点）从而发现是递增的趋势。

规律三：可以很明显的看到，均值是随着抢红包的越晚而缓慢递减，标准差值同时也往上递增，这个趋势结合之前的分析，我们猜想，即标准差越大说明，领取到最大的红包和最小红包的风险越大，也就是说越晚抢标准差越大，对于冒险主义者来讲是最好的，因为他有很大概率获得最大的金额，但也大概率获得最小的红包，风险与收益并存；均值越大，说明每次都拿到一个不大不小的红包，虽然获得最小和最大金额红包的概率很小，但起码不亏本，也就是说越早抢，均值越稳定，这比较适合不喜欢冒险的人。

验证预测结果：

21：24分　发送预测结果到另一位同学微信：

　

随后开始发红包：

结果：

最佳手气为第8个人且金额为1.13

与预测结果一致，规律基本正确！

总结：

（1）最佳手气为1.13块，根据我们推导的预测公式=总额/红包总个数*2*随机数（0-2的double数）, 也就是说最佳手气在总额/红包总个数*2值的前后附近。这里我们判断在0.8-1.3之间，推断正确

（2)平均值为0.5元，0.5-0.8元的红包有3个，小于0.5的红包有6个，说明大于平均值的红包个数多于小于平均值的个数。与我们的第二点预测完全正确

(3)最佳手气位置：根据我们的散点图发现，最先抢到红包的人，得到的金额会比较稳定，但同时最佳手气的概率也比较低。表示越晚抢红包得到的金额波动较大，但同时抢到最佳手气等大金额的红包概率也比早抢的高。所以我们推断，最佳手气位置在最后20%-30%之间。

微信红包随机分发算法c＋＋模拟：

基本思路：每次抢到一个红包金额等于：红包剩余金额/红包剩余个数*2*随机数（0-1的double型），如果计算的结果小于等于0.01，则取0.01值

主要代码：

double packages[50000]

double Luckiest_money=0

void getPackage(int remainSize,double remainMoney){

srand((unsigned)time(NULL))

for(int i=0i

在数据库中增加一条红包记录，存储到CKV，设置过期时间；

在Cache（可能是腾讯内部kv数据库，基于内存，有落地，有内核态网络处理模块，以内核模块形式提供服务））中增加一条记录，存储抢红包的人数N抢红包后台 *** 作：

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

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

微信红包是腾讯旗下产品微信于2014年1月27日推出的一款应用，功能上可以实现发红包、查收发记录和提现。当用户抢红包时，实际是把资金抢到了腾讯的一个虚拟数据库中，并没有到用户账户中去。如果是不能发，说明你并没有通过本人的实名认证绑定yhk，或者是没有设置支付密码。你需要通过本人的实名认证绑定yhk后才能发红包。

---