点击上方 "程序员小乐" ，关注公众号
8点20分，第一时间与你相约
每日英文
Never give up on something you really want. It’s difficult to wait, but worse to regret.
永远不要放弃你真正想要的东西。等待虽难，但后悔更甚。
每日掏心话
有什么信念，就选择什么态度；有什么态度，就会有什么行为；有什么行为，就产生什么结果。要想结果变得好，必须选择好的信念。
来源：xiaojiaqi | 责编：乐乐
链接：github.com/xiaojiaqi/10billionhongbaos
图片来自网络
00 前言
01 背景知识
- QPS：Queries per second 每秒的请求数目
- PPS：Packets per second 每秒数据包数目
- 摇红包：客户端发出一个摇红包的请求，如果系统有红包就会返回，用户获得红包
- 发红包：产生一个红包里面含有一定金额，红包指定数个用户，每个用户会收到红包信息，用户可以发送拆红包的请求，获取其中的部分金额。
02 确定目标
在一切系统开始以前，我们应该搞清楚我们的系统在完成以后，应该有一个什么样的负载能力。 2.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亿。
总结
从单台服务器看，它需要满足下面一些条件：
- 支持至少100万连接用户
- 每秒至少能处理2.3万的QPS，这里我们把目标定得更高一些 分别设定到了3万和6万。
- 摇红包：支持每秒83个的速度下发放红包，也就是说每秒有2.3万次摇红包的请求，其中83个请求能摇到红包，其余的2.29万次请求会知道自己没摇到。当然客户端在收到红包以后，也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。因为没有支付模块，所以我们也把要求提高一倍，达到200个红包每秒的分发速度
- 支持用户之间发红包业务，确保收发两边的红包数目和红包内金额要一致。同样也设定200个红包每秒的分发速度为我们的目标。
03 基础软件和硬件
客户端：esxi 5.0 虚拟机，配置为4核 5G内存。一共17台，每台和服务器建立6万个连接。完成100万客户端模拟
04 技术分析和实现
4.1) 单机实现100万用户连接 这一点来说相对简单，笔者在几年前就早完成了单机百万用户的开发以及操作。现代的服务器都可以支持百万用户。相关内容可以查看： github代码以及相关文档： https://github.com/xiaojiaqi/C1000kPracticeGuide
系统配置以及优化文档：
https://github.com/xiaojiaqi/C1000kPracticeGuide/tree/master/docs/cn
客户端QPS
因为有100万连接连在服务器上，QPS为3万。这就意味着每个连接每33秒，就需要向服务器发一个摇红包的请求。因为单IP可以建立的连接数为6万左右， 有17台服务器同时模拟客户端行为。我们要做的就保证在每一秒都有这么多的请求发往服务器即可。 其中技术要点就是客户端协同。但是各个客户端的启动时间，建立连接的时间都不一致，还存在网络断开重连这样的情况，各个客户端如何判断何时自己需要发送请求，各自该发送多少请求呢？ 我是这样解决的：利用NTP服务，同步所有的服务器时间，客户端利用时间戳来判断自己的此时需要发送多少请求。
算法很容易实现：假设有100万用户，则用户id 为0-999999.要求的QPS为5万， 客户端得知QPS为5万，总用户数为100万，它计算 100万/5万=20，所有的用户应该分为20组，如果 time() % 20 == 用户id % 20，那么这个id的用户就该在这一秒发出请求，如此实现了多客户端协同工作。每个客户端只需要知道 总用户数和QPS 就能自行准确发出请求了。 （扩展思考：如果QPS是3万 这样不能被整除的数目，该如何办？如何保证每台客户端发出的请求数目尽量的均衡呢？）
服务器QPS
服务器端的QPS相对简单，它只需要处理客户端的请求即可。但是为了客观了解处理情况，我们还需要做2件事情。
- 第一：需要记录每秒处理的请求数目，这需要在代码里埋入计数器。
- 第二：我们需要监控网络，因为网络的吞吐情况，可以客观的反映出QPS的真实数据。为此，我利用python脚本 结合ethtool 工具编写了一个简单的工具，通过它我们可以直观的监视到网络的数据包通过情况如何。它可以客观的显示出我们的网络有如此多的数据传输在发生。
我为了减少竞争，将所有的用户分在了不同的桶里。这样可以减少对锁的竞争。如果以后还有更高的性能要求，还可以使用 高性能队列——Disruptor来进一步提高性能。 注意，在我的测试环境里是缺少支付这个核心服务的，所以实现的难度是大大的减轻了。另外提供一组数字：2016年淘宝的双11的交易峰值仅仅为12万/秒，微信红包分发速度是5万/秒，要做到这点是非常困难的。（http://mt.sohu.com/20161111/n472951708.shtml）
05 代码实现及分析
在代码方面，使用到的技巧实在不多，主要是设计思想和golang本身的一些问题需要考虑。 首先golang的goroutine 的数目控制，因为至少有100万以上的连接，所以按照普通的设计方案，至少需要200万或者300万的goroutine在工作。这会造成系统本身的负担很重。 其次就是100万个连接的管理，无论是连接还是业务都会造成一些心智的负担。 我的设计是这样的：
首先将100万连接分成多个不同的SET，每个SET是一个独立，平行的对象。每个SET 只管理几千个连接，如果单个SET 工作正常，我只需要添加SET就能提高系统处理能力。 其次谨慎的设计了每个SET里数据结构的大小，保证每个SET的压力不会太大，不会出现消息的堆积。 再次减少了gcroutine的数目，每个连接只使用一个goroutine,发送消息在一个SET里只有一个gcroutine负责，这样节省了100万个goroutine。这样整个系统只需要保留 100万零几百个gcroutine就能完成业务。大量的节省了cpu 和内存 系统的工作流程大概是：每个客户端连接成功后，系统会分配一个goroutine读取客户端的消息，当消息读取完成，将它转化为消息对象放至在SET的接收消息队列，然后返回获取下一个消息。 在SET内部，有一个工作goroutine，它只做非常简单而高效的事情，它做的事情如下，检查SET的接受消息，它会收到3类消息
- 客户端的摇红包请求消息
- 客户端的其他消息 比如聊天 好友这一类
- 服务器端对客户端消息的回应
对于第2种消息客户端的其他消息 比如聊天 好友这一类，只需简单地从队列里拿走消息，转发给后端的聊天服务队列即可，其他服务会把消息转发出去。
对于第3种消息服务器端对客户端消息的回应。SET 只需要根据消息里的用户id，找到SET里保留的用户连接对象，发回去就可以了。 对于红包产生服务，它的工作很简单，只需要按照顺序在轮流在每个SET的红包产生对列里放至红包对象就可以了。这样可以保证每个SET里都是公平的，其次它的工作强度很低，可以保证业务稳定。
见代码： https://git hub.com/xiaojiaqi/10billionhongbaos
06 实践
实践的过程分为3个阶段 阶段1 分别启动服务器端和监控端，然后逐一启动17台客户端，让它们建立起100万的链接。在服务器端，利用ss 命令 统计出每个客户端和服务器建立了多少连接。 命令如下：
结果如下：
观察网络监控和监控端反馈，发现QPS 达到预期数据，网络监控截图：
在服务器端启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包，总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。
等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。
如法炮制，在服务器端，启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包。总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。
等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。
最后，实践完成。
07 分析数据
在实践过程中，服务器和客户端都将自己内部的计数器记录发往监控端，成为了日志。我们利用简单python 脚本和gnuplt 绘图工具，将实践的过程可视化，由此来验证运行过程。 第一张是客户端的QPS发送数据：
这张图的横坐标是时间，单位是秒，纵坐标是QPS，表示这时刻所有客户端发送的请求的QPS。 图的第一区间，几个小的峰值，是100万客户端建立连接的， 图的第二区间是3万QPS 区间，我们可以看到数据 比较稳定的保持在3万这个区间。最后是6万QPS区间。但是从整张图可以看到QPS不是完美地保持在我们希望的直线上。这主要是以下几个原因造成的
- 当非常多goroutine 同时运行的时候，依靠sleep 定时并不准确，发生了偏移。我觉得这是golang本身调度导致的。当然如果cpu比较强劲，这个现象会消失。
- 因为网络的影响，客户端在发起连接时，可能发生延迟，导致在前1秒没有完成连接。
- 服务器负载较大时，1000M网络已经出现了丢包现象，可以通过ifconfig 命令观察到这个现象，所以会有QPS的波动。
和客户端的向对应的，服务器也存在3个区间，和客户端的情况很接近。但是我们看到了在大概22：57分，系统的处理能力就有一个明显的下降，随后又提高的尖状。这说明代码还需要优化。
整体观察在3万QPS区间，服务器的QPS比较稳定，在6万QSP时候，服务器的处理就不稳定了。我相信这和我的代码有关，如果继续优化的话，还应该能有更好的效果。
将2张图合并起来 ：
基本是吻合的，这也证明系统是符合预期设计的。
这是红包生成数量的状态变化图：
非常的稳定。
这是客户端每秒获取的摇红包状态：
可以发现3万QPS区间，客户端每秒获取的红包数基本在200左右，在6万QPS的时候，以及出现剧烈的抖动，不能保证在200这个数值了。我觉得主要是6万QPS时候，网络的抖动加剧了，造成了红包数目也在抖动。
最后是golang 自带的pprof 信息，其中有gc 时间超过了10ms, 考虑到这是一个7年前的硬件，而且非独占模式，所以还是可以接受。
08 总结
按照设计目标，我们模拟和设计了一个支持100万用户，并且每秒至少可以支持3万QPS，最多6万QPS的系统，简单模拟了微信的摇红包和发红包的过程。可以说达到了预期的目的。 如果600台主机每台主机可以支持6万QPS，只需要7分钟就可以完成 100亿次摇红包请求。 虽然这个原型简单地完成了预设的业务，但是它和真正的服务会有哪些差别呢？我罗列了一下
Refers：
- 单机百万的实践
- 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
欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，学习能力的提升上有新的认识，欢迎转发分享给更多人。
欢迎各位读者加入程序员小乐技术群，在公众号后台回复“加群”或者“学习”即可。
猜你还想看
看完感觉我 RecyclerView 白学了！
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
