4后台
4.1 数据库
以下关系型数据库设计的字段是基于少量请求下，我们模拟红包系统的可行方案，并没有考虑高并发、分库分表以及缓存的情况，关于这部分内容可以查看本文4.4部分整理一些大神的回答作为了解。
（1）用户信息数据表user_info
userID、红包ID、祝福语、红包类型、红包个数、红包金额、超时
（2）用户钱包数据表user_wallet
userID、money、银行卡ID等其他字段
（3）发送红包数据表red_send
红包ID、senderID、红包个数、红包金额、祝福语、最佳手气、发出时间
（4）接收红包数据表red_receive
红包ID、receiver、接收时间、接收金额
4.2 随机算法
很多人说红包序列是预先在手机发出去的时候已经产生好随机序列，其实这样会产生大量的数据库读写操作，内存读的速度以DDR3-2400为例，能达到17G/s，写的速度达到18G/s（参考文献：http://m.it168.com/article_1410707_p5.html）。而硬盘数据库的读写速度最多达到133MB/s。可见大量的从硬盘读写数据不但容易使硬盘损坏，更达不到高并发的读写需求。所以预先生成随机序列写入数据库，用户抢的时候再读出红包金额并将用户信息写入数据库并不科学。所以采用内存实时计算随机序列并异步写入硬盘数据库储存的方法。基于内存的随机序列是伪随机序列，他并不是真正的随机，而是根据种子通过一定的算法计算出来的值，只要种子不变，每次计算出来的值的序列是一致的。也就是说当红包指纹（ID或者ID+时间戳或者其他算法生成）一定时，计算出来的序列是一致的，这样子就不用储存在数据库，而是实时计算，第一次取序列的第一个值，第二次取序列的第二个值，如此类推。（更详细的说明可以参考http://www.open-open.com/lib/view/open1430473257443.html）。具体步骤如下（代码以python举例子，没办法知道人家后台用什么语言写的）：
以红包ID为种子
>>>red_ID = 1775509988475009
>>>random.seed(red_ID)
群手气红包的最小值为0.01，摇一摇红包的最小值为2.00
>>>min = 1.00
>>>if (红包为群手气红包):
min = 0.01
else(红包为摇一摇红包):
min = 2.00
群手气红包的最大值为剩余红包总额和个数的商的2倍（你可以在群里不停地发红包做回归，记得叫上我去拿红包，哈哈）。
>>>max = (remain_money/remain_num)*2
而摇一摇红包官方给出的计算公式是剩余金额/剩余红包数*n
n主观猜测也是等于2，在这公式基础上再人为控制概率。
方案一：
人为干扰概率的，有人拿到京东618元的红包，动脑子想想，京东店庆是618，这个金额绝对不是随机出来的，而是设定好金额，然后每个金额范围都有一定的概率。
比如说2元—5元概率为85%；5元—20元概率为10%，20元—50元概率为4.99%，618元概率为0.01%。（概率仅作参考，因为样本量太大，官方也没提供数据，这里只是提供其中一种可行的方案，以下代码也只是提供思路，与实际可运行的代码略有差别）
>>>a = random.uniform(0,1)
>>>b,_max,_min = 0
>>>if a < 0.85:
_min = 2.00
_max = 5.00
>>>elif a < 0.95 & a >= 0.85:
_min = 5.00
_max = 20.00
>>>elif a < 0.9999 & a >= 0.95:
_min = 20.00
_max = 50.00
>>>elif a > 0.9999:
_min = 618.00
_max = 618.00
>>>random.uniform(min,max)
方案二：
_min = 2.00
_max = 剩余金额/剩余红包数*n
人为放出618元的彩蛋红包，并且用上述方法设置概率为0.0001%
4.3 红包发出去那一刻发生了什么？
这一部分由于个人的水平限制，未能给出有深度的简介，这里为了文章的完整性，借用胖胖的文章作为说明（胖胖的博客为www.phppan.com）
（1）发红包后台操作：
在数据库中增加一条红包记录，存储到CKV，设置过期时间；
在Cache（可能是腾讯内部kv数据库，基于内存，有落地，有内核态网络处理模块，以内核模块形式提供服务））中增加一条记录，存储抢红包的人数N
（2）抢红包后台操作：
抢红包分为抢和拆，抢操作在Cache层完成，通过原子减操作进行红包数递减，到0就说明抢光了，最终实际进入后台拆操作的量不大，通过操作的分离将无效请求直接挡在Cache层外面。这里的原子减操作并不是真正意义上的原子减操作，是其Cache层提供的CAS，通过比较版本号不断尝试，存在一定程度上的冲突，冲突的用户会放行，让其进入下一步拆的操作，这也解释了为啥有用户抢到了拆开发现领完了的情况。
拆红包在数据库完成，通过数据库的事务操作累加已经领取的个数和金额，插入一条领取流水，入账为异步操作，这也解释了为啥在春节期间红包领取后在余额中看不到。拆的时候会实时计算金额，其金额为1分到剩余平均值2倍之间随机数，一个总金额为M元的红包，最大的红包为 M * 2 /N（且不会超过M），当拆了红包后会更新剩余金额和个数。财付通按20万笔每秒入账准备，实际只到8万每秒。
4.4 Q&A若干整理
（这一部分是网上整理的，不知道如何分类比较好就放在一起了）
① 既然在抢的时候有原子减了就不应该出现抢到了拆开没有的情况？
这里的原子减并不是真正意义上的原子操作，是Cache层提供的CAS，通过比较版本号不断尝试。
② cache和db挂了怎么办？
主备 +对账
③ 有没有红包个数没了，但余额还有情况？
没有，程序最后会有一个take all操作以及一个异步对账保障。
④ 为什么要分离抢和拆？
总思路是设置多层过滤网，层层筛选，层层减少流量和压力。这个设计最初是因为抢操作是业务层，拆是入账操作，一个操作太重了，而且中断率高。 从接口层面看，第一个接口纯缓存操作，搞压能力强，一个简单查询Cache挡住了绝大部分用户，做了第一道筛选，所以大部分人会看到已经抢完了的提示。
⑤ 抢到红包后再发红包或者提现，这里有什么策略吗？
大额优先入账策略
⑥ 有没有从数据上证明每个红包的概率是不是均等？
不是绝对均等，就是一个简单的拍脑袋算法。官方已经在产品经理大会上说明这是个拍脑袋的算法了。
⑦发红包人的钱会不会冻结？
是直接实时扣掉，不是冻结。
⑧ 采用实时算出金额是出于什么考虑？
实时效率更高，预算才效率低下。预算还要占额外存储。因为红包只占一条记录而且有效期就几天，所以不需要多大空间。就算压力大时，水平扩展机器是。详见本文4.2的说明。
⑨ 实时性：为什么明明抢到红包，点开后发现没有？
答：2014年的红包一点开就知道金额，分两次操作，先抢到金额，然后再转账。
2015年的红包的拆和抢是分离的，需要点两次，因此会出现抢到红包了，但点开后告知红包已经被领完的状况。进入到第一个页面不代表抢到，只表示当时红包还有。详见本文Jinkey在第五部分的说明。
⑩ 红包的设计
答：微信从财付通拉取金额数据过来，生成个数/红包类型/金额放到redis集群里，app端将红包ID的请求放入请求队列中，如果发现超过红包的个数，直接返回。根据红包的逻辑处理成功得到令牌请求，则由财付通进行一致性调用，通过像比特币一样，两边保存交易记录，交易后交给第三方服务审计，如果交易过程中出现不一致就强制回归。
? 并发性处理：红包如何计算被抢完？
答：cache会抵抗无效请求，将无效的请求过滤掉，实际进入到后台的量不大。cache记录红包个数，原子操作进行个数递减，到0表示被抢光。财付通按照20万笔每秒入账准备，但实际还不到8万每秒。
? 如何保持8w每秒的写入？
答：多主sharding，水平扩展机器。
? 查询红包分配，压力大不？
答：抢到红包的人数和红包都在一条cache记录上，没有太大的查询压力。
? 一个红包一个队列？
答：没有队列，一个红包一条数据，数据上有一个计数器字段。
? 每领一个红包就更新数据么？
答：每抢到一个红包，就cas更新剩余金额和红包个数。
? 红包如何入库入账？
数据库会累加已经领取的个数与金额，插入一条领取记录。入账则是后台异步操作。
? 入帐出错怎么办？比如红包个数没了，但余额还有？
答：最后会有一个take all操作。另外还有一个对账来保障。
下一篇：你所不知道的微信红包（五）——交互分析