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

文章目录

    • 1. 负载均衡
    • 2. 负载均衡策略
      • 1. 轮询策略
      • 2. 最小连接策略
      • 3. IP 哈希策略
      • 4. 哈希策略
      • 5. 加权轮询策略

1. 负载均衡

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

分布式 - 服务器Nginx:一小时入门系列之负载均衡_第1张图片

使用 upstream定义一组服务 。

# 启动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 配置文件内容:

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. 轮询策略

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 服务,因此总是登录不成功。

分布式 - 服务器Nginx:一小时入门系列之负载均衡_第2张图片

2. 最小连接策略

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

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

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

3. IP 哈希策略

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

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

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

4. 哈希策略

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

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

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

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

分布式 - 服务器Nginx:一小时入门系列之负载均衡_第3张图片

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

分布式 - 服务器Nginx:一小时入门系列之负载均衡_第4张图片

5. 加权轮询策略

加权轮询策略(Weighted Round Robin):根据后端服务器的权重来分配请求,权重越高的服务器被分配到的请求越多。

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

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

你可能感兴趣的:(【分布式-服务器Nginx】,分布式,服务器,nginx)