版权声明：创作不易，转载请注明出处 https://blog.csdn.net/ha_weii/article/details/81350087

一，普通的负载均衡

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值，转发给对应的后端服务器。