说明微信红包体系设计剖析钱；两个字微信红包体系设计剖析聊天窗口和微信钱包。
2
2.1钱包
在钱包添加红包入口，是由于用户初次用时，通常是先收到其他人的红包，自己要取钱，那样去什么地方取呢？一定是钱包，钱包需要集合所有跟钱有关的定义，给用户一个深刻的印象，像OmniFocis的透视功能（不了解不再计较…），需要把有关内容聚合到一个入口。所以钱包聚合了和钱有关的内容，譬如信用卡还款、手机充值、投资理财通等，用户首次进去收钱的时候，自然就看到微信红包并进一步引导用户绑定信用卡和发红包。另外假如用户首次用红包不是收到其他人红包，而是听说有红包这一功能或者看到其他人发红包，他第一会想到钱有关的东西应该在红包里面。
3
2.2 聊天窗口
而这聊天窗口中加入红包入口则是愈加简单暴力，用户在春节或者平时用会常常点开"+"发送图片，这就比较容易会见到红包入口了，而且微信在春节的时候特意把红包按钮用红色高亮显示了，这就愈加容易被用户发现，从而提升入口转换率。这里还有个逻辑，在单聊和群聊所进入的红包页面的不一样的，如下图所示微信红包体系设计剖析
1、金额随机，时大时小的金额能给用户惊喜；
2、可以看到其他用户抢了多少，引起攀比心理（这次抢得不爽，下次必须要抢个大大哒）；
3、产生不少新奇玩法，譬如手气好的发3倍金额；
4、因为可以看到哪个抢了红包，所以群里面一直抢第一又不参与游戏的人基本上是用外挂软件，群成员自发的需要群主踢掉这个人，这种众包式的"反外挂"比微信自己用技术方法去解决愈加节省本钱和愈加有效。
至于拼手气群红包相对于一般红包的劣势就是需要很多的计算资源去计算红包的随机金额，不过对于腾讯那样厉害的构造师和财力，这类计算资源算不了什么，反而消耗这类资源去拉起微信群的活跃度和拉高同时在线人数让财报好看点愈加合算。
2.3 摇一摇
微信在新年前还额外的增加了摇一摇的红包入口，给一直被觉得"约炮利器"的摇一摇洗白（哈哈，开玩笑啦！）。加速度传感器也非常具备互动性，却一直隐藏在手机里面，用率不如摄像头和话筒。摇一摇红包非常不错的借助了每一个人手机里面"雪藏"的硬件。在"红包一定是要发的"和"摇一摇功能的代码本来就有"的两大首要条件下，增加摇一摇红包这功能并不会增加多少开发量和本钱，由于既然红包要发，无论用什么形式发，后台的负载均衡和高并发分流是一定要做的，摇一摇的代码在约pao的年代就已经非常健全了基本上不需要改，接入红包的逻辑就能了，所以机会本钱非常低。那为何必须要发红包呢？由于上一年已经带坏头了，示范效应致使支付宝也来分一杯羹，微信能不发吗？
3 界面
3.1发红包页面
在单人聊天窗口进入的一般（定向）红包的页面仅需输入红包金额和祝福语，点击【塞钱进红包】，假如已经绑定银行卡，则调起对话框浮层【输入密码】；假如未绑定银行卡则跳转到零钱支付页面，点击按钮【用零钱支付】即可，不需要输入密码，在这个过程中，假如零钱不足，则会跳转到输入银行卡号的页面，点击【下一步】之后需要接着输入名字、银行预留手机号和短信验证码，填写完成后即可用银行卡支付。
5
这里不能不提的是一个很人性化的设计，当点击"改完一般红包"，从群手气红包切换到一般红包的过程中，已经输入的内容不会丢失，红包个数不变，此时的单个金额EditView（AndroidUI控件）中的值会由 总金额/红包个数 得出并自动填充；当点击"改为群手气红包"，从一般红包切换到群手气红包的过程中，已经输入的内容不会丢失，红包个数不变，此时的总金额EditView中的值会由 单个金额*红包个数 计算出并自动填充，，不需要用户重新输入，很贴心。这也是微信"将客户体验做到极致"的地方之一。
3.2红包『抢』页面
聊天窗口会显示出红包样式的聊天消息，点击红包后会出现拆的页面。
6
3.3红包『拆』页面
点击按钮【拆】之后，那坨黄色的东西会转（用几帧图片切换形成的动画，在IOS上比Android上运行起来愈加流畅），那坨东西转完之后页面会跳转到【红包结果页面】。值得一提的是Android最新版本中将Html版本的红包换成了Android原生红包界面，为何这么做呢？
一是微信惯用的牺牲推广客户端资源（CPU、内存、储存卡容量）去换取服务器端的稳定和降低资源投入的方案，页面资源放在当地，如此子web前端服务器容量就能降低投入，同时也可以降低推广客户端对资源服务器的访问量。类似的，微信的聊天记录是默认不存储在服务器端的，而是将各种图片语音短视频全部塞到你手机的内存里面，微信表情在6.0版本之前也是不保存到服务器的。
二是以往基于web的红包页面常常会出现"妈的页面还在loading红包就没了""红包来了却连不了网是如何一种体验"等等的用户抱怨，而原生的页面由于放在当地无需远程加载，仅需传输简单的红包ID，发送者等少量信息即可公告推广客户端显示红包页面，可以降低联网时间和减少互联网情况对抢红包的体验流畅度，让用户抢不到红包都不会感觉是由于微信没优化好，而是自己太幸福 （没单身的手速慢，哈哈）。下图为几种红包"拆"页面（大伙来玩找不一样，嘻嘻）微信红包体系设计剖析每降低1个单位（譬如说50W）的红包数目，自动将这个值写入缓存服务器，用户摇红包的时候都直接访问缓存，而且不是每次摇都访问剩余数，而是摇n次之后（譬如摇了5次）才去请求一次剩余红包数，如此就把传递到服务器的重压降低n倍。
上图最后那个页面你没见过？
微信官方说，当服务器重压过大的时候，唤起让用户休息一下这个页面。这里我提出另外一种方案，或许微信也使用了这种方案微信红包体系设计剖析http://m.it168.com/article_1410707_p5.html）。而硬盘数据库的读写速度最多达到133MB/s。可见很多的从硬盘读写数据不但容易使硬盘损毁，更达不到高并发的读写需要。所以预先生成随机序列写入数据库，用户抢的时候再读出红包金额并将用户信息写入数据库并不科学。所以使用内存实时计算随机序列并异步写入硬盘数据库储存的办法。基于内存的随机序列是伪随机序列，他并非真的的随机，而是依据种子通过肯定的算法计算出来的值，只须种子不变，每次计算出来的值的序列是一致的。也就是说当红包指纹（ID或者ID+时间戳或者其他算法生成）肯定时，计算出来的序列是一致的，如此子就不需要储存在数据库，而是实时计算，首次取序列的第一个值，第二次取序列的第二个值，这样类推。具体步骤如下（代码以python举例子，无法了解人家后台用什么语音写的）微信红包体系设计剖析
在数据库中增加一条红包记录，存储到CKV，设置过期时间；
在Cache（可能是腾讯内部kv数据库，基于内存，有落地，有内核态互联网处置模块，以内核模块形式提供服务））中增加一条记录，存储抢红包的人数N
（2）抢红包后台操作微信红包体系设计剖析为何明明抢到红包，点开后发现没？
答微信红包体系设计剖析微信从财付通拉取金额数据过来，生成个数/红包种类/金额放到redis集群里，app端将红包ID的请求放入请求队列中，假如发现超越红包的个数，直接返回。依据红包的逻辑处置成功得到令牌请求，则由财付通进行一致性调用，通过像比特币一样，两边保存买卖记录，买卖后交给第三方服务审计，假如买卖过程中出现不同就强制回归。
⑪并发性处置微信红包体系设计剖析cache会抵抗无效请求，将无效的请求过滤掉，实质进入到后台的量不大。cache记录红包个数，原子操作进行个数递减，到0表示被抢光。财付通根据20万笔每秒入账筹备，但实质还不到8万每秒。
⑫怎么样维持8w每秒的写入？
答微信红包体系设计剖析抢到红包的人数和红包都在一条cache记录上，没太大的查看重压。
⑭一个红包一个队列？
答微信红包体系设计剖析每抢到一个红包，就cas更新剩余金额和红包个数。
⑯红包怎么样入库入账？
数据库会累加已经领取的个数与金额，插入一条领取记录。入账则是后台异步操作。
⑰入帐出错如何解决？譬如红包个数没了，但余额还有？
答微信红包体系设计剖析
mmexport1442151693886
5.2.3 红包结果页面显示逻辑
说明微信红包体系设计剖析
16
"按钮"代表蓝色文字链接，如下图所示微信红包体系设计剖析
19
绿色格子代表没这种逻辑，可能是不出现该页面或者其他缘由。
对上表的数据进行挖掘，大家可以发现以下规则集微信红包体系设计剖析
仅以此文，纪念大学四年为了加入微信团队所做出的努力。
网页名字微信红包体系设计剖析
