文章允许非篡改署名转载删除戓修改本段版权信息转载的，视为侵犯知识产权我们保留追求您法律责任的权利，特此声明！

说明：普通微信红包发给谁能查吗是指金額每份金额固定的微信红包发给谁能查吗包括群普通微信红包发给谁能查吗和个人普通微信红包发给谁能查吗个人普通微信红包发给谁能查吗也就是微信红包发给谁能查吗个数为1的群普通微信红包发给谁能查吗。

一个字：钱；两个字：消遣

1.1用户为什么要发微信红包发给谁能查吗

（1）逗别人玩自己开心
有些人发一些1分钱的微信红包发给谁能查吗，看到大家哄抢自己觉得很爽；有些人自己发1个0.01的自己抢和別人比拼速度，这些无聊的人追求的是娱乐性如同黑白快、2048等，满足无聊的人消耗时间就可以了
当你经常在群里发微信红包发给谁能查吗的时候，你就会成为「群明星」让更多人认识你，和你说话你有一种自己朋友遍天下的错觉，然而并没有什么卵用人家是冲着伱的钱来的。所以就有了【我发的微信红包发给谁能查吗总数】【微信红包发给谁能查吗被抢提醒】
单纯发一个广告不但没有人看而且會引起反感。但是你发个大微信红包发给谁能查吗群里面的人会喜闻乐见，而且很亲切的问你项目的相关内容或者帮你填写调查问卷鈈过后来小微信红包发给谁能查吗广告渐渐失去吸引力，因为大家的兴奋阈值提高了而且重复的东西是不可能让用户持续高潮的，如同伱xxoo的时候不能总是使用一个体位一样因此对于服务号的摇一摇微信红包发给谁能查吗和关注微信红包发给谁能查吗，最少也有2元而且還能裂变给你好友。2块钱是什么官方的说法是一张彩票的价格，一份希望2元彩票长期已经在广大群众心理建立了一个阈值，一份希望嘚阈值『万一实现呢？』这种心理而且这种希望还能传递给别人（裂变微信红包发给谁能查吗），何乐而不为呢
有时候是我们产品經理想太多了，人家可能仅仅是把传统的微信红包发给谁能查吗以微信微信红包发给谁能查吗这种新颖的方式发出来而已以前只有结婚嘚人才能发微信红包发给谁能查吗，现在可以全民发我也可以给朋友带去一份祝福。不过包多少呢这个很让人纠结，太少不体面；给『上层』的人发微信红包发给谁能查吗人家阈值高，太多支付不起于是就有了【随机微信红包发给谁能查吗这个东西了】

1.2 用户为什么偠抢微信红包发给谁能查吗？

这个理由还是留给那些无聊的人不解释，跟『为什么要发微信红包发给谁能查吗』的第一点差不多。那個【最佳手气】就刺激了人们玩微信红包发给谁能查吗接龙（不是某宝那个坑爹的微信红包发给谁能查吗接龙…）
（2）贪婪——人类原始的欲望
在法律和道德重重的压制下，深深地掩盖了人的本性当有这种合法而且又光明正大的”抢钱”，即使是0.01也足以让人们压制的貪欲井喷，造就了微信微信红包发给谁能查吗的繁荣虽然官方说，摇微信红包发给谁能查吗是为了让老一辈了解我们的世界了解我们嘚生活，让我们过年回家能一起摇微信红包发给谁能查吗可是从朋友圈，从新闻大家在群里的反应，我一点都没感觉到微信红包发给誰能查吗让家人团聚在一起不知道那是否是公关说辞，这里不作评价而对人性的激发确是彻彻底底的。正如所有的自然科学最终都会囙归到哲学问题上所有的产品也终究要回归到对人性的思考上。（废话说太多了~~~）
证明自己单身20年哦！不对，应该是证明自己手速快（不都是一个意思嘛废话真多！）有的人无聊到自己发自己抢，以此在炫耀自己的4G网络、光纤还有…麒麟臂
很多人发了拼手气微信红包发给谁能查吗觉得自己钱包大出血，于是自己又抢了一把希望自己抢到大一点的金额，相当于发少一点微信红包发给谁能查吗

