Nginx之大并发服务器架构实战技法

转载自：https://www.toutiao.com/a6514293732701897223/

 

Nginx之大并发服务器架构实战技法一

对于高性能网站 ,请求量大,如何支撑?大体分为两个部分。一部分是尽量减少对服务器的请求，另一方面是提高服务器的相应能力。减少服务器的请求能力，我这里列举一下几个方面，大家可以参考。

1：对于开发人员，尽量做到能够合并css, 把多张背景图片合并, 减少mysql查询等。

2: 对于运维人员， nginx的expires 设置 ,利用浏览器缓存等,减少查询.

3: 利用第三方的cdn来响应请求，以此来减少自身服务器的压力。

4: 最终剩下的,不可避免的请求----服务器集群+负载均衡来支撑.

所以,来到第4步后,就不要再考虑减少请求这个方向了.而是思考如何更好的响应高并发请求。那么这也是我们今天着重要讲的。

Nginx之大并发服务器架构实战技法 一

对于Nginx来说，客户来请求Nginx 来响应，怎么响应，无非是读取mysql 或者是直接读取磁盘上的index.html 等等。两个方向，第一是要建socket 连接，第二是要打开文件。这就牵扯到两个硬性的限制。第一，你的socket 连接能不能建那么多。你的内存是不是足够大，因为建立socket 连接都要内存维护着他们的信息的。你打开文件，操作系统允许不允许你一次打开那么多的文件。因为在默认情况下一个进程同时只能打开1024个文件。所以你想建立高并发，高并发无非就是建立的socket 连接多，打开的文件多。只有你这两个方面能承的住。当然对你的网卡也是有要求的，起码你的网卡能够同时跑通那么多的流量。

知道了这两个大的方向之后，我们排查问题就需要从这两点入手。然后通过观察系统的dmesg 和 nginx 的error.log 来逐步解决问题。其实在真实的生产环境里面，做东西都是哪里出错了，跟着错误轨迹一点点去摸索的优化的。没有一个固定的路子说照着什么做就能达到多大的并发。

以上是架构一个高并发 Nginx 服务器的大体思路和方案。在下一篇文章中，我将会拿一个实例，运用今天所讲到的理论，从实操的角度来说明一下如何一步一步的把一个大并发的服务器架构起来。

 

Nginx之大并发服务器架构实战技法二

在上一篇文章里，我介绍了一下nginx服务器解决大并发的基本思路，现在我就要运用这些理论知识，一起来看看实际效果咋样。我们总体目标是，把一台普通的PC机nginx服务器单机，在不用其他架构和手段的情况下，单使用我们上次的理论把他优化成1万并发以上。

Nginx 之大并发服务器架构实战技法二

首先，来对这台 nginx 服务器做一下压力测试。在这里压力测试我们使用使用apache自带的ab小工具。我们先测试一下nginx 的并发性咋样。先来1000个并发，测试50000 的请求。测试结果如下图所示：

1000并发5万请求的测试结果

1000个并发显示3000多的报错

通过结果显示80%是在100毫秒内相应。90%-95%是在1秒左右相应，其中有1%超过了3秒。5万个请求，有3000多个出错。这个请求情况并不算优秀。再压一次2000个并发，8万个请求，压力测试结果显示如下：

显示报错信息：Too many open files

90%的相应都在3秒以上

通过上面的测试结果，我们看到出问题了。有一个报错： “socket: Too many open files”，而且90以上都是在3秒以上响应。所谓高并发，没有什么神奇的东西。只要你服务器硬盘快。CPU强，内存大。硬件条件要够。这个和比武一样，首先要有硬件条件，然后才能讲技巧。具体到我们这里，我们的硬件够，2000个并发应该不是问题，但是此处确提示："socket: Too many open files",其实这个报错就是我们优化的一个重要的启发。它说打开的文件太多了。我们知道，在linux 中，简介即是美，一切的操作，无论硬盘，软盘还是打印机等都当成是文件来处理。其实质是，每来一个请求，都要建立一个socket 连接，在linux 看来，就是把网卡看成了一个文件。1000多个并发，打开了1000多次次，打开的太多了。接收不了，所以报"Too many open files"错误。对于nginx 服务器，默认情况下，只允许打开1024个描述符。做高并发服务器，一下就用光了。所以我们需要把服务器允许打开的描述符变大些，调节成2000.： “ulimit -n 2000”,ab再 测试一下。

