微信抢红包解析（算法+平台）
微信红包的架构
2015年之前用的是硬抗，之后用的是cache抗流量
至于是什么是cache? 什么是cache抗流量百度上有。
理想的红包生成算法
理想的红包生成结果是平均值附近的红包比较多，大红包和小红包的数量比较少。
可以想像下，生成红包的数量的分布有点像正态分布。
那么如何实现这种平均线附近值比较多的要求呢？
就是要找到一种算法，可以提高平均值附近的概率。那么利用一种”膨胀“再”收缩“的方式来达到这种效果。
先平方，再生成平方范围内的随机数，再开方，那么
public class HongBaoAlgorithm {
static Random random = new Random();
static {
random.setSeed(System.currentTimeMillis());
}
public static void main(String[] args) {
long max = 200;
long min = 1;
long[] result = HongBaoAlgorithm.generate(100_0000, 10_000, max, min);
long total = 0;
for (int i = 0; i < result.length; i++) {
// System.out.println("result[" + i + "]:" + result[i]);
// System.out.println(result[i]);
total += result[i];
}
//检查生成的红包的总额是否正确
System.out.println("total:" + total);
//统计每个钱数的红包数量，检查是否接近正态分布
int count[] = new int[(int) max + 1];
for (int i = 0; i < result.length; i++) {
count[(int) result[i]] += 1;
}
for (int i = 0; i < count.length; i++) {
System.out.println("" + i + " " + count[i]);
}
}
/**
* 生产min和max之间的随机数，但是概率不是平均的，从min到max方向概率逐渐加大。
* 先平方，然后产生一个平方值范围内的随机数，再开方，这样就产生了一种“膨胀”再“收缩”的效果。
*
* @param min
* @param max
* @return
*/
static long xRandom(long min, long max) {
return sqrt(nextLong(sqr(max - min)));
}
/**
*
* @param total
* 红包总额
* @param count
* 红包个数
* @param max
* 每个小红包的最大额
* @param min
* 每个小红包的最小额
* @return 存放生成的每个小红包的值的数组
*/
public static long[] generate(long total, int count, long max, long min) {
long[] result = new long[count];
long average = total / count;
long a = average - min;
long b = max - min;
//
//这样的随机数的概率实际改变了，产生大数的可能性要比产生小数的概率要小。
//这样就实现了大部分红包的值在平均数附近。大红包和小红包比较少。
long range1 = sqr(average - min);
long range2 = sqr(max - average);
for (int i = 0; i < result.length; i++) {
//因为小红包的数量通常是要比大红包的数量要多的，因为这里的概率要调换过来。
//当随机数>平均值，则产生小红包
//当随机数<平均值，则产生大红包
if (nextLong(min, max) > average) {
// 在平均线上减钱
// long temp = min + sqrt(nextLong(range1));
long temp = min + xRandom(min, average);
result[i] = temp;
total -= temp;
} else {
// 在平均线上加钱
// long temp = max - sqrt(nextLong(range2));
long temp = max - xRandom(average, max);
result[i] = temp;
total -= temp;
}
}
// 如果还有余钱，则尝试加到小红包里，如果加不进去，则尝试下一个。
while (total > 0) {
for (int i = 0; i < result.length; i++) {
if (total > 0 && result[i] < max) {
result[i]++;
total--;
}
}
}
// 如果钱是负数了，还得从已生成的小红包中抽取回来
while (total < 0) {
for (int i = 0; i < result.length; i++) {
if (total < 0 && result[i] > min) {
result[i]--;
total++;
}
}
}
return result;
}
static long sqrt(long n) {
// 改进为查表？
return (long) Math.sqrt(n);
}
static long sqr(long n) {
// 查表快，还是直接算快？
return n * n;
}
static long nextLong(long n) {
return random.nextInt((int) n);
}
static long nextLong(long min, long max) {
return random.nextInt((int) (max - min + 1)) + min;
}
}
概率就不再是平均的了。
-
微信的金额什么时候算？
答：微信金额是拆的时候实时算出来，不是预先分配的，采用的是纯内存计算，不需要预算空间存储。。
采取实时计算金额的考虑：预算需要占存储，实时效率很高，预算才效率低。 -
实时性：为什么明明抢到红包，点开后发现没有？
答：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操作。另外还有一个对账来保障。
