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

我们在一个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

仅供参考

创建数据库里最基本的应该就是建表，建索引、存储过程等一系列 *** 作了。谈到表就不得不谈到实体。

一、数据实体

什么是实体，客观存在并且可以相互区别的事物称为实体。这里我们就简单的把它理解为一个表吧，描述实体的特性，我们就把他们称为了属性。也可以说当我们把一个数据库表当作一个实体，那么它里面的所有字段是不是就是一个属性了呢？结果是肯定的。

二、实体间的联系

我想说的是，很简单，数据库里表跟表间的关系莫过于三种：一对一；多对多；一对多。

一对一其实就是说我们建的主表跟相关联的表之间是一一对应的，比如说，我建了一个学生基本信息表：t_student,然后我又建了一个成绩表，里面有个外键，studentID，学生基本信息表里的字段studentID和成绩表里的studentID就是一对一。

一对多，也是类似，我另外建一个班级表，而每个班级有多个学生，每个学生就对应一个班级，对班级来说当然就是一对多了。

多对多，我还举这个例子，我建个选课表，可能有许多科目，每个科目有很多学生选，而每个学生又可以选择多个科目。这就是多对多了。

三、基本表的完整性

(1) 原子性。基本表中的字段是不可再分解的。

(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。

(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。

(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。

这是基本表的完整性，也是它特有的。这里我想说的是，在数据库里还有几种表也是常用的那就是中间表和临时表。

1、中间表

中间表是针对多对多关系的，就比如做公交查询系统。里面有两个表，分别是车站表、线路表。这里我们起个名字叫：t_busstation 、t_road，根据常识我们也知道，一个站有多个线路经过，而每个线路又有多个车站，怎么才能将两个表联系起来呢，如果是一对一，一对多，我们一个表，两个表就可以将他们实现了，但是多对多呢，这样我们就必须借助中间表用来连接两个表。一般中间表都是有一个本表的自增主键，还有另外两个表的主键。中间表是没有属性的因为它不是一个基本表。

2、临时表

在本次项目中，我们就要用到临时表，首先来看看什么是临时表吧。这是我从网上书上查到的。因为我们用的是MS SQL Server 2000数据库，而在这个数据库里是支持临时表的。

临时表：其实就是那些以#号开头为名字的数据表，它主要是用来存放临时数据的，当用户断开连接但没有出去临时表里的数据时，系统会自动把临时表里的数据清空。这里要说一点，临时表是放在系统数据库 tempdb中的，而不是当前数据库。

临时表总共是分两种：本地临时表和全局临时表。

（1）这里我们需要了解的就是，在数据库中本地临时表是以一个#开头的，这种临时表只对当前的数据库用户可见，而其他的用户是不可见的。当数据库实例断开后当然也就丢失了数据了，不管是显式清空还是系统回收。

（2）还有一个就是全局临时表。它是以“##”开头的，而且是对于所有的用户都是可见的，当你断开数据库实例连接时，只要还有别的系统项目在引用它，连着数据库，那么数据就存在，只有当别的系统也断开连接时，系统才会清除全局临时表的数据。

下面是建立临时表的语句:

本地临时表：

create table #student

(

studentID int ,

studentName nvarchar (40),

classID int

)

全局临时表：

create table ##student

(

studentID int ,

studentName nvarchar (40).

classID int

)

这里我们也可以用SQL语句完成：

select * from employee into #student

现在就来看看三大范式。

第一范式：如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.比如一个工人的基本信息表，里面有工人的工号，性别，年龄，这些属性都是不可分割的，所以这个表就符合了第一范式。

第二范式： 就是在第一范式的基础上延伸，使之表里的每个字段都与主键发生关系。假如一个关系满足第一范式,并且除了主键以外的其它字段,都依赖于该主键,则满足第二范式.

例如:订单表(订单编号、产品编号、定购日期、价格、……)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，这个列我们就可以把它删除。

第三范式：在第二范式的基础上更进一步，也就是为了实现表里的列都与主键列直接相关，不是间接相关。这个我们可以用“Armstrong 公理”中的传递规则来推理。

我们来看一下它的定义：

设U是关系模式R 的属性集，F 是R 上成立的只涉及U 中属性的函数依赖集。若X→Y 和 Y→Z在R 上成立，则X →Z 在R 上成立。因此我们就来看在网上搜索到的例子：例如:订单表(订单编号，定购日期，顾客编号，顾客姓名，……)，初看该表没有问题，满足第二范式，每列都和主键列"订单编号"相关，再细看你会发现"顾客姓名"和"顾客编号"相关，"顾客编号"和"订单编号"又相关，最后经过传递依赖，"顾客姓名"也和"订单编号"相关。为了满足第三范式，应去掉"顾客姓名"列，放入客户表中。

这里其实就是为了说明数据库的表里步要出现冗余，在顾客表里已经有了"顾客姓名"了，而在订单表里就别出现了，而直接根据顾客编号相关联就可以，否则造成资源浪费。

以上就是三大范式。

延伸：我们来看这三大范式：

第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；

第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；

第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没

有冗余。

其实在设计数据库的时候我们最多的要遵循的就是第三范式，但是并不是越满足第三范式数据库就设计的越完美，这种错误是错误的。有时候增加点冗余相反的会提高访问速率，因此在实际的设计过程中应降低对范式的要求。

以前对数据冗余并不是很了解，在百度知道里的定义是这样的：在一个数据集合中重复的数据称为数据冗余. 但是不是说我们表的主键在其他表里重复出现就是冗余，这不是，而是为了连接两个表。只有非键字段就是既不是主键外键等约束的键如果重复出现，就会形成数据冗余。数据冗余也包括重复性冗余和派生冗余。比如工人表里有"基本工资"，"奖金"两列，然后还有一个"总工资"的列，这个总工资就是派生冗余。低级的重复性冗余一定要避免，杜绝，但是像派生冗余还是提倡的因为它能提高访问的效率。

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

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

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

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

---