nginx查看并发连接数(nginx的并发访问量最大多少)

nginx的并发访问量最大多少

启动失败的解决办法：Nginx 是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点开发的，第一个公开版本0.1.0发布于2004年10月4日。特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好。

nginx 并发量

1，快速响应：nginx的单次请求会得到更快的响应，另一方面，在高峰期（如有数以万计的并发请求），Nginx可以比其他Web服务器更快地响应请求（官方说nginx可以支持五万并发），尤其是对静态资源的返回，更为迅速。

2，跨平台性，高扩展性：nginx的设计极具扩展性，它是由多个不同功能，不同层次，不同类型且耦合度极低的模块组成，比如HTTP模块中，还设计了HTTP过滤模块，一个正常的HTTP模块处理完请求后，会有一连串的HTTP过滤模块再对其进行过滤，我们开发一个新的HTTP模块时，可以使用HTTP核心模块 events模块 log模块等 还可以自由的复用各种过滤器模块。因此，当对某一个模块修复Bug或进行升级时，可以专注于模块自身，无须在意其他。这种低耦合度的优秀设计，造就了Nginx庞大的第三方模块，当然，公开的第三方模块也如官方发布的模块一样容易使用。

Nginx的模块都是嵌入到二进制文件中执行的，无论官方发布的模块还是第三方模块都是如此。这使得第三方模块一样具备极其优秀的性能，充分利用Nginx的高并发特性，因此，许多高流量的网站都倾向于开发符合自己业务特性的定制模块。

3，高可靠性：经过了实践的检验，功能丰富且稳定。nginx每个worker子进程相对独立，master进程在一个worker子进程出错时可以快速拉起新的worker子进程继续提供服务

4，低内存消耗

一般情况下，10 000个非活跃的HTTP Keep-Alive连接在Nginx中仅消耗2.5MB的内存，这是Nginx支持高并发连接的基础。

5，高并发处理

nginx支持的并发连接上限取决于内存，单机上万的并发量解决起来轻轻松松

6，热部署

master管理进程与worker工作进程的分离设计，使得nginx在不间断提供服务的情况下支持更新配置，更换日志文件，升级nginx可执行文件等

7，支持BSD许可协议

BSD开源协议是一个给予使用者很大自由的协议。基本上使用者可以"为所欲为",可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布

nginx最大并发连接数

先不考虑服务器资源是否够，瓶颈会首先出现在数据库读写，假设现在有34W并发，而且根据访问性质来看应该是报名操作，而报名操作是带有数据库CRUD的，Mysql的最大连接数是2000(假设没做分库分表，5W rmb让开发商做分库分表显然是不可能的)，一般用到80%就很不错了，所以连接数用1600来算。然后假设数据库能在100ms内返回(想必也不是什么好机器)，那么一个连接1s能进行10次操作，那么1600连接用满，能进行1.6W次数据库操作。

但这个也只是理论上的峰值，在实际项目中，单库是绝达不到1.6W写入的，并且还是涉及到多表操作的情况下。

实际上根据《高性能MySQL》第三版 1.5小节，在如下的测试环境中

测试机器Cisco UCSC250

内存384GB

存储引擎是InnoDB

测试的数据集2.5GB

MySQL的buffer pool设置为4GB

所以在内存为384G的机器上，吞吐量不会超过8000。那么384G机器要多少钱呢？

这是64G机器的价格，因此384=64*6 6*1.8W=10.8W/年

因此，如果要并发支持到8000，光数据库就至少需要10W/Y。当然，这是假设请求在1s内返回的情况，假设我们允许服务能在5s内返回，那么此时并发能支持到4W。还是在不考虑服务器，网络损耗的情况下，实际上是远远达不到的。

所以，用5w来支持38w并发，是绝不可能的。

回到我们刚才的计算，假设数据库吞吐量到达理论峰值，能支持8000用户同时访问，如果每个客户能等待5s的化，能支持4w用户(前提是这些用户不可以同时访问，需要在5s内做到均匀分布，此时需要通过限流等手段来实现)

要支持8000用户同时访问，又需要多少个应用服务器呢？

假设我们使用tomcat服务，每个线程所占空间为8M，那么光tomcat线程就需要: 8000*8=64000=64G，当然还需要有主机内存，损耗啥的，按照一倍计算就是128G，那么需要是2*1.8W=3.6W

所以，如果需要支持4w个用户5s延时的访问，需要3.6+10.8= 14.4w rmb

这还只是服务器的钱，不算开发成本在内

那么，如果要支持38w的并发报名呢？这已经是一个相当大的并发量了，首先需要考虑的是抛弃掉一部分流量，可以在cdn就直接抛弃，或是nginx，或者直接在应用服务器上，比如在这种情况下就只能保持8000/380000 = 2%，只能有2%的请求允许进来。

