「米粒创意」扛住100亿次红包请求的后端架构设计前言偶然看到了《

前言
偶然看到了《扛住100亿次请求——如何做一个“有把握”的春晚红包系统》一文，看完以后，感慨良多，收益很多。正所谓他山之石，可以攻玉，虽然此文发表于2015年，我看到时已经过去良久，但是其中的思想仍然可以为很多后端设计借鉴。
同时作为一名微信后端工程师，看完以后又会思考，学习了这样的文章以后，是否能给自己的工作带来一些实际的经验呢？所谓纸上得来终觉浅，绝知此事要躬行，能否自己实践一下100亿次红包请求呢？否则读完以后脑子里能剩下的东西不过就是100亿1400万QPS整流这样的字眼，剩下的文章将展示作者是如何以此过程为目标，在本地环境的模拟了此过程。
实现的目标：单机支持100万连接，模拟了摇红包和发红包过程，单机峰值QPS6万，平稳支持了业务。
注：本文以及作者所有内容，仅代表个人理解和实践，过程和微信团队没有任何关系，真正的线上系统也不同，只是从一些技术点进行了实践，请读者进行区分。
背景知识
QPS：Queriespersecond每秒的请求数目。
PPS：Packetspersecond每秒数据包数目。
摇红包：客户端发出一个摇红包的请求，如果系统有红包就会返回，用户获得红包。
发红包：产生一个红包里面含有一定金额，红包指定数个用户，每个用户会收到红包信息，用户可以发送拆红包的请求，获取其中的部分金额。
确定目标
在一切系统开始以前，我们应该搞清楚我们的系统在完成以后，应该有一个什么样的负载能力。
用户总数
通过文章我们可以了解到接入服务器638台，服务上限大概是14.3亿用户，所以单机负载的用户上限大概是14.3亿/638台=228万用户/台。
但是目前中国肯定不会有14亿用户同时在线，参考http://qiye.qianzhan.com/show/detail/160818-b8d1c700.html的说法， 2016年Q2微信用户大概是8亿，月活在5.4亿左右。所以在2015年春节期间，虽然使用的用户会很多，但是同时在线肯定不到5.4亿。
服务器数量
一共有638台服务器，按照正常运维设计，我相信所有服务器不会完全上线，会有一定的硬件冗余，来防止突发硬件故障。假设一共有600台接入服务器。
单机需要支持的负载数
每台服务器支持的用户数：5.4亿/600=90万。也就是平均单机支持90万用户。如果真实情况比90万更多，则模拟的情况可能会有偏差，但是我认为QPS在这个实验中更重要。
单机峰值QPS
文章中明确表示为1400万QPS 。这个数值是非常高的，但是因为有600台服务器存在，所以单机的QPS为1400万/600=约为2.3万QPS ，文章曾经提及系统可以支持4000万QPS ，那么系统的QPS至少要到4000万/600=约为6.6万,这个数值大约是目前的3倍，短期来看并不会被触及。但是我相信应该做过相应的压力测试。
发放红包
文中提到系统以5万个每秒的下发速度，那么单机每秒下发速度50000/600＝83个/秒，也就是单机系统应该保证每秒以83个的速度下发即可。
最后考虑到系统的真实性，还至少有用户登录的动作，真实的系统还会包括聊天这样的服务业务。
最后整体看一下100亿次摇红包这个需求，假设它是均匀地发生在春节联欢晚会的4个小时里，那么服务器的QPS应该是10000000000/600/3600/4.0=1157 。也就是单机每秒1000多次，这个数值其实并不高。
如果完全由峰值速度1400万消化10000000000/(1400*10000)=714秒，也就是说只需要峰值坚持11分钟，就可以完成所有的请求。可见互联网产品的一个特点就是峰值非常高，持续时间并不会很长。
总结
从单台服务器看，它需要满足下面一些条件：
①支持至少100万连接用户。
②每秒至少能处理2.3万的QPS ，这里我们把目标定得更高一些，分别设定到了3万和6万。