微信红包分配算法

A. 微信红包的随机算法是怎样的

1）红包大小服从截尾正态分布，其好处是减少抽取红包大小分布的方差，让更多的人抽取的红包在均值附近，同时仍给一小部分人抽取大红包的机会，总体来说增加了红包抽取人的积极性和游戏的公平性；
2）抽取红包大小与抽取红包先后无相关性。一种可能的红包产生机制是：当发红包者<准备红包>的时候，程序自动依照截尾分布产生了相应大小，相应个数的红包，然后随机发给抽取红包的人。同样，这样的一个随机过程有助于增加游戏的公平性，也减少了红包抽取人投机操作。

钱包钱数满足截尾正态随机数分布。大致为在截尾正态分布中取随机数，并用其求和数除以总价值，获得修正因子，再用修正因子乘上所有的随机数，得到红包价值。

这种分布意味着：低于平均值的红包多，但是离平均值不远；高于平均值的红包少，但是远大于平均值的红包

B. 微信中发红包时怎么平均分配

微信红包有两种，一种就是拼手气红包，还有一种就是普通红包，普通红包就属于平均分配！

C. 微信群里面发红包，群里成员领到的红包金额是怎么计算的，是随机的还是怎么来的

摘要 这个的话主要是看你发的是什么红包的。假如说你发的一个红包设置为可以6个人抢。这样的话里面的钱就会被随机分配的，一般的话都是随机分配。

D. 微信红包金额怎么分配

微信红包分两种：
1、单独发给一个人的，红包都归个人；
2、红包发到群里的，会随机分配；
但根据个人发红包的经验，头两个和倒数四到五个，通常拿不到最大的红包。
最容易拿到大红包的，是倒数第一第二，通常都是手气最佳。
根据个人的经验。

E. 微信红包怎么平均分配

摘要 1.微信红包要平均分，只需要发普通红包即可。

F. 微信红包如何等分金额

发红包时左上角有个选项1是拼手气红包，2是普通红包，3是专属红包，
选择普通红包，发多少个。每个多少钱，按照选项操作就行。
希望能帮助到你

G. 微信红包怎么分配金额大小

微信红包的分配大小是系统自动分配的。没有办法进行人工的参与，网上买的一些。可以保证你抢到大红包的软件都是骗人的，不要相信

H. 随机红包金额如何决定的

从工程角度来说，红包分配算法需要简单粗暴的实现。

有些人的算法过于复杂，第几个人领取都要面面俱到的计算，考虑因素太多，工程实现上真的没必要。
其实只需要按照如下框架即可：

1. 发红包时，按照设计的快速随机算法，将红包分好若干份。

2. 按照设计的评估算法，对得到的红包分配进行校验。

3. 如果校验不通过，如贫富差距过大，则重复随机分配。

4. 如果若干次重复，如5次，则停止重复，就按照当前分配。

5. 再有用户请求红包，直接队列化请求，再从红包序列中取出对应编号红包。

上述方案的优势是：
1. 只需“一次”计算。

随机算法选择简单粗暴的即可，系统按照校验策略对其评价，不满足则有限次重复，直到满足或次数太多为止。

2. 此后就只有读取。

后续操作完全是读取缓存，无需密集计算。

那么是不是还有更简单粗暴的方案呢?还是有的，那就是伪随机序列查表法。

百万千万级别的红包请求，如果每次都按照真随机来计算，仍然会有不小的计算压力。

索性预先计算得到若干伪随机分配方案，调用时只需要随机选择一个即可。
举例来说，有人的红包是10元分配给5人，系统预先存有多种分配方案，如1，1，2，3，3，或1，1，2，2，4，请求时随机选取一个方案即可。

当然，各种组合未必能穷尽，但是只需要让用户在有限次操作中觉得这是随机就够了。
(8)微信红包分配算法扩展阅读
微信红包是腾讯旗下产品微信于2014年1月27日推出的一款应用，功能上可以实现发“红包”、查收发记录和提现。

2014年4月14日，“安卓手机用户只要用微信扫描身边出现的红色二维码，通过腾讯应用宝成功安装其他应用软件，即可领取微信红包。

2019年2月10日，微信官方发布2019年春节数据报告，除夕到初五，8.23亿人次收发微信红包。
设计简单

在“微信红包”这个功能的设计上，遵循了简单的原则。发送方通过“新年红包”公众号，选择发送红包的数量和金额，以及祝福的话语，通过“微信支付”进行支付，就可以发送给好友；接收方则在打开后获得相应收益，只需要将储蓄卡与微信关联，就可以在一个工作日后提现。2014年1月27日前，用户在抢红包之前，要先写上祝福，然后才可以抢。在这之后，已经改为先抢红包再发送祝福的过程。

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

当有人在微信群里发了一个 N 人的红包、总金额 M 元，后台大概的技术逻辑如下。

发红包后台操作：

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

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

抢红包后台操作：

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

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