前言
本文收录于我是沐风晓月的csdn专栏《linux基本功-系统服务实战》， 关于nginx的系列后面会汇总起来，关注我，一起学习与成长。
本专栏写作的过程中，联合了csdn几位大佬，目前正在整理更新目录，力争让大家学到一些真东西，将所学的理论落地，帮助你更快的提升自己。
学技术最难的地方，其实是找到最优资料的过程，这次联合几位csdn的云原生方向的博主大佬，一起打造易学，易懂，落地的架构和云原生专栏。
文章目录
- 前言
- 一. 重点知识回顾
- 1.1 Nginx内核与模块划分
- 1.2 Nginx模块处理流程
- 1.3 nginx负载均衡的作用
- 二. 负载均衡的算法
- 2.1 关于负载均衡的理论回顾
- 2.2 目前nginx常用的算法
- 1. 轮询（默认方式）
- 2. 权重策略（weight 加权轮询）
- 3. ip_hash
- 4. fair
- 5. url_hash
- 6. least_conn
- 总结
一. 重点知识回顾
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
💕 学习如逆水行舟，不进则退，一起努力加油哦！
💕 喜欢的话记得点赞收藏哈