服务器允许打开描述符配置

结果发现，发现80000的请求，70000多个请求失败，那么这时候，基本上2000个并发的测试已经是撑不住了。

在刚才的测试中，看结果显示，有多少个等待的。什么叫等待呢？就类似学生去食堂买饭，好多人在等着买饭。

我们当然是希望等待越少越好。

结果中显示等待

工欲善其事，必先利其器。我们用ab小工具压2000，发现也可以压。但是我们想更详细的观察服务器的状态。比方说当前有多少客户端正在连接中、并发是多少，有多少处于等待状态。所以我们要借助与nginx 的一个统计工具来方便我们做测试。有一个选项是内建的一个nginx 的观察统计模块模块：--with-http_stub_status_module，在编译nginx 的时候，只需要指定一下就可以了。便于我们观察每时每刻到底有多少并发，多少等待。这样便于我们调优。

nginx 统计模块配置

我们现在在压力测一下。2000个并发，请求10万次，通过 观察统计模块，我们发现显示的有点异样。我们请求的是 2000个并发，但是这里显示，最多只有600多并发的样子。在看看ab 的结果，10万个并发，9万多的失败率。这个结果基本上就没法接受了。

2000个并发，结果实际显示才几百并发

10万的请求9万多失败

nginx 不尽人意，2000个并发就错误率非常高了。那么失败没有关系，正因为它失败了。而且并发低，才需要我们做优化。在这里，我们还没有对nginx 做优化处理，现在我们只是完成了压力测试和它的统计信息的观察。那么在下一篇文章，我们将在这个基础上，针对这个压力测试结果做优化。

Nginx之大并发服务器架构实战技法三

在之前两篇文章中，我分别做了大并发优化思路的详解和对nginx 2000并发的压力测试。我们发现 Nginx 不尽人意，2000个并发的时候， 就错误率非常之高。这时候我们按照之前的两个优化思路，首先我们看看nginx 的错误日志。我们看到， open"xxxx"failed,Too many open files;出问题了。这就是说操作系统不允许一个进程一次打开那么多的html文件。

Too many open files 报错。

另外一方面，我们看下socket 能否建立起来，命令： dmesg tail。我们发现“SYN flooding on port 80.sending sookies.”。服务器说，80端口被请求的特别快。是不是遭受到 洪水攻击了，所以每一次请求都带了一个 cookies ,防止别人洪水攻击。挡住了一部分。

洪水攻击报错

这就是之前说的两个方面，建立的socket 能否很多。打开的文件是否很多。我们接下来对它进行调试。

看看 ulimit -n ,发现在机器上，能打开1024个文件。然后我们把它变大。注意这个ulimit -n 20000 是操作系统层面改的。

我们通过统计模块看，并发依然不尽人意。那么我们来分析，这到底是为什么？

我们首先从两个地方来努力， 一个就是socket ,一个是文件。

socket层面 ，我们又分两个部分来讨论。一个是系统层面，一个是nginx 层面。

1、系统层面：

1）、允许打开的最大连接数：它的内核有一个叫做somaxconn。

2）、加快tcp连接的回收： 连接之后就断开了。一般它不能马上断开的，有一个延迟。tcp 是否立即回收。

它在内核有一个 recycle。

3）、空的tcp是否允许回收利用，内核有一个 reuse.

4）、 洪水攻击。那么如果系统认为是洪水攻击，抵御我们咋办呢？我们要让它不做洪水抵御。

2、nginx 层面：

1）、每一个子进程允许打开的连接，也就是 worker_connnections。

2）、http连接快速关闭 keepalive_timeout。

