实现的目标：单机支持100万连接，模拟了摇红包和发红包过程，单机峰值QPS 6万，平稳支持了业务。

QPS：Queries per second（每秒的请求数目）。

PPS：Packets per second（每秒数据包数目）。

摇红包：客户端发出一个摇红包的请求，如果系统有红包就会返回，用户获得红包。

发红包：产生一个红包里面含有一定金额，红包指定数个用户，每个用户会收到红包信息，用户可以发送拆红包的请求，获取其中的部分金额。

在一切系统开始以前，我们应该搞清楚我们的系统在完成以后，应该有一个什么样的负载能力。

通过文章我们可以了解到接入服务器 638 台，服务上限大概是 14.3 亿用户， 所以单机负载的用户上限大概是 14.3 亿/638 台=228 万用户/台。

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 在这个实验中更重要。

文章中明确表示为 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 万。

③摇红包：支持每秒 83 个的速度下发放红包，也就是说每秒有 2.3 万次摇红包的请求，其中 83 个请求能摇到红包，其余的 2.29 万次请求会知道自己没摇到。

当然客户端在收到红包以后，也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。

因为没有支付模块，所以我们也把要求提高一倍，达到 200 个红包每秒的分发速度。

④支持用户之间发红包业务，确保收发两边的红包数目和红包内金额要一致。同样也设定 200 个红包每秒的分发速度为我们的目标。

想要完整地模拟整个系统实在是太难了，首先需要海量的服务器，其次需要上亿的模拟客户端。

这对我来说是办不到，但是有一点可以确定，整个系统是可以水平扩展的，所以我们可以模拟 100 万客户端，再模拟一台服务器，那么就完成了 1/600 的模拟。

和现有系统区别：和大部分高 QPS 测试的不同，本系统的侧重点有所不同。

Golang 1.8r3，Shell，Python（开发没有使用 C++ 而是使用了 Golang，是因为使用 Golang 的最初原型达到了系统要求。虽然 Golang 还存在一定的问题，但是和开发效率比，这点损失可以接受）。

服务器操作系统：Ubuntu 12.04。

客户端操作系统：debian 5.0。

服务端：dell R2950。8 核物理机，非独占有其他业务在工作，16G 内存。这台硬件大概是 7 年前的产品，性能要求应该不是很高。

客户端：esxi 5.0 虚拟机，配置为 4 核 5G 内存。一共 17 台，每台和服务器建立 6 万个连接，完成 100 万客户端模拟。

这一点来说相对简单，笔者在几年前就早完成了单机百万用户的开发以及操作。现代的服务器都可以支持百万用户。相关内容可以查看 Github 代码以及相关文档、系统配置以及优化文档。

这个问题需要分 2 个部分来看客户端方面和服务器方面。

①客户端 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

服务器端的 QPS 相对简单，它只需要处理客户端的请求即可。但是为了客观了解处理情况，我们还需要做 2 件事情。

第一：需要记录每秒处理的请求数目，这需要在代码里埋入计数器。

第二：需要监控网络，因为网络的吞吐情况，可以客观的反映出 QPS 的真实数据。

为此，我利用 Python 脚本结合 ethtool 工具编写了一个简单的工具，通过它我们可以直观地监视到网络的数据包通过情况如何。它可以客观地显示出我们的网络有如此多的数据传输在发生。

摇红包的业务非常简单，首先服务器按照一定的速度生产红包。红包没有被取走的话，就堆积在里面。

服务器接收一个客户端的请求，如果服务器里现在有红包就会告诉客户端有，否则就提示没有红包。

因为单机每秒有 3 万的请求，所以大部分的请求会失败。只需要处理好锁的问题即可。

我为了减少竞争，将所有的用户分在了不同的桶里。这样可以减少对锁的竞争。

如果以后还有更高的性能要求，还可以使用高性能队列——Disruptor 来进一步提高性能。

注意，在我的测试环境里是缺少支付这个核心服务的，所以实现的难度是大大地减轻了。

另外提供一组数字：2016 年淘宝的双 11 的交易峰值仅仅为 12 万/秒，微信红包分发速度是 5 万/秒，要做到这点是非常困难的。

发红包的业务很简单，系统随机产生一些红包，并且随机选择一些用户，系统向这些用户提示有红包。

这些用户只需要发出拆红包的请求，系统就可以随机从红包中拆分出部分金额，分给用户，完成这个业务。同样这里也没有支付这个核心服务。

最后，我们需要一套监控系统来了解系统的状况，我借用了我另一个项目里的部分代码完成了这个监控模块，利用这个监控，服务器和客户端会把当前的计数器内容发往监控，监控需要把各个客户端的数据做一个整合和展示。

同时还会把日志记录下来，给以后的分析提供原始数据。线上系统更多使用 opentsdb 这样的时序数据库，这里资源有限，所以用了一个原始的方案。

在代码方面，使用到的技巧实在不多，主要是设计思想和 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 类消息：

参考链接：

https://github.com/xiaojiaqi/10billionhongbaos

命令如下：

Alias ss2=Ss –ant | grep 1025 | grep EST | awk –F: “{print \$8}” | sort | uniq –c’

结果如下：

运行如下命令：

观察网络监控和监控端反馈，发现 QPS 达到预期数据，网络监控截图：

此时观察客户端在监控上的日志，会发现基本上以 200 个每秒的速度获取到红包。

等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成 2 万个红包，每秒也是 200 个，每个红包随机指定 3 位用户，并向这 3 个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。

利用客户端的 HTTP 接口，将所有的客户端 QPS 调整到 6 万，让客户端发出 6W QPS 强度的请求。

第一张是客户端的 QPS 发送数据：

将两张图合并起来：

这是红包生成数量的状态变化图：

这是客户端每秒获取的摇红包状态：

最后是 Golang 自带的 pprof 信息，其中有 GC 时间超过了 10ms, 考虑到这是一个 7 年前的硬件，而且非独占模式，所以还是可以接受。

我罗列了一下：