去新浪口试随机红包算法险些是必问的问题，着重稽核口试者的实际动手能力。
题目一：
写出一个随机红包算法（红包总额$n分钱，分配份额$m人，$n>=$m),哀求：
1.不能有人分不到。2、分配不能太过均匀。3、拆红包时实时打算金额。不能提前分配好。
担保每个人都能分配到，只要设置好最大值和最小值就可以了，不能有人分不到，以是最小值必须是大于1分钱。
分配不能太过均匀，只要担保随机数能够在一个尽可能大的范围随机生造诣可以了。
实时打算的话，只要实现函数时把剩余的金额，剩余的份数份数作为变量传入就可以了。
废话不多说，直接上代码，首先定义打算每次分配金额的函数（单位为元）：
接下来就可以定义一个循环打算出每个红包的金额了：
末了打印出来类似以下这种，再各自乘以100后，单位便是分了：
3.1,6.73,9.51,2.08,9.03,1.85,4.06,2.15,1.84,7.59,3.74,3.22,10.48,1.38,6.98,9.87,7.78,3.09,4.41,1.11
题目二：
请写出一个微信红包算法，哀求最小值为2块钱，最大值为5块钱，其他条件同题型一。
实际上这道题和题目一十分类似，写代码时只须要将$min变量设置为2，将$max变量设置为5就可以了，其余把稳下边界条件的检讨。
以上便是来悛改浪微博的两道口试题。
祝大家抢红包快乐哦~
转一下关于红包架构的文章
微信红包的架构设计简介
@来源于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/72）=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操作。其余还有一个对账来保障。
--END--