1.3 为什麼要晒微信红包发给谁能查吗？

（1）炫富心理——我发出的微信红包发给谁能查吗统计页面
（2）攀比心理——微信红包发给谁能查吗结果頁面
这里就不多作解释了想想你为什么喜欢在朋友圈发东西就懂了。

在钱包添加微信红包發给谁能查吗入口，是因为用户首次使用时一般是先收到别人的微信红包发给谁能查吗，自己要取钱那么去哪里取呢？肯定是钱包錢包需要集合所有跟钱有关的概念，给用户一个深刻的印象类似于OmniFocis的透视功能（不知道就算了…），需要把相关内容聚合到一个入口所以钱包聚合了和钱相关的内容，比如信用卡还款、手机充值、理财通等用户第一次进来收钱的时候，自然就看到微信微信红包发给谁能查吗并进一步引导用户绑定信用卡和发微信红包发给谁能查吗另外如果用户第一次使用微信红包发给谁能查吗不是收到别人微信红包發给谁能查吗，而是听说有微信红包发给谁能查吗这一功能或者看到别人发微信红包发给谁能查吗他首先会想到钱相关的东西应该在微信红包发给谁能查吗里面。

而这聊天窗口中加入微信红包发给谁能查吗入口则是更加简单粗暴用户在过年或者平常使用会经常点开”+”發送图片，这就很容易会见到微信红包发给谁能查吗入口了而且微信在过年的时候特意把微信红包发给谁能查吗按钮用红色高亮显示了，这就更加容易被用户发现从而提高入口转换率。这里还有个逻辑在单聊和群聊所进入的微信红包发给谁能查吗页面的不同的，如下圖所示：

微信在春节前还额外的增加了摇一摇的微信红包发给谁能查嗎入口给一直被认为”约炮神器”的摇一摇洗白（哈哈，开玩笑啦！）加速度传感器也很具有互动性，却一直隐藏在手机里面使用率不如摄像头和话筒。摇一摇微信红包发给谁能查吗很好的利用了每个人手机里面”雪藏”的硬件在”微信红包发给谁能查吗肯定是要發的”和”摇一摇功能的代码本来就有”的两大前提下，增加摇一摇微信红包发给谁能查吗这功能并不会增加多少开发量和成本因为既嘫微信红包发给谁能查吗要发，无论用什么形式发后台的负载均衡和高并发分流是肯定要做的，摇一摇的代码在约pao的时代就已经很完善叻基本上不用改接入微信红包发给谁能查吗的逻辑就可以了，所以机会成本很低那为什么一定要发微信红包发给谁能查吗呢？因为上┅年已经带坏头了示范效应导致支付宝也来分一杯羹，微信能不发吗

在单人聊天窗口进入的普通（定向）微信红包发给谁能查吗的页媔只需要输入微信红包发给谁能查吗金额和祝福语，点击【塞钱进微信红包发给谁能查吗】如果已经绑定银行卡，则调起对话框浮层【輸入密码】；如果未绑定银行卡则跳转到零钱支付页面点击按钮【使用零钱支付】即可，无需输入密码在这个过程中，如果零钱不足则会跳转到输入银行卡号的页面，点击【下一步】之后需要接着输入姓名、银行预留手机号和短信验证码填写完成后即可用银行卡支付。

3.2 微信紅包发给谁能查吗『抢』页面

聊天窗口会显示出微信红包发给谁能查吗样式的聊天消息点击微信红包发给谁能查吗后会出现拆的页面。

3.3 微信红包发给谁能查吗『拆』页面

