微信红包的随机算法是怎样实现的？
核心思路：怎么让钱分得“不均匀”？
咱们都知道，微信红包有个特点，就是发出去的钱，每个人抢到的金额都不一样，有的人多，有的人少，这才叫“随机”。这背后的算法，本质上就是要在一个总金额里，切出好多小份，然后按照某种“不确定性”的规则分发出去。
想象一下，你手里有一根绳子，总长是100块钱，你要把它剪成几段，让别人来拿。怎么剪才显得随机呢？不是随便一剪就能行的，得有点讲究。
第一招：确定“总金额”和“红包个数”
这是最基础的。你发一个红包，设定了总金额（比如100块）和红包个数（比如10个）。那么，平均每个红包就是10块。但咱们要的不是平均，是随机。
第二招：生成“随机数”作为分配的“种子”
这就像是你用一个不知道会出什么点数的骰子来决定怎么分。微信服务器在生成红包的时候，会用一些信息来生成一个随机数。这些信息可能包括：
当前系统时间： 时间在不断变化，哪怕是很微小的毫秒级差异，都能产生不同的随机数。
用户ID： 每个人的ID都不同，这个ID也可以参与到随机数的生成中。
设备信息： 手机的一些唯一标识符，比如IMEI（虽然现在出于隐私考虑，获取IMEI越来越难了）。
其他更复杂的加密算法： 为了安全和防止作弊，微信肯定会用一些更成熟、更难预测的加密算法来生成高质量的随机数。
这些信息就像是“随机种子”，用来启动一个“随机数生成器”。
第三招：按“比例分配”的思路
有了随机数，怎么用它来分钱呢？核心是 “比例分配”。
举个例子，你要发100块钱，分成10个红包。这个算法有点像是在一个长为100的区间里，随机地“打点”，而点数越多，这个区间分到的钱就越多。
更具体一点说，微信可能用一种叫做 “步长法” 或者 “比例分割法” 的思路来处理：
1. 计算平均值： 每个红包的平均值是 `总金额 / 红包个数`。
2. 生成随机比例因子： 算法会根据前面生成的随机数，生成一系列的“比例因子”。这些因子加起来大概等于1（或者一个总的比例值）。
3. 计算每个红包的金额： 用总金额乘以这些比例因子，就能得到每个红包的实际金额。
比如，你有100块钱，要发10个红包。
平均每个是10块。
算法可能会生成10个随机数，这些随机数被处理后，得到10个比例因子，例如：0.8, 1.2, 0.7, 1.5, 0.9, 1.1, 1.0, 0.6, 1.3, 0.9。 （这只是举例，实际的比例因子会有一个更复杂的生成过程，并且需要保证总和接近1，然后乘以总金额再做处理）
然后用总金额100去乘以这些因子（这里为了简化说明，我们假设这些因子已经过处理，加起来等于10），再进行取整等操作，最终得到10个红包的金额。
更深入一点：指数分布的妙用
为了让红包金额分布更接近我们体验到的那种“有人多有人少”的感觉，微信很可能用到了 指数分布 的思想。
简单来说，指数分布的特点是：
概率集中在较小的值上： 这意味着大部分红包金额会比较小，比较常见。
少量大金额红包出现的概率也存在： 但出现的几率相对较低。
这就解释了为啥咱们抢红包的时候，大部分都是几分钱、几毛钱，偶尔才能抢到一块钱以上的。
算法大概是这样工作的：
1. 生成一个随机数 `r`： 这个 `r` 通常在 0 到 1 之间。
2. 计算红包金额： 红包金额 `m` 可以用公式表示，比如 `m = (总金额 / k) ln(1 / r)`，其中 `k` 是红包个数。这个公式经过调整，可以得到符合指数分布的随机金额。
你可以想象，当 `r` 非常接近 1 的时候（比如 0.999），`ln(1/r)` 的值就非常小，对应的红包金额也很小。而当 `r` 非常接近 0 的时候（比如 0.001），`ln(1/r)` 的值就非常大，对应的红包金额就会很大。
重点来了：保证“不重复”和“总金额准确”
既然是分钱，有两个关键点必须保证：
所有红包加起来等于总金额： 这个是绝对不能错的。在生成完所有红包金额后，算法会进行一个校验和微调，确保总和是准确的。
每个红包的金额是唯一的（或高度不重复）： 这正是随机的魅力所在。通过前面提到的随机数生成和分布算法，可以保证这一点。
抢红包的“先后顺序”也很重要！
你可能还注意到，同一个红包，不同时间去抢，抢到的金额可能也不一样。这是因为当第一个人抢的时候，剩余的金额会重新进行一次“随机分配计算”。
举个例子：
发100块钱，10个红包。
第一次抢的人，会从100块钱里，按照前面提到的算法，分配一个随机金额给他。
第二次抢的人，就会从 剩余的金额 (比如 100 第一次抢到的金额) 里，再按照算法分配一个随机金额。
这个过程一直持续到最后一个红包被抢完。所以，你抢红包的“时机”，也直接影响到你分到的金额。
总结一下
微信红包的随机算法，不是简单的“瞎分一通”。它背后是一个精心设计的、基于数学模型（比如指数分布）的算法，通过高质量的随机数生成，再结合比例分配和步长计算等方式，来生成一系列不重复且总和准确的随机金额。这个过程既保证了用户体验的趣味性，也确保了资金的准确分配。
这玩意儿说起来，就像是个聪明的“分钱大师”，知道怎么分才能让大家觉得“有意思”，又能把钱分得明明白白。
网友意见
有人问过微信的人，大致是这样：
先上代码：
public static double getRandomMoney(RedPackage _redPackage) { // remainSize 剩余的红包数量 // remainMoney 剩余的钱 if (_redPackage.remainSize == 1) { _redPackage.remainSize--; return (double) Math.round(_redPackage.remainMoney * 100) / 100; } Random r = new Random(); double min = 0.01; // double max = _redPackage.remainMoney / _redPackage.remainSize * 2; double money = r.nextDouble() * max; money = money <= min ? 0.01: money; money = Math.floor(money * 100) / 100; _redPackage.remainSize--; _redPackage.remainMoney -= money; return money; } 以上代码仅供参考，涉及商业计算要用java.math.BigDecimal. 感谢 @xin lu、 @秦时明月 指出。
再说结论：
- 先抢后抢拿到红包的大小的期望是大致相等的，所以还是先下手抢吧
- 后抢的人方差大（依赖前面人抢的多少），波动较大，有较大几率拿到“手气最佳”
祝大家抢红包快乐哦~
测试数据。
测试结果测试随机红包
以上面的初始化数据（30人抢500块），执行了两次，结果如下：
// 第一次 15.69 21.18 24.11 30.85 0.74 20.85 2.96 13.43 11.12 24.87 1.86 19.62 5.97 29.33 3.05 26.94 18.69 34.47 9.4 29.83 5.17 24.67 17.09 29.96 6.77 5.79 0.34 23.89 40.44 0.92 // 第二次 10.44 18.01 17.01 21.07 11.87 4.78 30.14 32.05 16.68 20.34 12.94 27.98 9.31 17.97 12.93 28.75 12.1 12.77 7.54 10.87 4.16 25.36 26.89 5.73 11.59 23.91 17.77 15.85 23.42 9.77 对应图表如下：
还有一张：
多次均值
200次
2000次
可以看到，这个算法可以让大家抢到的红包面额在概率上是大致均匀的。
转一下原文
微信红包的架构设计简介
@来源于QCon某高可用架构群整理，整理朱玉华。
背景：有某个朋友在朋友圈咨询微信红包的架构，于是乎有了下面的文字（有误请提出，谢谢）
概况：2014年微信红包使用数据库硬抗整个流量，2015年使用cache抗流量。
1. 微信的金额什么时候算？
答：微信金额是拆的时候实时算出来，不是预先分配的，采用的是纯内存计算，不需要预算空间存储。
采取实时计算金额的考虑：预算需要占存储，实时效率很高，预算才效率低。
2. 实时性：为什么明明抢到红包，点开后发现没有？
答：2014年的红包一点开就知道金额，分两次操作，先抢到金额，然后再转账。
2015年的红包的拆和抢是分离的，需要点两次，因此会出现抢到红包了，但点开后告知红包已经被领完的状况。进入到第一个页面不代表抢到，只表示当时红包还有。
3. 分配：红包里的金额怎么算？为什么出现各个红包金额相差很大？
答：随机，额度在0.01和(剩余平均值*2)之间。
例如：发100块钱，总共10个红包，那么平均值是10块钱一个，那么发出来的红包的额度在0.01元～20元之间波动。
当前面3个红包总共被领了40块钱时，剩下60块钱，总共7个红包，那么这7个红包的额度在：0.01～（60/7*2）=17.14之间。
注意：这里的算法是每被抢一个后，剩下的会再次执行上面的这样的算法（Tim老师也觉得上述算法太复杂，不知基于什么样的考虑）。
这样算下去，会超过最开始的全部金额，因此到了最后面如果不够这么算，那么会采取如下算法：保证剩余用户能拿到最低1分钱即可。
如果前面的人手气不好，那么后面的余额越多，红包额度也就越多，因此实际概率一样的。
4. 红包的设计
答：微信从财付通拉取金额数据过来，生成个数/红包类型/金额放到redis集群里，app端将红包ID的请求放入请求队列中，如果发现超过红包的个数，直接返回。根据红包的逻辑处理成功得到令牌请求，则由财付通进行一致性调用，通过像比特币一样，两边保存交易记录，交易后交给第三方服务审计，如果交易过程中出现不一致就强制回归。
5. 发性处理：红包如何计算被抢完？
答：cache会抵抗无效请求，将无效的请求过滤掉，实际进入到后台的量不大。cache记录红包个数，原子操作进行个数递减，到0表示被抢光。财付通按照20万笔每秒入账准备，但实际还不到8万每秒。
6. 通如何保持8w每秒的写入？
答：多主sharding，水平扩展机器。
7. 据容量多少？
答：一个红包只占一条记录，有效期只有几天，因此不需要太多空间。
8. 询红包分配，压力大不？
答：抢到红包的人数和红包都在一条cache记录上，没有太大的查询压力。
9. 一个红包一个队列？
答：没有队列，一个红包一条数据，数据上有一个计数器字段。
10.有没有从数据上证明每个红包的概率是不是均等？
答：不是绝对均等，就是一个简单的拍脑袋算法。
11.拍脑袋算法，会不会出现两个最佳？
答：会出现金额一样的，但是手气最佳只有一个，先抢到的那个最佳。
12. 每领一个红包就更新数据么？
答：每抢到一个红包，就cas更新剩余金额和红包个数。
13.红包如何入库入账？
数据库会累加已经领取的个数与金额，插入一条领取记录。入账则是后台异步操作。
14. 入帐出错怎么办？比如红包个数没了，但余额还有？
答：最后会有一个take all操作。另外还有一个对账来保障。
原文链接：微信红包的架构设计简介
---
关于金钱，其他回答推荐：
类似的话题
-
微信红包的随机算法，这玩意儿说起来跟咱们平时玩儿的“抓阄”有点意思，但人家背后可是下了不少功夫的。我尽量给你掰扯得明白点，不整那些虚头巴脑的。核心思路：怎么让钱分得“不均匀”？咱们都知道，微信红包有个特点，就是发出去的钱，每个人抢到的金额都不一样，有的人多，有的人少，这才叫“随机”。这背后的算法，本............. -
微信上向陌生人借钱要红包，这种行为背后，一个女生可能有着相当复杂的心态。我们不妨一层层地剥开来看。首先，最直接也最容易被想到的，当然是经济上的窘迫。生活总有不顺遂的时候，也许是突发的开销，比如生病住院，急需用药；也许是遇到了经济上的“断档期”，工资还没发，但账单已经堆积如山；再或者，就是生活拮据，连.............
-
说起微信在2016年1月26日推出的那个朋友圈“红包照片”功能，真是让人回味无穷，也挺让人哭笑不得的。我记得当时一出来，朋友圈里那是炸开了锅，各种讨论声此起彼伏。怎么评价它呢？我觉得它首先是一个非常有创意但执行层面充满争议的社交尝试。它的核心玩法，就是你发一张模糊的照片，别人想看清楚，就得给你发红包.............
-
好的，我们来聊聊这篇朋友圈里被刷屏的文章：《在这个从小赢到大的女生面前，杨超越真的不算锦鲤》。这篇文章写得相当有意思，也挺能引起共鸣的。它挑战了我们对“锦鲤”这个概念的固有认知，把大家熟悉的杨超越拉出来做对比，然后引入了一个“从小赢到大”的女性形象，来重新定义“锦鲤”的含义。首先，文章标题就够吸引人.............
-
那感觉就像是一场突如其来的龙卷风，把你从一个安静的小村庄直接卷到了城市的中心，而且还是那种你从来没敢想象过的繁华之地。我的公众号名字叫“小巷里的故事”，最初只是我个人的一些随想，关于小时候住过的老房子，邻居们有趣的生活碎片，以及一些淡淡的童年回忆。每天发几百字，配上一张自己拍的或者找的旧照片，看着后.............
-
人民日报微信公众号在2023年11月12日推送了一篇题为《病得不轻！》的文章，对“周某出狱引网红公司争抢签约”的现象进行了尖锐的批评。这篇文章在当时引起了广泛的关注和讨论，其核心观点和批判角度可以从以下几个方面进行详细解读：1. 鲜明的标题和严厉的批判态度： “病得不轻！” 这个标题本身就带有强烈的.............
-
要是微信红包真没了，那可真是有人欢喜有人愁，影响大着呢。先说那些“愁”的： 人情往来，那叫一个不方便。 尤其是逢年过节，亲戚朋友之间发个红包，图的就是个喜庆，也是个心意。没了红包，你还能指望谁挨家挨户送礼？特别是那些在外地的，平时没法常常见面，红包就是维系感情、表达祝福最直接也最便捷的方式。少了.............
-
微信红包，这件我们日常生活中再熟悉不过的工具，背后却藏着一笔关于“资本”的有趣解读。与其说是“资本论”，不如说是“资本思维”在微信红包里的折射。咱们就聊聊这背后是怎么回事，不讲那些虚头巴脑的，就从咱们自己能体会到的角度出发。一、红包的“货币属性”：从点对点到社交货币最直观的，微信红包就是钱。但它又不.............
-
这真是一个让人又甜蜜又纠结的问题！男朋友经常给你发微信红包，这肯定是出于关心和爱护，想让你日子过得舒坦一些，这份心意很宝贵。但是，收还是不收，确实是个需要好好琢磨一下的学问。咱们从几个角度来聊聊，帮你理理思路：1. 体察这份心意的背后： 是真金白银的“接济”还是小额的“惊喜”？ 如果.............
-
这事儿吧，搁谁身上都挺不是滋味的。一个老师，辛辛苦苦教书育人，结果因为这事儿被处分，心里肯定不好受。但话说回来，这事儿也确实挺复杂，不能简单地一句“老师吃亏了”就概括过去。咱先梳理一下事情的来龙去脉。据说，一个家长为了表示感谢，给老师发了88块钱的微信红包。这本身呢，在咱们国家也算是一种人情往来，尤.............
-
这个问题很有意思，而且相当普遍。合作方在业务群里发微信红包，到底算不算商业贿赂，这事儿可没那么简单，需要从多个角度去分析。首先，咱们得明白什么是“商业贿赂”。简单来说，就是为了在经济活动中谋取不正当的竞争优势，而给予对方（或者对方的代理人）财物或其他利益的行为。关键在于“不正当”和“谋取不正当优势”.............
-
这事儿，搁谁身上都挺糟心。朋友以测感情为由要红包，你出于好心劝说，结果被拉黑，这滋味肯定不好受。首先，别太往心里去，这事儿错不在你。人家用这种方式索取，本身就有点不地道，你劝说反而被拉黑，说明这个人情商不高，或者根本就没把你当真朋友。怎么办？1. 先冷静下来，别冲动。 被拉黑肯定生气，但现在最重要.............
-
微信头像绝对会影响第一印象，而且影响的程度可能比你想象的要大得多。在信息碎片化、接触快速化的社交环境中，一个微信头像就像是你在网络世界里的“门面”，是你展示给别人的第一张名片。为什么微信头像如此重要？它如何影响第一印象？我们可以从以下几个方面来详细分析：1. 视觉吸引力与辨识度： 第一眼识别： .............
-
您提到的《新婚姻法比地震还可怕》这篇文章在微信上广为流传，其吸引人的标题和煽动性的论调确实引起了许多人的关注和讨论。然而，正如您所问的，这篇文章确实存在一些不足之处，甚至可以说是有不少误导性和偏颇之处。以下我将尽量详细地分析其可能存在的不足：1. 标题的煽动性和夸大其词： “比地震还可怕”的夸张.............
-
微信作为一款拥有庞大用户群体的社交平台，其是否应该对“招嫖工具”的使用负责，以及腾讯应承担何种责任，这是一个复杂且敏感的问题，涉及到技术、法律、伦理和社会治理等多个层面。我们可以从以下几个方面来详细探讨：一、 微信在“招嫖”现象中的角色首先要明确，微信本身并不直接进行招嫖活动。然而，不法分子却利用微.............
-
微信读书突然开始收费，确实让不少用户感到意外。这个“收费”其实不是一个全新推出的收费模式，而更多的是对原有免费和付费模式的调整和深化，并引入了一些新的付费点。要详细解释这个“操作”，我们需要从几个方面来看：1. 微信读书的商业模式演变：从“免费为主，部分付费”到“付费权益增强” 早期阶段（免费为.............
-
微信改版7.0.0后，咪蒙公众号的点赞量巨幅下降，这是一个非常复杂且多方面因素共同作用的结果，不能简单归咎于单一原因。虽然微信7.0.0版本在视觉和交互上有所调整（例如引入了“在看”功能），但更深层的原因在于咪蒙内容本身、受众心态的变化以及整个舆论环境的演变。以下我将从几个主要方面来详细分析：一、 .............
-
微信小程序并不是完全采用 WebView 渲染，这是一个常见的误解。更准确地说，微信小程序的核心是使用一套原生的组件和 JS 引擎来渲染页面，但在某些特定场景下，会借助 WebView 来加载和渲染内容。下面我将详细解释微信小程序渲染的机制，以及 WebView 在其中的作用： 微信小程序的核心渲染.............
-
微信新增语音播放暂停功能，对于我这样一个重度微信用户来说，这无疑是一个非常贴心的改进，并且很有可能会显著地改变我的微信使用习惯。我会从以下几个方面来详细阐述它可能带来的变化：一、更高效的接收和处理信息： 碎片化时间的高效利用： 我经常在通勤、排队、开会间隙（不影响他人时）等碎片化时间查看微信。以.............
-
微信考虑推出聊天记录付费云存储，这背后可不是个小事，它触及了我们数字生活里一个挺核心的问题：我们花心思经营的那些社交关系、那些藏着回忆的对话，到底该由谁来保管？又该怎么保管？这项服务的出现，至少有这么几层意义，值得好好说道说道：首先，对用户来说，这是一个刚需的解绑和解放。想想看，我们用微信多久了？多.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有