本文内容编写时，参考了网上的材料，详见“参考资料”局部，感激分享者。
1、引言
这个系列文章曾经整顿了 10 篇，但都没有波及到具体的红包算法实现，次要有以下两方面起因。
一方面是各社交 /IM 产品中的红包性能同质化重大，红包算法的“可玩性”便是“外围竞争力所在”，这是同质化性能的差异化竞争思路，不会轻易公开。
另一方面，市场上还存在各种抢红包插件这类灰产存在，一旦公开这些算法，很可能又被这帮插件开发者们搞出什么幺蛾子。
所以，这样的状况下，如果要做社交 /IM 产品中的红包性能，红包轻易算法该怎么实现，基本上只能自已推敲，很难找到大厂算法间接套用。
本着即时通讯网一贯的 im 常识流传精力，我收集整理并参考了大量的网上材料，综合了比拟靠谱的信息起源，便有了本文。本文依据无限的材料，分享了微信红包随机算法实现中的一些技术要点，并整顿了两种比拟靠谱的红包算法实现思路（含可运行的实现代码），心愿能给你的红包算法开发带来启发。
申明：本文材料整顿自网络，仅供学习钻研之用，如有不妥，请告诉作者。
学习交换：
– 即时通讯开发交换 5 群：215477170 [举荐]
– 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
– 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK [举荐]
本文已同步公布于“即时通讯技术圈”公众号，欢送关注：
▲ 本文在公众号上的链接是：点此进入，原文链接是：http://www.52im.net/thread-3125-1-1.html
2、系列文章
- 《社交软件红包技术解密(一)：全面解密 QQ 红包技术计划——架构、技术实现等》
- 《社交软件红包技术解密(二)：解密微信摇一摇红包从 0 到 1 的技术演进》
- 《社交软件红包技术解密(三)：微信摇一摇红包雨背地的技术细节》
- 《社交软件红包技术解密(四)：微信红包零碎是如何应答高并发的》
- 《社交软件红包技术解密(五)：微信红包零碎是如何实现高可用性的》
- 《社交软件红包技术解密(六)：微信红包零碎的存储层架构演进实际》
- 《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实际》
- 《社交软件红包技术解密(八)：全面解密微博红包技术计划》
- 《社交软件红包技术解密(九)：谈谈手 Q 春节红包的设计、容灾、运维、架构等》
- 《社交软件红包技术解密(十)：手 Q 客户端针对 2020 年春节红包的技术实际》
- 《社交软件红包技术解密(十一)：最全解密微信红包随机算法(含演示代码)》（* 本文）
3、微信红包算法要点汇总
这是目前能找到的仅有的一份，有微信团队人员参加的微信红包算法技术要点的探讨材料。分享于 2015 年，差不多是微信红包刚火没多久，大略是微信技术团队的人过后没有当初这些技术之外的顾虑，所以作了无限的分享，材料难得，本次重新整理了一下，能够作为参考资料应用。以下是材料注释。
材料起源：来自 InfoQ 的某架构群的技术探讨，由朱玉华整顿（集体博客是：zhuyuhua.com（目前已无法访问））。
材料背景：起因是有敌人在朋友圈征询微信红包的架构，于是在微信团队成员参加探讨的状况下，我（指“朱玉华”）整顿了这次探讨的技术要点，也就是上面的内容（内容为问答模式）。
3.1、算法实现的技术要点
问：微信的金额什么时候算？
答：微信金额是拆的时候实时算进去，不是事后调配的，采纳的是纯内存计算，不须要估算空间存储。
为什么采取实时计算金额？起因是：实时效率更高，估算才效率低下。估算还要占额定存储。因为红包只占一条记录而且有效期就几天，所以不须要多大空间。就算压力大时，程度扩大机器是。
问：对于实时实时性，为什么明明抢到红包，点开后发现没有？
答：2014 年的红包一点开就晓得金额，分两次操作，先抢到金额，而后再转账。
2015 年的红包的拆和抢是拆散的，须要点两次，因而会呈现抢到红包了，但点开后告知红包曾经被领完的情况。进入到第一个页面不代表抢到，只示意过后红包还有。
问：对于调配算法，红包里的金额怎么算？为什么呈现各个红包金额相差很大？
答：随机，额度在 _0.01_ 和残余平均值 _2_ 之间。例如：发 _100_ 块钱，总共 _10_ 个红包，那么平均值是 _10_ 块钱一个，那么收回来的红包的额度在 _0.01_元～_20_元之间稳定。
当后面 _3_ 个红包总共被领了 _40_ 块钱时，剩下 _60_ 块钱，总共 _7_ 个红包，那么这 _7_ 个红包的额度在：_0.01_～（_60/7 * 2_）=_17.14_之间。
留神：这里的算法是每被抢一个后，剩下的会再次执行下面的这样的算法（Tim 老师也感觉上述算法太简单，不知基于什么样的思考）。
这样算下去，会超过最开始的全副金额，因而到了最初面如果不够这么算，那么会采取如下算法：保障残余用户能拿到最低 1 分钱即可。
如果后面的人手气不好，那么前面的余额越多，红包额度也就越多，因而理论概率一样的。
问：红包的设计
答：微信从财付通拉取金额数据过去，生成个数 / 红包类型 / 金额放到 redis 集群里，app 端将红包 ID 的申请放入申请队列中，如果发现超过红包的个数，间接返回。依据红包的逻辑解决胜利失去令牌申请，则由财付通进行一致性调用，通过像比特币一样，两边保留交易记录，交易后交给第三方服务审计，如果交易过程中呈现不统一就强制回归。
问：并发性解决：红包如何计算被抢完？
答：cache 会抵制有效申请，将有效的申请过滤掉，理论进入到后盾的量不大。cache 记录红包个数，原子操作进行个数递加，到 0 示意被抢光。财付通依照 _20 万笔_每秒入账筹备，但理论还不到 _8 万每秒_。
问：通如何放弃 8w 每秒的写入？
答：多主 sharding，程度扩大机器。
问：数据容量多少？
答：一个红包只占一条记录，有效期只有几天，因而不须要太多空间。
问：查问红包调配，压力大不？
答：抢到红包的人数和红包都在一条 cache 记录上，没有太大的查问压力。
问：一个红包一个队列？
答：没有队列，一个红包一条数据，数据上有一个计数器字段。
问：有没有从数据上证实每个红包的概率是不是均等？
答：不是相对均等，就是一个简略的拍脑袋算法。
问：拍脑袋算法，会不会呈现两个最佳？
答：会呈现金额一样的，然而手气最佳只有一个，先抢到的那个最佳。
问：每领一个红包就更新数据么？
答：每抢到一个红包，就 cas 更新残余金额和红包个数。
问：红包如何入库入账？
答：数据库会累加曾经支付的个数与金额，插入一条支付记录。入账则是后盾异步操作。
问：入帐出错怎么办？比方红包个数没了，但余额还有？
答：最初会有一个 take all 操作。另外还有一个对账来保障。
问：既然在抢的时候有原子减了就不应该呈现抢到了拆开没有的状况？
答：这里的原子减并不是真正意义上的原子操作，是 Cache 层提供的 CAS，通过比拟版本号一直尝试。
问：cache 和 db 挂了怎么办？
答：主备 + 对账。
问：为什么要拆散抢和拆？
答：总思路是设置多层过滤网，层层筛选，层层缩小流量和压力。
这个设计最后是因为抢操作是业务层，拆是入账操作，一个操作太重了，而且中断率高。从接口层面看，第一个接口纯缓存操作，搞压能力强，一个简略查问 Cache 挡住了绝大部分用户，做了第一道筛选，所以大部分人会看到曾经抢完了的提醒。
问：抢到红包后再发红包或者提现，这里有什么策略吗？
答：大额优先入账策略。
针对下面的技术要点，有人还画了张原理图（这是网上能找到的绝对清晰的版本）：
3.2、微信抢红包的过程模仿
针对上节中整顿的材料，当有人在微信群里发了一个 N 人的红包、总金额 M 元，后盾大略的技术逻辑如下。
3.2.1）发红包后盾操作：
- 1）在数据库中减少一条红包记录，存储到 CKV，设置过期工夫；
- 2）在 Cache（可能是腾讯外部 kv 数据库，基于内存，有落地，有内核态网络解决模块，以内核模块模式提供服务））中减少一条记录，存储抢红包的人数 N。
3.2.2）抢红包后盾操作：
- 1）抢红包分为抢和拆：抢操作在 Cache 层实现，通过原子减操作进行红包数递加，到 0 就阐明抢光了，最终理论进入后盾拆操作的量不大，通过操作的拆散将有效申请间接挡在 Cache 层里面。
- 这里的原子减操作并不是真正意义上的原子减操作，是其 Cache 层提供的 CAS，通过比拟版本号一直尝试，存在肯定水平上的抵触，抵触的用户会放行，让其进入下一步拆的操作，这也解释了为啥有用户抢到了拆开发现领完了的状况。
- 2）拆红包在数据库实现：通过数据库的事务操作累加曾经支付的个数和金额，插入一条支付流水，入账为异步操作，这也解释了为啥在春节期间红包支付后在余额中看不到。
- 拆的时候会实时计算金额，其金额为 1 分到残余平均值 2 倍之间随机数，一个总金额为 M 元的红包，最大的红包为 M * 2 /N（且不会超过 M），当拆了红包后会更新残余金额和个数。财付通按 20 万笔每秒入账筹备，理论只到 8 万每秒。
4、微信红包算法模仿实现 1（含代码）
依据上一节的微信红包随机算法技术要点材料，实现了一个算法，以下供参考。（注：本节内容援用自《微信红包随机算法初探》一文）
4.1、算法约定
算法很简略，跟微信的算法一样，不是提前算好，而是抢红包时计算。
即：金额随机，额度在 0.01 和残余平均值 * 2 之间。（参见上一节的“对于调配算法，红包里的金额怎么算？为什么呈现各个红包金额相差很大？”内容）
4.2、代码实现
算法的逻辑次要是：
public static double getRandomMoney(RedPackage _redPackage) {
// remainSize 残余的红包数量
// remainMoney 残余的钱
if(_redPackage.remainSize == 1) {
_redPackage.remainSize–;
return (double) Math.round(_redPackage.remainMoney * 100) / 100;
}
Random r = newRandom();
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;
}
LeftMoneyPackage 数据结构如下：
class RedPackage {
int remainSize;
double remainMoney;
}
测试时初始化相干数据是：
static void init() {
redPackage.remainSize = 30;
redPackage.remainMoney = 500;
}
附件是能够运行的残缺 Java 代码文件：
（无奈上传附件，如有须要请从此链接处下载：http://www.52im.net/thread-3125-1-1.html）
4.3、测试后果
4.3.1 单次测试
按上述代码中的初始化数据（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
第一次随机红包数据图表如下：
▲ x 轴为抢的程序，y 轴为抢到的金额
第二次随机红包数据图表如下：
▲ x 轴为抢的程序，y 轴为抢到的金额
4.3.2 屡次均值
反复执行 200 次的均值：
▲ x 轴为抢的程序，y 轴为该次抢到金额的概率均值
反复执行 2000 次的均值：
▲ x 轴为抢的程序，y 轴为该次抢到金额的概率均值
从以上两张图的均值后果能够看出，这个算法中每一次能抢到的金额几率简直是均等的，从随机性来说比拟正当。
5、微信红包算法模仿实现 2（含代码）
我对随机算法很感兴趣，刚巧最近钻研的方向有点偏随机数这块，所以也本人实现了一下微信的红包散发算法（算法要点参考的是本文第三节内容）。（注：本节内容援用自《微信红包算法的剖析》一文）
5.1、代码实现
从第三节中能够理解到，微信并不是一开始就预调配所有的红包金额，而是在拆时进行计算的。这样做的益处是效率高，实时性。本次的代码中，红包具体是怎么计算的呢？请参见第 4 节中的“对于调配算法，红包里的金额怎么算？为什么呈现各个红包金额相差很大？”。
那基于这个思维，能够写出一个红包调配算法：
/**
* 并不完满的红包算法
*/
public static double rand(double money, int people, List<Double> l) {
if(people == 1) {
double red = Math.round(money * 100) / 100.0;
l.add(red);
return0;
}
Random random = newRandom();
double min = 0.01;
double max = money / people * 2.0;
double red = random.nextDouble() * max;
red = red <= min ? min : red;
red = Math.floor(red * 100) / 100.0;
l.add(red);
double remain = Math.round((money – red) * 100) / 100.0;
return remain;
}
算法整体思路很简略，就在在最初一个人的时候要留神，此时不进行随机数计算，而是间接将残余金额作为红包。
5.2、第一次剖析
采纳上述算法，能够对用户的抢红包行为做剖析。这里的模拟行为是：30 元的红包，10 人抢。操作 100 次。
能够得出如下后果：
▲ x 轴为抢的程序，y 轴为该次抢到金额
从上图中能够很轻易的看进去，越后抢的人，危险越大，同时收益也越大，有较大几率取得“手气最佳”。
那红包面值的散布性如何呢？
▲ x 轴为抢的程序，y 轴为该次抢到金额反复 100 次后的平均值
从上图能够看出，都是比拟靠近平均值 (3 元) 的。
那反复 1000 次呢？
▲ x 轴为抢的程序，y 轴为该次抢到金额反复 1000 次后的平均值
更靠近了。。。
能够看出，这个算法能够让大家抢到红包面额在概率上是大抵均等的。
5.3、不足之处
有人提出了这个问题：
他接下来放了好几张他试验的截图。我这里取了一张，如果有趣味，能够去知乎的问题里查看更多图片。
而此时，我哥们在和我的在探讨中，也通知我，的确存在某个法则，可能让最初一个抢的人占有某些渺小的劣势，比方，多 0.01 的之类。
例如发 6 个，总额 0.09 的包，最初一个抢的有极大概率是 0.03。
然而我之前的代码却没方法体现出这一点。
比方 10 人拆 0.11 元的包，我的后果是：
可见以上代码还存在不足之处。
于是我就有一个猜想：
微信可能不是对全金额进行随机的，可能在派发红包之前，曾经对金额做了解决，比方，当时减去(红包个数 *0.01)，之后在每个红包的随机值根底上加 0.01，以此来保障每个红包最小值都是 0.01。
这个猜想或者能够解开那位知友和我哥们这边的纳闷。
5.4、欠缺算法
在原先的根底上对代码进行简略的修改：
public static double rand(double money, int people, List<Double> l) {
if(people == 1) {
double red = Math.round(money * 100) / 100.0;
l.add(red+0.01);
return 0;
}
Random random = newRandom();
double min = 0;
double max = money / people * 2.0;
double red = random.nextDouble() * max;
red = red <= min ? min : red;
red = Math.floor(red * 100) / 100.0;
l.add(red+0.01);
double remain = Math.round((money – red) * 100) / 100.0;
return remain;
}
这个算法，在第一次调用时传入 money 的值是总金额减去红包数 *0.01，大略像这样：
_money = _money – people * 0.01;
5.5、第二次剖析
5.5.1 验证上次的不足之处
1）10 人抢 0.11 元的包：
2）2 人抢 0.03 元的包：
3）6 人抢 0.09 的包：
5.5.2 批改后的代码会不会对已知论断造成影响？
30 元的红包，10 人抢，操作 100 次。
▲ x 轴为抢的程序，y 轴为该次抢到金额
▲ x 轴为抢的程序，y 轴为该次抢到金额反复 100 次后的平均值
由下面两图可见，论断基本上没有扭转。
5.6、论断
通过上述代码实际可知：
1）先抢后抢，金额冀望都是雷同的；
2）微信的红包算法很可能是事后调配给每人 0.01 的“底额”；
3）后抢者危险高，收益大。
5.7、补充
上几张前面测试的图，补充一下之前的观点，发 n 个红包，总金额是(n+1)*0.01，最初一个领的肯定是手气最佳。
大家也能够试试。
以上，大略能够证实，微信红包是在调配前先给每个人 0.01 的最低金额的！
6、参考资料
[1] 微信红包随机算法初探
[2] 微信红包算法的剖析
[3] 微信红包的架构设计简介
[4] 微信红包的随机算法是怎么实现的？
另外，知乎上对于微信红包算法的探讨问题很多人参加，有趣味能够下来看看，或者会有更多启发：《微信红包的随机算法是怎么实现的？》。
附录：更多微信相干资源
《IM 开发宝典：史上最全，微信各种性能参数和逻辑规定材料汇总》
《微信本地数据库破解版(含 iOS、Android)，仅供学习钻研 [附件下载]》
（本文同步公布于：http://www.52im.net/thread-3125-1-1.html）