可以通过nginx+redis的方式抛弃掉98%的请求，这样可以不用浪费应用服务器资源。或者直接在应用服务器上做操作，抛弃掉无法响应的请求，避免流量拖垮整个系统。

nginx并发量过高怎么处理

　　Nginx会按需同时运行多个进程：一个主进程(master)和几个工作进程(worker)，配置了缓存时还会有缓存加载器进程(cache loader)和缓存管理器进程(cache manager)等。Nginx主要通过“共享内存”的机制实现进程间通信。主进程以root用户身份运行，而worker、cache loader和cache manager均应以非特权用户身份运行。　　在工作方式上，Nginx分为单工作进程和多工作进程两种模式。在单工作进程模式下，除主进程外，还有一个工作进程，工作进程是单线程的；在多工作进程模式下，每个工作进程包含多个线程。Nginx默认为单工作进程模式。

nginx10万并发

要解决高并发问题，先要了解负载均衡。什么是负载均衡？

当一台服务器的性能达到极限时，我们可以使用服务器集群来提高网站的整体性能。那么，在服务器集群中，需要有一台服务器充当调度者的角色，用户的所有请求都会首先由它接收，调度者再根据每台服务器的负载情况将请求分配给某一台后端服务器去处理。

那么在这个过程中，调度者如何合理分配任务，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡问题。

下面详细介绍负载均衡的五种实现方式

（一）HTTP重定向实现负载均衡

过程描述

当用户向服务器发起请求时，请求首先被集群调度者截获；调度者根据某种分配策略，选择一台服务器，并将选中的服务器的IP地址封装在HTTP响应消息头部的Location字段中，并将响应消息的状态码设为302，最后将这个响应消息返回给浏览器。

当浏览器收到响应消息后，解析Location字段，并向该URL发起请求，然后指定的服务器处理该用户的请求，最后将结果返回给用户。

在使用HTTP重定向来实现服务器集群负载均衡的过程中，需要一台服务器作为请求调度者。用户的一项操作需要发起两次HTTP请求，一次向调度服务器发送请求，获取后端服务器的IP，第二次向后端服务器发送请求，获取处理结果。

调度策略

随机分配策略

当调度服务器收到用户请求后，可以随机决定使用哪台后端服务器，然后将该服务器的IP封装在HTTP响应消息的Location属性中，返回给浏览器即可。

轮询策略(RR)

调度服务器需要维护一个值，用于记录上次分配的后端服务器的IP。那么当新的请求到来时，调度者将请求依次分配给下一台服务器。

由于轮询策略需要调度者维护一个值用于记录上次分配的服务器IP，因此需要额外的开销；此外，由于这个值属于互斥资源，那么当多个请求同时到来时，为了避免线程的安全问题，因此需要锁定互斥资源，从而降低了性能。而随机分配策略不需要维护额外的值，也就不存在线程安全问题，因此性能比轮询要高。

优缺点分析

采用HTTP重定向来实现服务器集群的负载均衡实现起来较为容易，逻辑比较简单，但缺点也较为明显。

在HTTP重定向方法中，调度服务器只在客户端第一次向网站发起请求的时候起作用。当调度服务器向浏览器返回响应信息后，客户端此后的操作都基于新的URL进行的(也就是后端服务器)，此后浏览器就不会与调度服务器产生关系，进而会产生如下几个问题：

由于不同用户的访问时间、访问页面深度有所不同，从而每个用户对各自的后端服务器所造成的压力也不同。而调度服务器在调度时，无法知道当前用户将会对服务器造成多大的压力，因此这种方式无法实现真正意义上的负载均衡，只不过是把请求次数平均分配给每台服务器罢了。

若分配给该用户的后端服务器出现故障，并且如果页面被浏览器缓存，那么当用户再次访问网站时，请求都会发给出现故障的服务器，从而导致访问失败。

（二）DNS负载均衡

首先需要将我们的域名指向多个后端服务器(将一个域名解析到多个IP上)，再设置一下调度策略，那么我们的准备工作就完成了，接下来的负载均衡就完全由DNS服务器来实现。

当用户向我们的域名发起请求时，DNS服务器会自动地根据我们事先设定好的调度策略选一个合适的IP返回给用户，用户再向该IP发起请求。

调度策略

一般DNS提供商会提供一些调度策略供我们选择，如随机分配、轮询、根据请求者的地域分配离他最近的服务器。

优缺点分析

DNS负载均衡最大的优点就是配置简单。服务器集群的调度工作完全由DNS服务器承担，那么我们就可以把精力放在后端服务器上，保证他们的稳定性与吞吐量。而且完全不用担心DNS服务器的性能，即便是使用了轮询策略，它的吞吐率依然卓越。此外，DNS负载均衡具有较强了扩展性，你完全可以为一个域名解析较多的IP，而且不用担心性能问题。

