利用nginx实现负载均衡 | 哈希算法，sticky模块实现session粘滞
一，普通的负载均衡
1，启动nginx服务器
之前已经把/usr/local/nginx/sbin/nginx链接到/sbin下，所以直接使用nginx命令打开
2，修改主配置文件/usr/local/nginx/conf/nginx.conf
user nginx nginx; #原来的nobody设置为nginx和nginx组
# 需要创建用户
[root@server4 conf]# useradd -M -d /usr/local/nginx/ nginx
[root@server4 conf]# id nginx
uid=500(nginx) gid=500(nginx) groups=500(nginx)
# -M, --no-create-home do not create the user's home directory
# -d, --home-dir HOME_DIR home directory of the new account
events {
worker_connections 65535; #这里原来的1024太小了
}
http语句块添加:
upstream westos{ #代理这个label和下面的要一样
server 172.25.28.2:80;
server 172.25.28.3:80;
}
http最后面仿照例子添加:
server {
listen 80;
server_name www.westos.org #这里指定了只能访问www.westos.org，访问ip都是不对的，所以客户端访问必须要本地解析/etc/hosts
172.25.28.4 www.westos.org
location / {
proxy_pass http://westos; #代理是westos
}
}
内核限制>操作系统>程序
内核
[root@server4 conf]# sysctl -a | grep file
fs.file-nr = 480 0 98861
fs.file-max = 98861
3,操作系统文件限制配置
/etc/security/limits.conf
# End of file
nginx - nofile 65536 #比程序限制65535大，比内核限制98861小
4,nginx -t 检查语法错误
nginx -s reload 重新加载
5，访问测试
注意一定要先解析，访问域名，如果访问ip，那么就没有负载均衡的作用了，直接把nginx当作web服务器使用
6，负载均衡测试
停掉一个RS，不影响访问
停掉两个RS，报502错误，这个页面是nginx默认发布目录下的50x.html
[root@server4 html]# pwd
/usr/local/nginx/html
[root@server4 html]# ls
50x.html index.html
（官方文档https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
有很多不同种类的负载均衡实现方法）
二，哈希算法
修改配置文件
http {
upstream westos{
ip_hash; #加入哈希函数
server 172.25.28.2:80;
server 172.25.28.3:80;
}
ip_hash是针对客户端的，对于同一个客户端ip，nginx给它分配的RS是一定的，除非改RS异常停止，而对于不同的客户端ip，nginx给它分配的RS不同，
三，改变权重
（为了实验效果，注释ip_hash）
http {
upstream westos{
#ip_hash;
server 172.25.28.2:80 weight=2;
server 172.25.28.3:80;
}
后端服务器RS中vm2出现的次数是vm3的两倍
四，nginx自身充当web服务器
http {
upstream westos{
#ip_hash;
server 172.25.28.2:80;
server 172.25.28.3:80;
server 127.0.0.1:80 backup; #备用
}
只有当后端服务器vm2和vm3都停止时，本机才会重当web服务器
五， sticky模块实现session粘滞
在使用负载均衡的时候会遇到会话保持的问题，常用的方法有：
1.ip hash，根据客户端的IP，将请求分配到不同的服务器上；
2.cookie，服务器给客户端下发一个cookie，具有特定cookie的请求会分配给它的发布者，
注意：cookie需要浏览器支持，且有时候会泄露数据
Sticky工作原理 ：
Sticky是nginx的一个模块，它是基于cookie的一种nginx的负载均衡解决方案，通过分发和识别cookie，来使同一个客户端的请求落在同一台服务器上，默认标识名为route
1.客户端首次发起访问请求，nginx接收后，发现请求头没有cookie，则以轮询方式将请求分发给后端服务器。
2.后端服务器处理完请求，将响应数据返回给nginx。
3.此时nginx生成带route的cookie，返回给客户端。route的值与后端服务器对应，可能是明文，也可能是md5、sha1等Hash值
4.客户端接收请求，并保存带route的cookie。
5.当客户端下一次发送请求时，会带上route，nginx根据接收到的cookie中的route值，转发给对应的后端服务器。
实现过程
nginx-1.10.1.tar.gz
nginx-sticky-module-ng.tar.gz
1，这里需要停止原来的nginx-1.14.0，当前nginx-sticky-module-ng.tar.gz不支持14版
nginx -s stop
2，配置1.10.1版本的nginx
编译
./configure --prefix=/opt/nginx --with-http_ssl_module --with-http_stub_status_module --with-threads --with-file-aio --add-module=/root/nginx-sticky-module-ng
##添加粘滞模块
##不要把之前的覆盖了，修改安装路径
##这种编译是静态编译，对于这个软件，需要什么模块了得把之前的模块再写一次，然后把需要的模块写在后面，而动态编译是只编译此次需要的，编译完成后之前的模块还在
make
make install
添加配置文件
把原来的配置文件复制过来
[root@server4 conf]# pwd
/opt/nginx/conf
[root@server4 conf]# cp /usr/local/nginx/conf/nginx.conf .
cp: overwrite `./nginx.conf'? y
注意：
[root@server4 conf]# which nginx
/sbin/nginx
[root@server4 conf]# ll /sbin/nginx
lrwxrwxrwx 1 root root 27 Aug 1 11:55 /sbin/nginx -> /usr/local/nginx/sbin/nginx
我们之前把nginx做了链接，但是那是1.14.0版本，现在这个不能在直接使用nginx命令，其实也可以做一个软链接，这里我们使用绝对路径
检查语法
[root@server4 conf]# /opt/nginx/sbin/nginx -t
nginx: the configuration file /opt/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /opt/nginx/conf/nginx.conf test is successful
修改配置文件
http {
upstream westos{
#ip_hash;
sticky; #粘滞算法
server 172.25.28.2:80;
server 172.25.28.3:80;
#server 127.0.0.1:80 backup;
}
3，访问测试
这是针对浏览器的cookie,curl不是浏览器，所以不能使用curl，必须要在浏览器里面查看
F12打开关闭cookie
#什么是Sticky？# 为了理解Sticky的工作原理，我们可以先考虑一个问题：负载均衡怎么做？
DNS解析，在域名解析时分配给不同的服务器IP；
IP Hash，根据客户端的IP，将请求分配到不同的服务器上；
cookie，服务器给客户端下发一个cookie，具有特定cookie的请求会分配给它的发行者。
Sticky就是基于cookie的一种负载均衡解决方案，通过cookie实现客户端与后端服务器的会话保持, 在一定条件下可以保证同一个客户端访问的都是同一个后端服务器。请求来了，服务器发个cookie，并说：下次来带上，直接来找我。
Sticky是nginx的一个模块，它是基于cookie的一种nginx的负载均衡解决方案，通过分发和识别cookie，来使同一个客户端的请求落在同一台服务器上，默认标识名为route
1.客户端首次发起访问请求，nginx接收后，发现请求头没有cookie，则以轮询方式将请求分发给后端服务器。
2.后端服务器处理完请求，将响应数据返回给nginx。
3.此时nginx生成带route的cookie，返回给客户端。route的值与后端服务器对应，可能是明文，也可能是md5、sha1等Hash值
4.客户端接收请求，并保存带route的cookie。
5.当客户端下一次发送请求时，会带上route，nginx根据接收到的cookie中的route值，转发给对应的后端服务器。