前言

本文收录于我是沐风晓月的csdn专栏《linux基本功-系统服务实战》，关于nginx的系列后面会汇总起来，关注我，一起学习与成长。

本专栏写作的过程中，联合了csdn几位大佬，目前正在整理更新目录，力争让大家学到一些真东西，将所学的理论落地，帮助你更快的提升自己。

学技术最难的地方，其实是找到最优资料的过程，这次联合几位csdn的云原生方向的博主大佬，一起打造易学，易懂，落地的架构和云原生专栏。

文章目录

前言
一. 重点知识回顾
二. 负载均衡的算法
总结

一. 重点知识回顾

1.1 Nginx内核与模块划分

内核

其设计非常微小和简洁，完成的工作也非常简单。仅通过查找配置文件将客户端请求映射到一个location block（location是nginx配置中的一个指令，用例URL匹配），而在这个location中所配置的每个指令将会启动不同的模块取完成相应的工作。

从结构上划分：

核心模块：HTTP模块、EVENT模块和MAIL模块。基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP
Proxy模块和HTTP Rewrite模块。第三方模块：HTTP Upstream Request
Hash模块、Notice模块和HTTP Access Key模块。

一般我们需要记住模块名字即可，做到心里有底。

从功能上划分

Core(核心模块)：构建nginx基础服务、管理其他模块。
Handlers（处理器模块）：此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
Filters （过滤器模块）：此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
Proxies （代理类模块）：此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务
比如FastCGI等进行交互，实现服务代理和负载均衡等功能。

1.2 Nginx模块处理流程

收到HTTP请求。
Nginx基于配置文件中的位置选择一个合适的处理模块（Handlers）。
Handlers模块需要把请求反向代理到后端服务器，就需要就变成另外一类的模块：load-balancers（负载均衡模块）
负载均衡模块的配置中有一组后端服务器，当一个HTTP请求过来时，它决定哪台服务器应当获得这个请求。
处理完成后，filters（过滤模块）将被调用。每个请求都可以被压缩成块，依次经过多个filters过。它们的执行顺序在编译时决定。过滤模块链以流水线的方式高效率地向客户端发送响应信息。每个filters不会等上一个filters全部完成，就像是流水线一样。
最后把响应发给客户端。

Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。

1.3 nginx负载均衡的作用

解决服务器的高并发压力，提高应用程序的处理性能；
提供故障转移，实现高可用；
通过添加或减少服务器数量，增强网站的可扩展性；
在负载均衡器上进行过滤，可以提高系统的安全性。

二. 负载均衡的算法

2.1 关于负载均衡的理论回顾

负载均衡，就是 Nginx 把请求均匀的分摊给上游的应用服务器，这样即使某一个服务器宕机也不会影响请求的处理，或者当应用服务器扛不住了，可以随时进行扩容。
在这里插入图片描述
nginx将客户端的请求，根据相应的规则分发到部署项目的后端服务器，比如tomcat。这里的相应规则其实就是在配置文件中指定：pass_proxy指令以及upstream指令。

静态负载均衡的算法：主要包括轮询算法，基于比率的加权轮询算法或者基于优先级的加权轮询算法；
动态负载均衡的算法：主要包括基于任务量的最少连接优化算法、基于性能的最快响应优先算法、预测算法及动态性能分配算法等；

一般动态的负载均衡算法更加适用于复杂的网络环境。

负载均衡都是基于OSI七层模型来划分的：

OSI七层模型：

物理层：比特流传输
数据链路层：控制网络层与物理层之间的通信；
网络层：IP寻址和路由选择；
传输层：建立、维护、管理端到端的连接，常见的有TCP/UDP；
会话层：建立、维护、管理会话连接；
表示层：对数据进行格式化、编码、加密、压缩等操作；
应用层：为应用程序提供网络服务；

四层负载是在传输层，基于IP+port的负载均衡，常见的有：

硬件：F5、BIG-IP、Radware等；
 软件：LVS、Nginx、Hayproxy等

nginx 增加了一个stream模块，用来实现四层协议的转发，代理，负载均衡等。

stream模块的用法跟http的用法类似，允许我们配置一组TCP或者UDP等协议的监听，然后通过proxy_pass来转发我们的请求，通过upstream添加多个后端服务，实现负载均衡；

要使用stream的模式，需要在编译的时候加上 --with-stream才能用。

七层负载均衡主要在应用层，主要基于虚拟的URL或者主机的IP的负载均衡：

实现七层负载均衡的方式：
    软件：Nginx、Hayproxy等