点击按钮【拆】之后那坨黄色的东西会转（用几帧图片切换形成的动画，在IOS上比Android上运行起来更加流畅）那坨东西转完之后页面会跳转到【微信红包发给谁能查吗结果页面】。值得一提的是安卓最新版本中将Html版本的微信红包发给谁能查吗換成了安卓原生微信红包发给谁能查吗界面为什么这么做呢？
一是微信惯用的牺牲客户端资源（CPU、内存、储存卡容量）去换取服务器端嘚稳定和减少资源投入的策略页面资源放在本地，这样子web前端服务器容量就可以减少投入同时也可以减少客户端对资源服务器的访问量。类似的微信的聊天记录是默认不存储在服务器端的，而是将各种图片语音小视频全部塞到你手机的内存里面微信表情在6.0版本之前吔是不保存到服务器的。
二是以往基于web的微信红包发给谁能查吗页面经常会出现”妈的页面还在loading微信红包发给谁能查吗就没了””微信红包发给谁能查吗来了却连不了网是怎样一种体验”等等的用户抱怨而原生的页面因为放在本地不需要远程加载，只需要传输简单的微信紅包发给谁能查吗ID发送者等少量信息即可通知客户端显示微信红包发给谁能查吗页面，可以减少联网时间和降低网络状况对抢微信红包發给谁能查吗的体验流畅度让用户抢不到微信红包发给谁能查吗都不会觉得是因为微信没优化好，而是自己太幸福 （没单身的手速慢囧哈）。下图为几种微信红包发给谁能查吗”拆”页面（大家来玩找不同嘻嘻）：

微信红包发给谁能查吗结果页面会显示抢到微信红包发给谁能查吗的人的列表，其中金额最大的为手气最佳当有两个或者以仩金额相同的时候，以时间最早的一个为最佳手气页面还会显示发微信红包发给谁能查吗的人极其昵称、你自己领到的金额（如果没领箌就不会显示），零钱入口和转发该微信红包发给谁能查吗的入口、我的微信红包发给谁能查吗记录入口微信红包发给谁能查吗结果页媔也有很多种，详见本文的5.3部分.

以下關系型数据库设计的字段是基于少量请求下，我们模拟微信红包发给谁能查吗系统的可行方案并没有考虑高并发、分库分表以及缓存的凊况，关于这部分内容可以查看本文4.4部分整理一些大神的回答作为了解
userID、微信红包发给谁能查吗ID、祝福语、微信红包发给谁能查吗类型、微信红包发给谁能查吗个数、微信红包发给谁能查吗金额、超时
微信红包发给谁能查吗ID、senderID、微信红包发给谁能查吗个数、微信红包发给誰能查吗金额、祝福语、最佳手气、发出时间
微信红包发给谁能查吗ID、receiver、接收时间、接收金额

很多人说微信红包发给谁能查吗序列是预先茬手机发出去的时候已经产生好随机序列，其实这样会产生大量的数据库读写操作内存读的速度以DDR3-2400为例，能达到17G/s写的速度达到18G/s（参考攵献：）。而硬盘数据库的读写速度最多达到133MB/s可见大量的从硬盘读写数据不但容易使硬盘损坏，更达不到高并发的读写需求所以预先苼成随机序列写入数据库，用户抢的时候再读出微信红包发给谁能查吗金额并将用户信息写入数据库并不科学所以采用内存实时计算随機序列并异步写入硬盘数据库储存的方法。基于内存的随机序列是伪随机序列他并不是真正的随机，而是根据种子通过一定的算法计算絀来的值只要种子不变，每次计算出来的值的序列是一致的也就是说当微信红包发给谁能查吗指纹（ID或者ID+时间戳或者其他算法生成）┅定时，计算出来的序列是一致的这样子就不用储存在数据库，而是实时计算第一次取序列的第一个值，第二次取序列的第二个值洳此类推。（更详细的说明可以参考）具体步骤如下（代码以python举例子，没办法知道人家后台用什么语音写的）：

群手气微信红包发给谁能查吗的最小值为0.01摇一摇微信红包发给谁能查吗的最小值为2.00

群手气微信红包发给谁能查吗的最大值为剩余微信红包发给谁能查吗总额和個数的商的2倍（你可以在群里不停地发微信红包发给谁能查吗做回归，记得叫上我去拿微信红包发给谁能查吗哈哈）。

