上回我们简单的说明了一下nginx的代理配置及基本概念，相信小伙伴们对nginx已经有一定的了解了，这次小编就来介绍介绍nginx的负载均衡原理，快一起来了解一下吧。
Nginx负载均衡原理详解
一、会话一致性
在Nginx中，它的会话一致性是由sticky来启动的，会话一致性与负载均衡算法之间并没有冲突，但是，在第一次分配之后，这个会话的全部请求都会分配到那个相同的backend上面。目前来说，nginx支持三种会话一致性：
1)、Cookie Insertion
backend在第一次response之后，会在它的头部插入一个session cookie，然后下面的客户端请求都会带有这个cookie值，这样Nginx就可以根据cookie判断需要转发给哪个backend。
sticky cookie srv_id expires=1h domain=.example.com path=/;
srv_id代表cookie的name
2)、Sticky Routes
这个模式会在backend第一次response之后，产生一个route信息，route信息一般会从cookie/URI信息中提取。
sticky route $route_cookie $route_uri;
这样Nginx就能够按照次序搜索$route_cookie、$route_uri参数并选择第一个非空的参数用作route，但如若所有参数都为null的话，就会使用默认的负载均衡算法来决定请求分发给哪个backend。
3)、Learn
这个模式下，Nginx会自动监测request与response中的session信息，并且一般需要回话一致性的请求、应答中都会带有session信息，与第一种模式比较下优点就是不用增加cookie，只用动态学习已有session就行了。
这种模式会需要使用到zone结构，在Nginx中zone都是共享内存，能够在多个worker process中共享数据用的。
sticky learn create=$upstream_cookie_examplecookie lookup=$cookie_examplecookie zone=client_sessions:1m timeout=1h;
二、Session Draining
一般是有需要关闭某些backend以便维护或者升级，这些关键性的服务都会请求gracefully处理的：但新的请求不会发送到这个backend上面，而之前分配到这个backend的会话的后续请求还会继续发送给它，直到这个会话最终完成。
会让某个backend进入draining的状态，既可以直接修改配置文件，之后按照之前的方式通过向master process发送信号重新加载配置，也能够采用Nginx的on-the-fly配置方式。
$ curl http://localhost/upstream_conf?upstream=backend $ curl http://localhost/upstream_conf?upstream=backend&id=1&drain=1
通过以上方法，先列出各个bacnkend的ID号，然后drain指定ID的backend。再通过在线观测backend的所有session都完成后，这个backend就可以下线了。
三、 backend健康监测
backend出错会涉及到两个参数，max_fails=1 fail_timeout=10s;意味着只要Nginx向backend发送一个请求失败或者没有收到一个响应，就认为该backend在接下来的10s是不可用的状态。
通过周期性地向backend发送特殊的请求，并期盼收到特殊的响应，可以用以确认backend是健康可用的状态。通过health_check可以做出这个配置。
match server_ok {
status 200-399;
header Content-Type = text/html;
body !~ "maintenance mode";
}
server {
location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2 match=server_ok;
}
}上面的health_check是必须的，后面的参数都是可选的。尤其是后面的match参数，可以自定义服务器健康的条件，包括返回状态码、头部信息、返回body等，这些条件是&&与关系。默认情况下Nginx会相隔interval的间隔向backend group发送一个”/“的请求，如果超时或者返回非2xx/3xx的响应码，则认为对应的backend是unhealthy的，那么Nginx会停止向其发送request直到下次改backend再次通过检查。
使用check功能时，通常都需要在backend group中独立开辟一个zone，在共享backend group配置的时，所有backend的状态就可以在所有的worker process中共享了，不然的话，每个worker process就都会独立保存自己的状态检查计数和结果。
四、 通过DNS设置HTTP负载均衡
Nginx的backend group中的主机可以配置成域名的形式，如果在域名的后面添加resolve参数，那么Nginx会周期性的解析这个域名，当域名解析的结果发生变化的时候会自动生效而不用重启。
http {
resolver 10.0.0.1 valid=300s ipv6=off;
resolver_timeout 10s;
server {
location / {
proxy_pass http://backend;
}
}
upstream backend {
zone backend 32k;
least_conn;
...
server backend1.example.com resolve;
server backend2.example.com resolve;
}
}如若域名解析的结果包含多个IP，那么这些IP地址都会保存到配置文件中去，且这些IP都会参与到自动负载均衡。
五、TCP/UDP流量的负载均衡
除了专长的HTTP负载均衡，Nginx还支持TCP和UDP流量的负载均衡，适用于LDAP/MySQL/RTMP和DNS/syslog/RADIUS各种应用场景。这类情况的负载均衡使用stream来配置，Nginx编译的时候需要支持–with-stream选项。查看 手册 ，其配置原理和参数和HTTP负载均衡差不多。
因为TCP、UDP的负载均衡都是针对通用程序的，所以之前HTTP协议支持的match条件(status、header、body)是没法使用的。TCP和UDP的程序可以根据特定的程序，采用send、expect的方式来进行动态健康检测。
match http {
send "GET / HTTP/1.0
Host: localhost
";
expect ~* "200 OK";
}以上就是关于nginx负载均衡原理的所有内容了，如果想了解nginx相关问题，就请持续关注我们网站吧。
推荐阅读：