2.2 目前nginx常用的算法

Nginx的upstream支持如下六种方式的分配算法，分别是：

算法名称	说明
轮询	默认方式
weight	权重方式
ip_hash	依据ip分配方式
least_conn	依据最少连接方式
url_hash	依据URL分配方式
fair	依据响应时间方式

1. 轮询（默认方式）

轮询是upstream模块负载均衡默认的策略，每个请求会按时间顺序逐个被分配到不同的后端服务器。轮询不需要额外的配置.

upstream mufengserver{
    
    
        server  192.168.1.41:8080;
        server  192.168.1.42:8081;
    }
server {
    
    
		listen 80;
		server_name localhost;
location / {
    
    
			# mufengserver 就是服务器组的名称
			proxy_pass http://mufengserver/;
		}
	}

2. 权重策略（weight 加权轮询）

weitht=number后面的weight参数越高，任务也就越多，权重数字越大，被分配到请求的几率越大,默认为1；
用于在服务器性能不均衡的情况下使用，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的，所有此策略比较适合服务器的硬件配置差别比较大的情况。

比如你的服务器 4C8G 和 8C16G 的服务器都有，那么这时候就可以对服务器设置一些权重，让性能好的承担更多的请求。

upstream mufengserver{
    
    
        server  192.168.1.41:9001 weight=5;
        server  192.168.1.42:9002 weight=1;
    }
server {
    
    
		listen 8080;
		server_name localhost;
		
		location / {
    
    
			# mufengserver 就是服务器组的名称
			proxy_pass http:/mufengserver/;
		}
	}

3. ip_hash

当对后端的多台动态应用服务器做负载均衡时，ip_hash指令能够将某个客户端IP的请求通过哈希算法定位到同一台后端服务器上;
当来自某一个IP的用户在后端Web服务器A上登录后，再访问该站点的其他URL，能保证其访问的还是后端web服务器A;

	# 代理服务器
	# 设置服务器组
	upstream mufengserver{
    
    
        ip_hash;
		server localhost:9001;
		server localhost:9002;
		server localhost:9003;
	}
	server {
    
    
		listen 8080;
		server_name localhost;
		
		location / {
    
    
			# backend 就是服务器组的名称
			proxy_pass http://mufengserver/;
		}
	}

注意：使用ip_hash指令无法保证后端服务器的负载均衡，可能导致有些后端服务器接收到的请求多，有些后端服务器接受的请求少，而且设置后端服务器权重等方法将不起作用.

4. fair

fair 主要根据访问的时间来分配任务，根据页面的大小，加载时间长短等智能的进行负载均衡；
要使用第三方模块fair必须安装upstream_fair模块;

upstream myserver{
    
    
        server  192.168.137.13:8082;
        server  192.168.137.13:8081;
        fair;
    }
server {
    
    
		listen 8080;
		server_name localhost;
		
		location / {
    
    
			# mufengserver 就是服务器组的名称
			proxy_pass http://mufengserver/;
}
}

5. url_hash

第三方插件,需要安装Nginx的hash软件包,按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，要配合缓存命中来使用。
有时候同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费，但使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再次收到请求，就可以从缓存中读取。

	# 代理服务器
	# 设置服务器组
	upstream mufengserver {
    
    
        hash $request_uri;
		server localhost:9001;
		server localhost:9002;
		server localhost:9003;
	}
	server {
    
    
		listen 8080;
		server_name localhost;
		
		location / {
    
    
			# mufengserver 就是服务器组的名称
			proxy_pass http://mufengserver;
		}
	}

6. least_conn

least_conn：最少连接，把请求转发给连接数较少的后端服务器。

轮询算法是把请求平均地转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。

这种方式适合请求处理时间长短不一造成服务器过载的情况。

	
	upstream mufengserver{
    
    
        least_conn;
		server localhost:9001;
		server localhost:9002;
		server localhost:9003;
	}
	server {
    
    
		listen 8080;
		server_name localhost;
		
		location / {
    
    
			# mufengserver 就是服务器组的名称
			proxy_pass http://mufengserver/;
		}
	}

总结

💕 好啦，这就是今天要分享给大家的全部内容了，我们下期再见！
💕 本文由沐风晓月原创，首发于CSDN博客，博客主页：mufeng.blog.csdn.net
💕 学习如逆水行舟，不进则退，一起努力加油哦！
💕 喜欢的话记得点赞收藏哈

智慧政务一网通办云平台顶层设计与建设方案

前言