但是，由于把集群调度权交给了DNS服务器，从而我们没办法随心所欲地控制调度者，没办法定制调度策略。

DNS服务器也没办法了解每台服务器的负载情况，因此没办法实现真正意义上的负载均衡。它和HTTP重定向一样，只不过把所有请求平均分配给后端服务器罢了。

此外，当我们发现某一台后端服务器发生故障时，即使我们立即将该服务器从域名解析中去除，但由于DNS服务器会有缓存，该IP仍然会在DNS中保留一段时间，那么就会导致一部分用户无法正常访问网站。这是一个致命的问题！好在这个问题可以用动态DNS来解决。

动态DNS

动态DNS能够让我们通过程序动态修改DNS服务器中的域名解析。从而当我们的监控程序发现某台服务器挂了之后，能立即通知DNS将其删掉。

综上所述

DNS负载均衡是一种粗犷的负载均衡方法，这里只做介绍，不推荐使用。

（三）反向代理负载均衡（nginx+uwsgi）

什么是正向代理，正向代理是内网通过代理访问外网，这个代理就是正向代理。而反向代理是指，外网通过代理访问内网，那这个代理就是反向代理。

假设把你公司的网看成是内网，那么你从公司里面的一台电脑上访问你家里的电脑上的服务，那就的通过正向代理，而你从你家电脑访问公司的这台电脑，就要通过反向代理。

使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术，让代理服务器将请求 均匀转发给多台内部Web服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web 服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。

反向代理处于web服务器这边，反向代理服务器提供负载均衡的功能，同时管理一组web服务器，它根据负载均衡算法将请求的浏览器访问转发到不同的web服务器处理，处理结果经过反向服务器返回给浏览器。

优点：

隐藏后端服务器。

与HTTP重定向相比，反向代理能够隐藏后端服务器，所有浏览器都不会与后端服务器直接交互，从而能够确保调度者的控制权，提升集群的整体性能。

故障转移

与DNS负载均衡相比，反向代理能够更快速地移除故障结点。当监控程序发现某一后端服务器出现故障时，能够及时通知反向代理服务器，并立即将其删除。

合理分配任务

HTTP重定向和DNS负载均衡都无法实现真正意义上的负载均衡，也就是调度服务器无法根据后端服务器的实际负载情况分配任务。但反向代理服务器支持手动设定每台后端服务器的权重。我们可以根据服务器的配置设置不同的权重，权重的不同会导致被调度者选中的概率的不同。

缺点：

调度者压力过大

由于所有的请求都先由反向代理服务器处理，那么当请求量超过调度服务器的最大负载时，调度服务器的吞吐率降低会直接降低集群的整体性能。

制约扩展

当后端服务器也无法满足巨大的吞吐量时，就需要增加后端服务器的数量，可没办法无限量地增加，因为会受到调度服务器的最大吞吐量的制约。

（四）IP负载均衡

原理：在网络层通过修改目标地址进行负载均衡。

用户访问请求到达负载均衡服务器，负载均衡服务器在操作系统内核进程获取网络数据包，根据算法得到一台真实服务器地址，然后将用户请求的目标地址修改成该真实服务器地址，数据处理完后返回给负载均衡服务器，负载均衡服务器收到响应后将自身的地址修改成原用户访问地址后再讲数据返回回去。类似于反向服务器负载均衡。

优点：在响应请求时速度较反向服务器负载均衡要快。

缺点：当请求数据较大（大型视频或文件）时，速度较慢。

（五）数据链路层负载均衡

原理：在数据链路层修改Mac地址进行负载均衡。

负载均衡服务器的IP和它所管理的web 服务群的虚拟IP一致；

负载均衡数据分发过程中不修改访问地址的IP地址，而是修改Mac地址；

通过这两点达到不修改数据包的原地址和目标地址就可以进行正常的访问。

优点：不需要负载均衡服务器进行地址的转换。数据响应时不需要经过负载均衡服务器。

缺点：负载均衡服务器的网卡带宽要求较高。

nginx最高并发量

apache与nginx的区别：

最核心的区别在于apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程 。nginx处理静态文件好,耗费内存少.但无疑apache仍然是目前的主流,有很多丰富的特性.所以还需要搭配着来.当然如果能确定nginx就适合需求,那么使用nginx会是更经济的方式。

nginx的负载能力比apache高很多。最新的服务器也改用nginx了。而且nginx改完配置能-t测试一下配置有没 有问题。

apache重启的时候发现配置出错了，会很崩溃，改的时候都会非常小心翼翼现在看有好多集群站，前端nginx抗并发，后端apache集群， 配合的也不错。

nginx处理动态请求是鸡肋，一般动态请求要apache去做，nginx只适合静态和反向。