分布式 - 服务器Nginx：一小时入门系列之负载均衡

文章目录

- [1. 负载均衡](#1. 负载均衡)
- [2. 负载均衡策略](#2. 负载均衡策略)
- - [1. 轮询策略](#1. 轮询策略)
  - [2. 最小连接策略](#2. 最小连接策略)
  - [3. IP 哈希策略](#3. IP 哈希策略)
  - [4. 哈希策略](#4. 哈希策略)
  - [5. 加权轮询策略](#5. 加权轮询策略)

1. 负载均衡

跨多个应用程序实例的负载平衡是一种常用技术，用于优化资源利用率、最大化吞吐量、减少延迟和确保容错配置。‎使用 nginx 作为非常有效的HTTP负载平衡器，将流量分配到多个应用程序服务器，可以提升Web应用程序的性能，提高扩展性和可靠性。

使用 upstream定义一组服务。

shell 复制代码

# 启动ruoyi-admin服务
[root@nginx-dev conf.d]# cd /home/apps
[root@nginx-dev apps]# java -jar ruoyi-admin.jar

# 启动tomcat服务
[root@nginx-dev ~]# /home/apache-tomcat-8.5.81/bin/startup.sh

# 在 /etc/nginx/conf.d文件夹下添加nginx配置文件：8003.conf
[root@nginx-dev ~]# cd /etc/nginx/conf.d
[root@nginx-dev conf.d]# vi 8003.conf   
[root@nginx-dev conf.d]# nginx -s reload

8003.conf 配置文件内容：

nginx 复制代码

upstream ruoyi-apps {
    #不写，采用轮循机制
    server localhost:8080;
    server localhost:8088;
}

server {
    listen 8003;
    server_name ruoyi.loadbalance;

    location / {
        proxy_pass http://ruoyi-apps;
    }
    
    # 请求ie页面
    location = /html/ie.html {
        root  /some/path/static;
    }

    # 请求字体文件
    location ^~ /fonts/ {
        root  /some/path/static;
    }

    # css|js|png|jpg|gif|ico 页面
    location ~ \.(css|js|png|jpg|gif|ico) {
        root /some/path/static;
    }  
}

2. 负载均衡策略

1. 轮询策略

nginx 复制代码

upstream ruoyi-apps {
    #不写，采用轮循机制
    server localhost:8080;
    server localhost:8088;
}

轮询策略（Round Robin）：默认的负载均衡策略，将请求依次分配给每个后端服务器，循环往复。

例如，当请求 nginx 的 8003 端口时，会将请求轮询转发给 tomcat 和 ruoyi-admin 两个后端服务器，即第1次请求会访问8080端口，第2次请求会访问8088端口，循环往复。

当访问 nginx 的 8003 端口时，请求会进入 8088 端口的 ruoyi-admin 服务，当填写完密码以后点击登录，这次请求会进入 8080 端口的 tomcat 服务，因此总是登录不成功。

2. 最小连接策略

最少连接策略（Least Connections）：将请求分配给当前连接数最少的后端服务器，以达到负载均衡的目的。

nginx 复制代码

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

请注意，使用轮循机制或最少连接的负载平衡，每个客户端的请求都可能分发到不同的服务器。不能保证同一客户端将始终定向到同一服务器。‎

3. IP 哈希策略

IP 哈希策略（IP Hash）：根据客户端 IP 地址的哈希值来选择后端服务器，同一个客户端的请求总是被分配到同一个后端服务器上。

nginx 复制代码

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

此方法可确保来自同一客户端的请求将始终定向到同一服务器，除非此服务器不可用。

4. 哈希策略

通用hash，允许用户自定义hash的key，key可以是字符串、变量或组合。例如，key可以是配对的源 IP 地址和端口，也可以是 URI，如以下示例所示：‎

nginx 复制代码

upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

请注意：基于 IP 的哈希算法存在一个问题，那就是当有一个上游服务器宕机或者扩容的时候，会引发大量的路由变更，进而引发连锁反应，导致大量缓存失效等问题。

假设我们基于 key 来做 hash，现在有 4 台上游服务器，如果 hash 算法对 key 取模，请求根据用户定义的哈希键值均匀分布在所有上游服务器之间。当有一台服务器宕机的时候，就需要重新对 key 进行 hash，最后会发现所有的对应关系全都失效了，从而会引发缓存大范围失效。

consistent参数启用 ‎‎ketama‎‎ 一致哈希算法，如果在上游组中添加或删除服务器，只会重新映射部分键，从而最大限度地减少缓存失效。‎

5. 加权轮询策略

加权轮询策略（Weighted Round Robin）：根据后端服务器的权重来分配请求，权重越高的服务器被分配到的请求越多。

nginx 复制代码

upstream my-server {
    server performance.server weight=3;
    server app1.server;
    server app2.server;
}

如上所示，每 5 个新请求将按如下方式分布在应用程序实例中：3 个请求将定向到 performance.server，一个请求将转到 app1.server，另一个请求将转到 app2.server。‎