微信红包体系设计分析

>>>max = (remain_money/remain_num)*2

而摇一摇红包官方给出的计算公式是剩余金额/剩余红包数*n

n主观猜测也是等于2，在这公司基础上再人为控制概率。

方案一：

人为干扰概率的，有人拿到京东618元的红包，动脑子想想，京东店庆是618，这个金额绝对不是随机出来的，而是设定好金额，然后每个金额范围都有一定的概率。

比如说2元—5元概率为85%;5元—20元概率为10%，20元—50元概率为4.99%，618元概率为0.01%。(概率仅作参考，因为样本量太大，官方也没提供数据，这里只是提供其中一种可行的方案，以下代码也只是提供思路，与实际可运行的代码略有差别)

>>>a = random.uniform(0,1)

>>>b,_max,_min = 0

>>>if a < 0.85:

_min = 2.00

_max = 5.00

>>>elif a < 0.95 & a >= 0.85:

_min = 5.00

_max = 20.00

>>>elif a < 0.9999 & a >= 0.95:

_min = 20.00

_max = 50.00

>>>elif a > 0.9999:

_min = 618.00

_max = 618.00

>>>random.uniform(min,max)

方案二：

_min = 2.00

_max = 剩余金额/剩余红包数*n

人为放出618元的彩蛋红包，并且用上述方法设置概率为0.0001%

4.3红包发出去那一刻发生了什么?

这一部分由于个人的水平限制，未能给出有深度的简介，这里为了文章的完整性，借用胖胖的文章作为说明(胖胖的博客为www.phppan.com)

(1)发红包后台操作：

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

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

(2)抢红包后台操作：

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