【网站架构】Nginx负载均衡宕机怎么办？Nginx性能调优、集群、高可用方案

​

大家好，欢迎来到停止重构的频道。

本期，我们讨论Nginx的性能调优。

Nginx一般是作为网站系统的反向代理或负载均衡，但这里有一个问题，负载均衡可以绑定多个后端服务器。

一个后端服务器宕机后，另外的后端服务器仍可继续运行，那负载均衡（Nginx）本身宕机了呢？在本期的集群方案将讨论这个问题。​

我们按这样的顺序介绍 

1. 明确目标性能 

2. 硬件选择 

3. 单个Nginx服务调优 

4. 集群方案 

明确性能指标

在调优之前需要先明确性能指标， 根据往期《性能指标》 整体系统的性能指标是并发量、吞吐量、错误率、响应时间。

在调试单个服务时，根据往期《调优基本思路》的结论，只需要明确吞吐量即可，如果整个系统的吞吐量指标为1000rps，则Nginx作为负载均衡的话，理论上吞吐量为1000rps即可。

不过，Nginx作为负载均衡的话是整个网站系统的总入口，而且Nginx的最终吞吐量与业务功能、请求返回的数据量是强关联，所以单独测试Nginx性能也没有实际意义。

一般判断Nginx性能是否足够是在整体系统性能测试时，观察Nginx服务器与其他服务器的负载情况，负载情况分析可参考往期《负载分析》。

例如，如果在整体性能测试时，Nginx的负载是满的（如CPU、内存、带宽使用率等），但其他服务的负载是未满的，则说明Nginx服务存在性能瓶颈，这时可以考虑增加增加硬件配置。

如果网站系统是公网公开的话，负载均衡最好选择公有云的负载均衡，因为它们会提供完整的边缘网络方案，也就是说不会拥堵在一个Nginx服务上。

硬件选择

Nginx的硬件选择一般是选择CPU和内存，cpu和内存的配比一般为1:2，当然，内存大小的选择更依赖文件缓存的预期大小，如果没有文件缓存的需要，内存大小可以低一些。

Nginx的硬件配置不需要太高，一般4核CPU的服务即可达到几万RPS。​

Nginx服务器的带宽也是需要重点观察的，因为Nginx作为负载均衡的话一般是作为整个网站系统的总入口，所以网络带宽的消耗是很大的。

如果有上传下载文件功能的话，最好把上传下载文件用单独的负载均衡处理，这样就不会因为文件传输影响主体功能。​

​

另外，Nginx除了作为负载均衡、反向代理，还有很多其他功能，如作为代理服务器做网络跳板、rtmp视频流服务器等。

如果有这些功能需要，最好部署单独的Nginx服务，出现性能问题时，能更好地对症下药。

单个Nginx服务调优 ​

接下来是对单个Nginx服务调优，在这之前，需要先调优服务器内核参数，调优方法可以参考往期《内核参数调优》。

单个Nginx服务调优可参考图中所示，另外，Nginx作为前端服务器软件的话，还可以缓存文件以减少磁盘读写，但是如果配置了CDN加速的话，其实缓存文件的意义也不大。​

集群方案​

严格意义上讲，Nginx是没有集群方案的，但是由于Nginx是无状态，所以可以使用keepalived作为集群方案。

每个服务器都安装keepalived和nginx后，这些服务器会抢占同一个虚IP，当一台服务器宕机，别的服务器会重新占用虚IP并继续接收请求。

虚ip其实就是还没与某个服务器绑定的IP。

这也是解决开篇问题的方案，这也是比较常用的Nginx的高可用方案，但是这个方案也会在一定程度上降低Nginx服务器的性能。

总结

截止本期，我们介绍完了MySQL、Redis、Nginx、Tomcat这些常用软件的性能优化和集群方案。

其实调优思路都是基本雷同的，只要掌握了基本思路，其他软件服务的调优也都是差不多的。

后面几期，我们将介绍一些提高性能的编程方案。