Nginx 负载均衡配置及会话保持
Nginx 负载均衡配置及会话保持
还是一样，欢迎看腾讯文档
【腾讯文档】Nginx 负载均衡配置及会话保持
https://docs.qq.com/doc/DT3lQRnNEU0tiaGFr
Nginx介绍
略，以后写，或者自己查一下
Nginx优点
Nginx 是一个很强大的高性能Web和反向代理服务，它具有很多非常优越的特性：
在连接高并发的情况下，Nginx是Apache服务不错的替代品：Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一。能够支持高达 50,000 个并发连接数的响应，感谢Nginx为大家选择了 epoll and kqueue作为开发模型。
负载均衡
例如： 轮询、最少连接数、IP地址哈希、源地址哈希、基于权重的负载均衡等等
Nginx配置项之一
upstream 模块
upstream 这个模块是写一组被代理的服务器地址（即定义的后端服务器列表中选取一台服务器接受用户的请求 ），然后配置负载均衡的算法。 来看一下最基本的负载均衡实例：
upstream web_test {
server 10.10.2.100:80;
server 10.10.3.100:80;
}
server {
....
location / {
proxy_pass http://web_test; --请求转向 web_test 定义的服务器列表
}
Nginx负载均衡策略
（1）轮询
最基本的配置方法，上面的例子就是轮询的方式，它是upstream模块默认的负载均衡默认策略。每个请求会按时间顺序逐一分配到不同的后端服务器。
● 平时就是用这个配置，其他的配置没有深入，借此机会了解了一下。
upstream web_test {
server 10.10.2.100:80; weight=1;
server 10.10.3.100:80; weight=2;
}
（2）ip_hash
每个请求按访问IP的hash结果分配，同一个IP客户端固定访问一个后端服务器。可以保证来自同一ip的请求被打到固定的机器上，可以解决session问题。
upstream web_test {
ip_hash; --同一个IP客户端固定访问一个后端服务器
server 10.10.2.100:80; weight=1;
server 10.10.3.100:80; weight=2;
}
（3）url_hash
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器。一旦缓存住了资源，再次收到请求，就可以从缓存中读取。
upstream web_test {
hash $request_uri; --实现每个url定向到同一个后端服务器
server 10.10.2.100:80; weight=1;
server 10.10.3.100:80; weight=2;
}
（4）least_conn
把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。
upstream web_test {
least_conn; --把请求转发给连接数较少的后端服务器
server 10.10.2.100:80; weight=1;
server 10.10.3.100:80; weight=2;
}
（5）weight
权重方式，在轮询策略的基础上指定轮询的比例。
一般来说，性能好的服务器权重大，性能差的权重给小一些。
upstream web_test {
server 10.10.2.100:80; weight=1;
server 10.10.3.100:80; weight=2; --轮询的比例相对上一条要大
}
（6）fair
此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream web_test {
server 10.10.2.100:80; weight=1;
server 10.10.3.100:80; weight=2;
fair; --实现响应时间短的优先分配
}
Nginx负载均衡配置状态参数
● down：表示当前的server暂时不参与负载均衡。
● backup：预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻。
● max_fails：允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。
● fail_timeout：在经历了max_fails次失败后，暂停服务的时间单位秒。max_fails可以和fail_timeout一起使用。
这里到了文章主题，为什么要谈谈会话保持，也是之前的知识盲区， 在最近的一次技术面试被问到了。 咳咳。
什么是会话保持
我们在访问网站的时候，进行登录以后，服务器上会生成一个session，然后服务器会携带着session_id返回给浏览器记录一个cookie值，当第二次访问时，cookie会来服务器上与session进行对比，如果对比成功，则不需要重新登录
会话保持有什么作用呢
简单说就是优化用户体验，降低网络开销
如果有一个用户访问请求被分配到服务器A，并且在服务器A登录了，并且在很短的时间，这个用户又发出了一个请求，如果没有会话保持功能的话，这个用户的请求很有可能会被分配到服务器B去，这个时候在服务器B上是没有登录的，所以你要重新登录，但是用户并不知道自己的请求被分配到了哪里，用户的感觉就是登录了，怎么又要登录，用户体验很不好。
还有你在淘宝上面买东西，从登录＝》拍得东西＝》添加地址＝》付款，这是一个一系列的过程，也可以理解成一次操作过程，所有这一系列的操作过程都应当由一台服务器完成，而不能被负载均衡器分配到不同的服务器上。
会话保持都会有时间的限制（映射到固定某一台的服务器除外，如：ip_hash）,各种负载均衡工具都会提供这种会话保持时间的设置，LVS，apache等。连php语言都提供了会话保持时间的设定session.gc_maxlifetime会话保持时间的设定要大于session生存时间的设定，这样可以减少需要同步session的情况，但是不能杜绝。所以同步session还是要做的。
Nginx 会话保持
nginx会话保持主要有以下几种实现方式。
1）ip_hash
ip_hash使用源地址哈希算法，将同一客户端的请求总是发往同一个后端服务器，除非该服务器不可用。
ip_hash语法：
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}
ip_hash简单易用，但有如下问题：
当后端服务器宕机后，session会丢失；
来自同一局域网的客户端会被转发到同一个后端服务器，可能导致负载失衡；
不适用于CDN网络，不适用于前端还有代理的情况。
2) sticky_cookie_insert
使用sticky_cookie_insert启用会话亲缘关系，这会导致来自同一客户端的请求被传递到一组服务器在同一台服务器。与ip_hash不同之处在于，它不是基于IP来判断客户端的，而是基于cookie来判断。因此可以避免上述ip_hash中来自同一局域网的客户端和前端代理导致负载失衡的情况。
语法：
upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky_cookie_insert srv_id expires=1h domain=3evip.cn path=/;
}
说明：
expires：设置浏览器中保持cookie的时间
domain：定义cookie的域
path：为cookie定义路径
3) 使用后端服务器自身通过相关机制保持session同步
如：使用数据库、redis、memcached等做session复制
周末去 看看田园风光，放松一下
其他资料：
什么是session？
https://blog.csdn.net/pingfan592/article/details/88388045?ops_request_misc=&request_id=&biz_id=102&utm_term=session&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-0-88388045.nonecase&spm=1018.2226.3001.4187