如上几点，在socket 层面上，我们希望能够尽可能多的socket文件，而且有人用完了还能快速回收。这就像商场，首先把座位弄多些。客人吃完饭就立即收拾，能快速回收。如果有人点了餐但是不吃了。那么这个位置需要能立即利用。同时来的客人越多越好，我们不做洪水抵御。通过这四个方向，参数需要调优。同时对于nginx worker_connnections,我允许你单个子进程允许建立多少连接，比如我们允许建立10000的连接。这是在socket 层面做的努力。

文件层面：我们也可以分为系统和nginx两个方面来考虑。

1、系统层面：ulimit -n ，需要设置一个大的值。

2、nginx 层面：子进程允许打开的文件：worker_rlimit_nofile,一个子进程最大能打开多少个文件。

那么我们把这个思路一整理，就可以动手了，如下：

首先socket, nginx 一个子进程允许打开多少个连接，我们把它调大一些，1万以上。

nginx 最大连接数

系统层面，我们看看当前系统层面的somaxconn,我们看到系统默认最大打开的连接数为128，这个肯定不行。

所以这个要放大。注意somaxsonn 这个文件不是一个真正的文件。proc是系统运行状态的数值，其实这些都是从内存读出来的。所以你如果修改这个数值，它就立即生效了。因为它是系统状态的数值。

所以我们把它修改大到50000。同时我们加快tcp 的回收。我们通过命令查看，发现值为0，那就意味着它不会快速回收，那么我们就把它修改为1，让它能够快速回收。空的tcp回收，也是直接 给响应的参数置1。

不做洪水抵御，我们先来看看当前它是否帮我们做洪水抵御了。通过tcp_syncookies,我们看到值为1，

系统在做洪水抵御。所以也不用抵御了。我们直接把它置为0就可以了。

刚才的东西，为了方便操作，我们来一个脚本，把刚才的写进脚本批量执行，把上面的四个选项调过来。它是立即生效的。那到现在为止，socket我们从nginx 和系统方面都做了加大和优化。

socket 系统方面调优参数

再来看文件层面。首先把系统层面打开的文件数量变大。ulimit -n 50000 。另外 nginx 本身是否允许你打开那么多的文件。所以在配置文件中还应该加一个：worker_rlimit_nofile 10000,一个工作进程允许打开多少个文件。

文件 nginx 层面允许打开文件数设置

nginx reload 一下，这时候，我们再一次压力测一下，5000并发，请求200000，我们看到，5000个并发，错误率为0，而且80%的请求都保持在200毫秒之内。nginx 很容易就能做到5000的并发。而且我们的机器不是什么很高档的服务器。就是普通的PC服务器，所以nginx 的性能还是值得肯定的。

我们在做一次压力测试，加一个 -k 的选项，看浏览器统计，我们看到这次waiting有了一个显著的变化。那么，-K是干什么的？我们随便打开一个浏览器的调试模式。

增加了 -k 参数的压力测试

显示keep-alive

单台5000并发错误率为0

keep-alive 这个东西是干什么的？ 有好处也有坏处。在http 1.0时代，在client 和 server 端,请求、 应答、 断开。到了http 1.1 的时候，请求你的主页，在主页上还包括了很多的css、 js、 图片，所以，请求你的主页后，你能不能不要把tcp 断开。我请求css 的时候，我的http连接建立在你刚才的http之上，就类似我排一次队，取好几次东西，那么keep-alive 在http1.1之后加上，也有好处，它就是防止了频繁的TCP握手。但是对于高并发网站来说。这里就是一个弊大于利的东西了。因为高并发网站，他们的TCP都是那么的珍贵。结果你抢到一个，还保存了那么长时间。默认为65秒。这显然是一个浪费，所以在高并发网站中 keepalive_timeout 0,是一个要严重注意的选项。如果非想用，把它控制在2秒之内。在大了就不太合适了。我们这里置为0，就是不支持这个功能了。这是，你看已经没有keepalive,取而代之的是：connection:close,这样能加快tcp的回收。

Nginx 之大并发服务器架构实战技法三

我们通过两台客户端，每台5000并发100000请求，同时压服务器，通过观察nginx 统计模块观察。发现10000的并发比较容易就实现了。而且错误率夜很低或者基本没有。最后通过我们的优化。在原来2000并发撑不住到10000并发轻松实现了。