Nginx服务器所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
以下是Nginx作为七层负载均衡常用的几种调度算法和适用的业务场景
1、轮询（默认调度算法）
特点：每个请求按时间顺序逐一分配到不同的后端服务器处理。
适用业务场景：后端服务器硬件性能配置完全一致，业务无特殊要求时使用。
upstream backendserver {
server 192.168.0.14：80 max_fails=2 fail_timeout=10s;
server 192.168.0.15：80 max_fails=2 fail_timeout=10s;
}
2、加权轮询
特点：指定轮询几率，weight值(权重)和访问比例成正比，用户请求按权重比例分配。
适用业务场景：用于后端服务器硬件性处理能力不平均的情形。
upstream backendserver {
server 192.168.0.14:80 weight=5 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 weight=10 max_fails=2 fail_timeout=10s;
}
3、ip_hash
特点：每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session会话保持问题。
适用业务场景：适用于需要账号登录的系统，会话连接保持的业务。
upstream backendserver {
ip_hash;
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}
4、最少连接数 least_conn
特点：按nginx反向代理与后端服务器之间的连接数，连接数最少的优先分配。
适用业务场景：适用于客户端与后端服务器需要保持长连接的业务。
upstream backendserver {
least_conn;
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}
5、fair（需编译安装第三方模块 ngx_http_upstream_fair_module）
特点：按后端服务器的响应时间来分配请求，响应时间短的优先分配。
适用业务场景：对访问响应速度有一定要求的业务。
upstream backendserver {
fair;
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}
6、url_hash（需编译安装第三方模块 ngx_http_upstream_hash_module）
特点：按访问url的hash结果来分配请求，使同一个url访问到同一个后端服务器。
适用业务场景：适用于后端服务器为缓存服务器时比较有效。
upstream backendserver {
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
hash $request_uri;
}
不管负载均衡方案是采用花费较少的软件方式，还是购买代价高昂在性能功能上更强的第四层交换机、负载均衡器等硬件方式来实现，亦或其他种类不同的均衡技术，下面这几项都是我们在引入均衡方案时可能要考虑的问题：
性能：性能是我们在引入均衡方案时需要重点考虑的问题，但也是一个最难把握的问题。衡量性能时可将每秒钟通过网络的数据包数目做为一个参数，另一个参数是均衡方案中服务器群所能处理的最大并发连接数目，但是，假设一个均衡系统能处理百万计的并发连接数，可是却只能以每秒2个包的速率转发，这显然是没有任何作用的。性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关，并且有两点需要注意：一、均衡方案对服务器群整体的性能，这是响应客户端连接请求速度的关键；二、负载均衡设备自身的性能，避免有大量连接请求时自身性能不足而成为服务瓶颈。有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能，如DNS负载均衡与NAT负载均衡相结合。另外，针对有大量静态文档请求的站点，也可以考虑采用高速缓存技术，相对来说更节省费用，更能提高响应性能；对有大量ssl/xml内容传输的站点，更应考虑采用ssl/xml加速技术。
可扩展性：IT技术日新月异，一年以前最新的产品，现在或许已是网络中性能最低的产品；业务量的急速上升，一年前的网络，现在需要新一轮的扩展。合适的均衡解决方案应能满足这些需求，能均衡不同操作系统和硬件平台之间的负载，能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不同服务器的负载，并且能以对客户端完全透明的方式动态增加或删除某些资源。
灵活性：均衡解决方案应能灵活地提供不同的应用需求，满足应用需求的不断变化。在不同的服务器群有不同的应用需求时，应有多样的均衡策略提供更广泛的选择。
可靠性：在对服务质量要求较高的站点，负载均衡解决方案应能为服务器群提供完全的容错性和高可用性。但在负载均衡设备自身出现故障时，应该有良好的冗余解决方案，提高可靠性。使用冗余时，处于同一个冗余单元的多个负载均衡设备必须具有有效的方式以便互相进行监控，保护系统尽可能地避免遭受到重大故障的损失。