大白话高并发（三）

背景

高并发得第三篇，讲一讲压测吧，因为我的目的是模拟100万人同时来秒杀。

是不是真的要找100万个人

没必要 ，你就算100万人掐着表在同一毫秒内把请求请求某一台机器，服务器也不可能在同一时间处理那么多请求，因为服务器的io模型大多是多路复用，网络模型是reactor，都是排队一个一个来处理的，而且单台服务器能不能承受100万并发也是个问题，所以针对短链接来说，测出来单台机器的最大qps才是关键，比如我得并发量是100万单台机器的最大qps是2万那么我就需要50台机器，（注意我这里说的是短链接，如果你是长连接肯定是要模拟100万个端，每个机器有大概6万个端口，因此需要16台机器作为客户端，服务端通过参数调整服务器的最大文件数为100万）

压测的思路

我觉得这张图特别的好，
在“并发连接与吞吐量”的图中，吞吐量的峰顶处对应的并发连接数，就是系统能处理的极限并发连接数了。
而在“延迟与吞吐量”的图中，在吞吐量颓势未显时达到设定的最大延迟处，就是系统的最大吞吐量了。

也就是说你先逐步增大并发找到qps最大那个点，比如刚开始并发100qps10000，然后并发200qps20000，并发300qps下降到19000了，并发400qps18000了，那么我们说20000qps就是这台机器最大的吞吐量了，然后我们设置一个请求响应延迟的阈值，比如我要求我们团队的接口不能超过200毫秒，那么我就看一下，虽然最大qps是20000但是每个接口的延迟是300毫秒，所以这不是我想要的，那就降低并发量，发现15000qps的时候延迟为200毫秒，所以我们就可以说每台机器的qps为15000，那么我们要是想支持100万人秒杀，就需要100/1.5大约70台机器。

还有我们常说的28定律 百分之80的用户在每天百分之20的时间来访问，假设平台用户是300万，一天24小时

（30000000.8) / （2460600.2）= 173
也就说你只要保证你的接口qps能做到173就可以应付大部分日常场景了，但是我们说的是秒杀场景，还是要求高一点

go-stress-testing

所以我们就看看github上用golang实现的压测软件，直接看源码。

main.go

dispose方法

其实就是for循环了需要多少个go携程去请求，真的没什么

http方法

一样，也只是循环了单个携程请求的数量。

总结

规定好最大延迟，测出单台机器最大qps，再根据你预计的人数，就知道了需要多少台机器

参考
https://zhuanlan.zhihu.com/p/85896572