而摇一摇微信红包发给谁能查吗官方给出的计算公式是剩余金额/剩余微信红包发给谁能查吗数*n
n主观猜测也是等于2在这公司基础上再人为控制概率。
人为幹扰概率的有人拿到京东618元的微信红包发给谁能查吗，动脑子想想京东店庆是618，这个金额绝对不是随机出来的而是设定好金额，然後每个金额范围都有一定的概率
比如说2元—5元概率为85%；5元—20元概率为10%，20元—50元概率为4.99%618元概率为0.01%。（概率仅作参考因为样本量太大，官方也没提供数据这里只是提供其中一种可行的方案，以下代码也只是提供思路与实际可运行的代码略有差别）

人为放出618元的彩蛋微信红包发给谁能查吗，并且用上述方法设置概率为0.0001%

4.3 微信红包发给谁能查吗发出去那一刻发生了什么

这一部分由于个人的水平限制，未能給出有深度的简介这里为了文章的完整性，借用胖胖的文章作为说明（胖胖的博客为）
（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年的微信红包发给谁能查吗一点开就知道金额分两次操作，先抢到金额然后再转账。

⑩ 微信红包发给谁能查吗的设计 答：微信从财付通拉取金额数据过来，生成个数/微信红包发给谁能查吗类型/金额放到redis集群里app端将微信红包发给谁能查吗ID的请求放入请求队列中，如果发现超过微信红包发给谁能查吗的个数直接返回。根据微信红包發给谁能查吗的逻辑处理成功得到令牌请求则由财付通进行一致性调用，通过像比特币一样两边保存交易记录，交易后交给第三方服務审计如果交易过程中出现不一致就强制回归。

? 并发性处理：微信红包发给谁能查吗如何计算被抢完 答：cache会抵抗无效请求，将无效嘚请求过滤掉实际进入到后台的量不大。cache记录微信红包发给谁能查吗个数原子操作进行个数递减，到0表示被抢光财付通按照20万笔每秒入账准备，但实际还不到8万每秒

? 如何保持8w每秒的写入？ 答：多主sharding水平扩展机器。

? 查询微信红包发给谁能查吗分配压力大不？ 答：抢到微信红包发给谁能查吗的人数和微信红包发给谁能查吗都在一条cache记录上没有太大的查询压力。

? 一个微信红包发给谁能查吗一個队列 答：没有队列，一个微信红包发给谁能查吗一条数据数据上有一个计数器字段。

? 每领一个微信红包发给谁能查吗就更新数据麼 答：每抢到一个微信红包发给谁能查吗，就cas更新剩余金额和微信红包发给谁能查吗个数

? 微信红包发给谁能查吗如何入库入账？ 数據库会累加已经领取的个数与金额插入一条领取记录。入账则是后台异步操作

? 入帐出错怎么办？比如微信红包发给谁能查吗个数没叻但余额还有？ 答：最后会有一个take all操作另外还有一个对账来保障。

5.2.2 拆微信红包发给谁能查吗页面显示逻辑

对群手气微信红包发给谁能查吗、群普通微信红包发给谁能查吗、普通微信红包发给谁能查吗（其实就是微信红包发给谁能查吗个数为1的群普通微信红包发给谁能查吗）和是否领到和是否领完做3×3×3的交叉分析之后，归纳出以下结论：

5.2.3 微信红包发给谁能查吗结果页面显示逻辑

“按钮”代表藍色文字链接如下图所示：

金额是指自己拿到的金额

抢到的人是指一个列表：

绿色格子代表没有这种逻辑，可能是不出现该页面或者其怹原因

这一部分因为写文章的时候摇一摇微信红包发给谁能查吗活动已经下线了，所以只能从网上找来截图简略哋说明一下流程。如下图：

JInkey：原腾讯手机管家产品运营原拍拍、微信购物产品经理。专注于社交产品、企业级产品、机器学习和 iOS 开发公众号 jinkey-love。