情景：某网站进行高峰期访问时(小高峰期，大概3500人访问量，网络流量大概60 Mbps)，Nginx的error.log一直打印 Upstream timed out 的相关日志信息。起初只有大概3000人的访问时，只会出现个别提示：请求错误 的问题，一会儿后又自动恢复了，以为是用户网络的问题，就没太在意；过了不到三天，访问量达到3500人时，出现大批量的请求错误，这时候就觉得事情不对劲，而且一直无法向之前一样自动恢复，Nginx一直打印 Upstream timed out 的错误日志信息。
系统部分架构：前端有部署两台A和B，请求通过公司的nginx转发到自己内部的nginx（内部ng与服务1属于同一台服务器），然后再到服务应用，但服务2属于冷备份，用于服务1崩溃时切换，在内部nginx上关闭了发往服务2的请求，所以服务2不提供服务。
1. 了解no live upstreams是什么？
no live upstreams 翻译：没有上游的响应
2. 内部nginx产生no live upstreams的主要原因？
1.后端服务挂了 2.后端应用性能达到瓶颈，比如 CPU、内存跑满，带宽跑满等 3.后端应用响应超时 4.防火墙配置问题 5.HTTP 头部过大 6.DNS 配置问题 *因为之前功能都是正常的，而且最近也没有进行版本更新，所以可以排除4，5，6三点 *查看了进程以及后台日志，没有错误日志产生，所以排除1 *内部nginx与服务是部署同一台服务器，也查看了CPU、内存、连接数等监控数据，也是正常，排除2 *至于第三点，看nginx有打印关于邮件的服务超时，但服务没有打印这个错误日志， 当时心想一个邮件服务超时，也不至于导致整个服务不能用吧，况且之前也有这个问题， 但都是正常运行的，于是暂且搁置这个问题
3. 既然服务没什么大问题，那么就只能从nginx上入手？
排除公司nginx到内部nginx的通信问题，因为no live upstream是内部nginx打印的，那么结合第一点，内部nginx的上游是服务1，也就是内部nginx跟服务之间的通信问题了，通过ping、telnet方式查看了网络、端口都是通的，之前也是正常的，应该没有哪个铁敢敢找死去动生产端口，那就排除是网络的问题了，这也就是验证了最开始小量的请求错误认为是网络问题的话是错误的。
查看内部nginx的配置发现，nginx的集群配置并没有配置keepalive，有猫腻，当访问人数达到3500时，出现大批量的请求错误，打印no live upstreams的错误日志，，而且我们系统还存在长连接的情况，所以现在大概方向可以确认（这就涉及到nginx对于http 1.0和http1.1的支持了，具体可以自己www点百度） 总的情况结合分析：网站有长连接的支持，但是nginx在负载均衡的配置上，没有配置keepalive，致使系统也无法进行高可用状态，其次后台邮件服务是每个用户登录时都会调用一次，邮件服务器那边处理不过来，后台服务也还在等待邮件请求的返回，导致连接池中连接全部使用完了，后边来的请求nginx得不到服务的响应，导致了nolive upstreams；其次当服务无法响应后，nginx会在一定的时间内认为该服务是死亡的，将不在把请求发往这个服务，导致后边的请求全部都是阻塞的。
1. 后台邮件服务改成异步的形式，避免出现等待邮件请求回来导致服务超时，连接池数量消耗完的问题2. 将冷备份的服务2也打开提供服务(注意session共享等问题)3. nginx添加keepalive 1000配置，集群添加max_fails=3 fail_timeout=10000属性，确保服务的高可用（属性具体值，依据具体情况而定）
最后，目前用户并发达到4000人时，依旧可以提供正常服务，未出现no live upstreams的错误日志信息。
