硬核文章：扛住 100 亿次请求？我们来试一试
点击上方 Java后端，选择 设为星标
作者 | ppmsn2005#gmail.com
项目 | github.com/xiaojiaqi/10billionhongbaos
1. 前言
前几天，偶然看到了 《扛住100亿次请求：如何做一个有把握的春晚红包系统》(http://www.infoq.com/cn/presentations/how-to-build-a-spring-festival-bonus-system）一文，看完以后，感慨良多，收益很多。正所谓他山之石，可以攻玉，虽然此文发表于2015年,我看到时已经是2016年末，但是其中的思想仍然是可以为很多后端设计借鉴，。同时作为一个工程师，看完以后又会思考，学习了这样的文章以后，是否能给自己的工作带来一些实际的经验呢？所谓纸上得来终觉浅，绝知此事要躬行，能否自己实践一下100亿次红包请求呢？否则读完以后脑子里能剩下的东西 不过就是100亿 1400万QPS整流 这样的字眼，剩下的文章将展示作者是如何以此过程为目标，在本地环境的模拟了此过程。
实现的目标: 单机支持100万连接，模拟了摇红包和发红包过程，单机峰值QPS 6万，平稳支持了业务。
注：本文以及作者所有内容，仅代表个人理解和实践，过程和微信团队没有任何关系，真正的线上系统也不同，只是从一些技术点进行了实践，请读者进行区分。因作者水平有限，有任何问题都是作者的责任，有问题请联系 ppmsn2005#gmail.com. 全文内容 扛住100亿次请求？我们来试一试
2. 背景知识
QPS: Queries per second 每秒的请求数目
PPS：Packets per second 每秒数据包数目
摇红包：客户端发出一个摇红包的请求，如果系统有红包就会返回，用户获得红包
发红包：产生一个红包里面含有一定金额，红包指定数个用户，每个用户会收到红包信息，用户可以发送拆红包的请求，获取其中的部分金额。
3. 确定目标
在一切系统开始以前，我们应该搞清楚我们的系统在完成以后，应该有一个什么样的负载能力。
3.1 用户总数:
通过文章我们可以了解到接入服务器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亿。
3.2. 服务器数量：
一共有638台服务器，按照正常运维设计，我相信所有服务器不会完全上线，会有一定的硬件冗余，来防止突发硬件故障。假设一共有600台接入服务器。
3.3 单机需要支持的负载数：
每台服务器支持的用户数：5.4亿/600 = 90万。也就是平均单机支持90万用户。如果真实情况比90万更多，则模拟的情况可能会有偏差，但是我认为QPS在这个实验中更重要。
3.4. 单机峰值QPS：
3.5. 发放红包：
总结：
从单台服务器看.它需要满足下面一些条件
1. 支持至少100万连接用户
2. 每秒至少能处理2.3万的QPS，这里我们把目标定得更高一些 分别设定到了3万和6万。
3. 摇红包：支持每秒83个的速度下发放红包，也就是说每秒有2.3万次摇红包的请求，其中83个请求能摇到红包，其余的2.29万次请求会知道自己没摇到。当然客户端在收到红包以后，也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。因为没有支付模块，所以我们也把要求提高一倍，达到200个红包每秒的分发速度
4. 支持用户之间发红包业务，确保收发两边的红包数目和红包内金额要一致。同样也设定200个红包每秒的分发速度为我们的目标。
和大部分高QPS测试的不同，本系统的侧重点有所不同。我对2者做了一些对比。
4. 基础软件和硬件
Golang 1.8r3 , shell, python (开发没有使用c++ 而是使用了golang, 是因为使用golang 的最初原型达到了系统要求。虽然golang 还存在一定的问题，但是和开发效率比，这点损失可以接受)
4.2硬件环境
服务端：dell R2950
8核物理机，非独占有其他业务在工作，16G内存。这台硬件大概是7年前的产品，性能应该不是很高要求。
服务器硬件版本：
客户端：esxi 5.0 虚拟机,配置为4核 5G内存。一共17台，每台和服务器建立6万个连接。完成100万客户端模拟
5. 技术分析和实现
5.1) 单机实现100万用户连接
这一点来说相对简单，笔者在几年前就早完成了单机百万用户的开发以及操作。现代的服务器都可以支持百万用户。相关内容可以查看
github代码以及相关文档。
其中技术要点就是客户端协同。但是各个客户端的启动时间，建立连接的时间都不一致，还存在网络断开重连这样的情况，各个客户端如何判断何时自己需要发送请求，各自该发送多少请求呢？
5.3) 摇红包业务
摇红包的业务非常简单，首先服务器按照一定的速度生产红包。红包没有被取走的话，就堆积在里面。服务器接收一个客户端的请求，如果服务器里现在有红包就会告诉客户端有，否则就提示没有红包。
因为单机每秒有3万的请求，所以大部分的请求会失败。只需要处理好锁的问题即可。
我为了减少竞争，将所有的用户分在了不同的桶里。这样可以减少对锁的竞争。如果以后还有更高的性能要求，还可以使用 高性能队列——Disruptor来进一步提高性能。
注意，在我的测试环境里是缺少支付这个核心服务的，所以实现的难度是大大的减轻了。另外提供一组数字：2016年淘宝的双11的交易峰值仅仅为12万/秒，微信红包分发速度是5万/秒，要做到这点是非常困难的。（http://mt.sohu.com/20161111/n472951708.shtml）
5.5）监控
最后 我们需要一套监控系统来了解系统的状况，我借用了我另一个项目(https://github.com/xiaojiaqi/fakewechat) 里的部分代码完成了这个监控模块，利用这个监控，服务器和客户端会把当前的计数器内容发往监控，监控需要把各个客户端的数据做一个整合和展示。同时还会把日志记录下来，给以后的分析提供原始数据。线上系统更多使用opentsdb这样的时序数据库，这里资源有限,所以用了一个原始的方案。
首先golang的goroutine 的数目控制，因为至少有100万以上的连接，所以按照普通的设计方案，至少需要200万或者300万的goroutine在工作。这会造成系统本身的负担很重。
其次就是100万个连接的管理，无论是连接还是业务都会造成一些心智的负担。
我的设计是这样的：
1， 客户端的摇红包请求消息2， 客户端的其他消息 比如聊天 好友这一类3， 服务器端对客户端消息的回应
对于 第1种消息 客户端的摇红包请求消息 是这样处理的，从客户端拿到摇红包请求消息，试图从SET的红包队列里 获取一个红包，如果拿到了就把红包信息 返回给客户端，否则构造一个没有摇到的消息，返回给对应的客户端。
对于第2种消息 客户端的其他消息 比如聊天 好友这一类，只需简单地从队列里拿走消息，转发给后端的聊天服务队列即可，其他服务会把消息转发出去。
对于第3种消息 服务器端对客户端消息的回应。SET 只需要根据消息里的用户id，找到SET里保留的用户连接对象，发回去就可以了。
对于红包产生服务，它的工作很简单，只需要按照顺序在轮流在每个SET的红包产生对列里放至红包对象就可以了。这样可以保证每个SET里都是公平的，其次它的工作强度很低，可以保证业务稳定。
https://github.com/xiaojiaqi/10billionhongbaos
命令如下：
Alias ss2=Ss –ant | grep 1025 | grep EST | awk –F: “{print $8}” | sort | uniq –c’运行如下命令：
网络监控截图
等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。
图的第一区间，几个小的峰值，是100万客户端建立连接的， 图的第二区间是3万QPS 区间，我们可以看到数据 比较稳定的保持在3万这个区间。最后是6万QPS区间。但是从整张图可以看到QPS不是完美地保持在我们希望的直线上。这主要是以下几个原因造成的
当非常多goroutine 同时运行的时候，依靠sleep 定时并不准确，发生了偏移。我觉得这是golang本身调度导致的。当然如果cpu比较强劲，这个现象会消失。 因为网络的影响，客户端在发起连接时，可能发生延迟，导致在前1秒没有完成连接。 服务器负载较大时，1000M网络已经出现了丢包现象，可以通过ifconfig 命令观察到这个现象，所以会有QPS的波动。
非常的稳定。
如果600台主机每台主机可以支持6万QPS，只需要7分钟就可以完成 100亿次摇红包请求。
单机百万的实践 https://github.com/xiaojiaqi/C1000kPracticeGuide 如何在AWS上进行100万用户压力测试 https://github.com/xiaojiaqi/fakewechat/wiki/Stress-Testing-in-the-Cloud 构建一个你自己的类微信系统 https://github.com/xiaojiaqi/fakewechat/wiki/Design http://djt.qq.com/article/view/1356 http://techblog.cloudperf.net/2016/05/2-million-packets-per-second-on-public.html http://datacratic.com/site/blog/1m-qps-nginx-and-ubuntu-1204-ec2 @火丁笔记 http://huoding.com/2013/10/30/296 https://gobyexample.com/non-blocking-channel-operations
【END】