Nginx配置负载均衡和会话保持
1、准备工作
首先准备两台服务器，这里我们准备了两台虚拟机，ip 地址分别为 192.168.32.128 和 192.168.32.129，以此模拟两台服务器。
在这两台服务器上分别启动了 tomcat 服务器， 并且都在 tomcat 的 webapps 目录下新建 mySystem 目录，在该目录下新建 a.html，以此模拟在多台服务器上都部署了同一个项目。不过我们在不同服务器上的 a.html 文件的显示内容上做了一些不同修改，以便做负载均衡时能区分出来是不是请求发送到了不同服务器上（当然，实际生产时多台服务器上的资源应该是保持一致的）。
在 192.168.32.128 服务器上启动 Nginx，并在该服务器上的 Nginx 做负载均衡。
Nginx的安装可参考：https://www.cnblogs.com/wenxuehai/p/14966724.html#autoid-h2-2-3-0
在Linux上安装启动tomcat可参考：https://www.cnblogs.com/wenxuehai/p/14974657.html#_label0
2、配置负载均衡
我们需要实现的效果如下：
也就是通过 Nginx 将请求转发至两台服务器上。
打开 192.168.32.128 服务器的 Nginx 配置文件，即 /usr/local/nginx/conf/nginx.conf 文件，配置负载均衡。
修改内容如下：
配置完成后，启动两台服务器的 tomcat ，并且启动 192.168.32.128 服务器的 Nginx。我们通过浏览器访问 http://192.168.32.128/mySystem/a.html ，多次刷新可以看到效果如下：
可以看到请求被平均分发到两台服务器上，也就是这一次请求的是 192.168.32.128 上的资源，下一次请求的就是 192.168.32.129 服务器上的资源。由此，我们就实现了负载均衡。
2.1、完整的Nginx配置文件
完整的 nginx.conf 配置文件如下：
#user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; upstream myServerSetting { server 192.168.32.128:8080; server 192.168.32.129:8080; } server { listen 80; server_name 192.168.32.128; #charset koi8-r; #access_log logs/host.access.log main; location / { proxy_pass http://myServerSetting; root html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # #location ~ \.php$ { # root html; # fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # include fastcgi_params; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} } # another virtual host using mix of IP-, name-, and port-based configuration # #server { # listen 8000; # listen somename:8080; # server_name somename alias another.alias; # location / { # root html; # index index.html index.htm; # } #} # HTTPS server # #server { # listen 443 ssl; # server_name localhost; # ssl_certificate cert.pem; # ssl_certificate_key cert.key; # ssl_session_cache shared:SSL:1m; # ssl_session_timeout 5m; # ssl_ciphers HIGH:!aNULL:!MD5; # ssl_prefer_server_ciphers on; # location / { # root html; # index index.html index.htm; # } #} }
3、Nginx负载均衡策略
3.1、轮询（默认）
轮询方式是 Nginx 负载均衡默认的方式。顾名思义，所有请求都按照时间顺序分配到不同的服务上。如果某个服务器 Down 掉，可以自动将该服务器剔除，不再分发请求到该服务器上。
我们上面的配置就是使用的默认即轮询策略进行分发：
upstream myServerSetting { server 192.168.32.128:8080; server 192.168.32.129:8080; }
3.2、权重（weight）
可以用 weight 关键字来指定每个服务器的权重比例，默认权重为 1，weight和访问比率成正比，权重越高被分发到的请求越多。通常用于后端服务机器性能不统一，将性能好的分配权重高来发挥服务器最大性能。
如下配置后10002服务的访问比率会是10001服务的二倍：
upstream dalaoyang-server { server localhost:10001 weight=1; server localhost:10002 weight=2; }
3.3、ip_hash（一个客户端访问固定服务器）
每个请求都根据访问 ip 的 hash 结果分配，经过这样的处理，每个访客固定访问一个后端服务，可以解决 session 的问题。
如下配置（ip_hash 可以和 weight 配合使用）。
upstream dalaoyang-server { ip_hash; server localhost:10001 weight=1; server localhost:10002 weight=2; }
3.4、fair（服务器响应快的优先分配）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream dalaoyang-server { server localhost:10001 weight=1; server localhost:10002 weight=2; fair; }
4、Nginx 实现后端会话保持
会话保持（Session Affinity）是一种负载均衡技术，也称为会话粘滞（Session Stickiness），它确保客户端的一系列请求在整个会话期间都被发送到同一台后端服务器上。通常，HTTP 是一种无状态协议，即每个请求都是独立的，服务器不会记住前一个请求的状态，在这种情况下，如果用户的请求被发送到不同的服务器，则可能出现用户虽然登录了但是因为下次请求被发送到了另一台服务器，服务器查询不到用户登录信息导致用户需不断重新登录。为了解决这个问题，会话保持技术被引入，确保客户端在整个会话期间与同一台服务器通信。
4.1、基于ip_hash的会话保持
在做Nginx的负载均衡时，可以在upstream里设置ip_hash，每个请求按访问ip的hash结果分配，映射到固定某一台的服务器。
缺点：
- 由于同一个IP客户端都固定访问一个后端服务器，这就可能会导致负载不均衡。特别是跟固定的上游服务器交互的情况下，负载会很不均衡。
配置示例：
upstream dalaoyang-server { ip_hash; server localhost:10001 weight=1; server localhost:10002 weight=2; }
4.2、基于cookie的会话保持
Sticky是基于cookie的一种负载均衡解决方案，根据服务器给客户端的cookie，客户端再次请求时会带上此 cookie，nginx 会把有此 cookie 的请求转发到对应的服务器上。即实现同个会话内的请求（即cookie未过期前的请求）都会被发送到同一台后端服务器。
基于 cookie 的会话保持可以使用 nginx-sticky-module 模块实现（需安装使用），nginx-sticky-module是一个用于Nginx的模块，它能够在后端服务器之间保持（"sticky"）用户会话。这意味着一旦用户被定向到一台特定的后端服务器，他们的后续请求将被自动定向到同一台服务器，除非后端服务器宕机或者有其他理由导致负载均衡器需要将用户转移到另一台服务器。在 nginx-sticky-module 模块中默认此 cookie 的 key 名为route。
（Nginx sticky模块不能与ip_hash同时使用）（注意，基于 cookie 的会话保持并不是用的登录信息的 session，虽然也是存在服务器中，但不是同一个东西）
原理：
- 客户端首次发起访问请求，nginx接收后，发现请求头没有cookie，则以轮询方式将请求分发给后端服务器。
- 后端服务器处理完请求，将响应数据返回给nginx。
- 此时 nginx 生成带 route 的cookie（例如：Cookie：route=19c3afb04a79d36869450dfe7dca8512，route的值与后端服务器对应，可能是明文，也可能是md5、sha1等Hash值），返回给客户端。
- 客户端接收请求，并保存带 route 的 cookie。
- 当客户端下一次发送请求时，会带上route。nginx 根据接收到的 cookie 中的 route 值，转发给对应的后端服务器。
配置示例：
upstream backend { sticky expires=6h domain=devops.cn path=/; server 192.168.31.240:8080 weight=3 max_fails=3 fail_timeout=10s; server 192.168.31.241:8080 weight=3 max_fails=3 fail_timeout=10s; server 192.168.31.242:8080 weight=6 max_fails=3 fail_timeout=10s; server 192.168.31.243:8080; server 192.168.31.244:8080 down; }
配置说明：
- expires=1h 表示设置 Cookie 的过期时间为 1 小时，
- domain=devops.cn 表示 Cookie 在整个域名下都有效。
- path=/ 表示 Cookie 在整个网站路径下都有效。
第一次访问的时候是没有Cookie的，第一次访问完成后NGINX才会把Cookie包含在返回的数据中，在下次请求数据的时候就会出现Cookie。 所以刷新一下后才能看到Cookie。
参考：https://zhuanlan.zhihu.com/p/636707965
