Nginx系列-负载均衡

文章目录

  • Nginx系列-负载均衡
    • [1. 负载均衡基础](#1. 负载均衡基础)
      • [1.1 负载均衡定义](#1.1 负载均衡定义)
      • [1.2 Nginx负载均衡原理](#1.2 Nginx负载均衡原理)
    • [2. 负载均衡策略](#2. 负载均衡策略)
      • [2.1 轮询(Round Robin)](#2.1 轮询(Round Robin))
      • [2.2 加权轮询(Weighted Round Robin)](#2.2 加权轮询(Weighted Round Robin))
      • [2.3 IP哈希(IP Hash)](#2.3 IP哈希(IP Hash))
      • [2.4 最少连接(Least Connections)](#2.4 最少连接(Least Connections))
      • [2.5 加权最少连接(Weighted Least Connections)](#2.5 加权最少连接(Weighted Least Connections))
    • [3. 负载均衡策略验证](#3. 负载均衡策略验证)

Nginx系列-负载均衡

1. 负载均衡基础

1.1 负载均衡定义

负载均衡是指将网络请求分散到多个服务器或网络节点上,以实现资源的优化使用和提高系统的响应速度。它不仅可以缓解单台服务器的压力,还可以提高系统的整体可用性和容错能力。

1.2 Nginx负载均衡原理

Nginx通过其内置的upstream模块来实现负载均衡。该模块允许你定义一组后端服务器,并根据一定的策略将客户端请求转发到这些服务器上。Nginx支持多种负载均衡策略,包括轮询、IP哈希、最少连接数等。

2. 负载均衡策略

Nginx支持多种负载均衡策略,以下是几种常用的策略:

2.1 轮询(Round Robin)

轮询是Nginx默认的负载均衡策略。它按照定义的服务器列表顺序逐个分配请求,循环往复。适用于服务器性能相当的情况。

复制代码
upstream myUpstream {
    server backend1.example.com;
    server backend2.example.com;
}

server {
    location / {
        proxy_pass http://myUpstream;
    }
}

2.2 加权轮询(Weighted Round Robin)

根据服务器的权重值分配请求,权重越高的服务器将获得更多的请求。通过给不同服务器设置不同的权重,可以合理分配负载,更好地利用服务器资源。

复制代码
upstream myUpstream {
    server backend1.example.com weight=3;
    server backend2.example.com weight=1;
}

server {
    location / {
        proxy_pass http://myUpstream;
    }
}

2.3 IP哈希(IP Hash)

根据客户端的IP地址进行哈希计算,将相同IP的请求始终分发到同一台后端服务器上。这样可以保证来自同一客户端的请求都会被发送到同一服务器,适用于需要会话保持或缓存一致性的应用场景。

复制代码
upstream myUpstream {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

server {
    location / {
        proxy_pass http://myUpstream;
    }
}

2.4 最少连接(Least Connections)

该策略将请求发送给当前连接数最少的服务器。通过动态地追踪每个服务器的连接数,将请求分发给连接最少的服务器,以实现负载均衡。适用于处理连接时长不一致的场景,如长连接和短连接混合的情况。

复制代码
upstream myUpstream {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

server {
    location / {
        proxy_pass http://myUpstream;
    }
}

2.5 加权最少连接(Weighted Least Connections)

为每台服务器分配权重,并按照最少连接数进行负载均衡

复制代码
upstream myUpstream {
    least_conn;
    server backend1.example.com weight=3;
    server backend2.example.com weight=1;
}

server {
    location / {
        proxy_pass http://myUpstream;
    }
}

3. 负载均衡策略验证

配置如下:

复制代码
#user  nobody;
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream my_upstream {
        least_conn;
        server 192.168.10.116:8084;
        server 192.168.10.116:8085;
    }
    server {
        listen       80;
        server_name  localhost;
        location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
            try_files $uri $uri/ /index.html;
            error_page 404 index.html;
        }
        #接口路径匹配
        location /api {
            proxy_pass http://my_upstream;
        }
	
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

配置好之后启动nginx,结果呕吼。。。

开始排查之路:

  1. 明确400错误是什么

HTTP 400 错误,也被称为"Bad Request"错误,是一个HTTP协议标准的响应状态码。它表示服务器无法理解或不能处理客户端发送的请求。这通常意味着请求的格式有误,或者请求中包含了服务器无法理解的参数。

  1. 查看nginx的日志,也没有看出什么问题,试着百度一下: nginx upstream 400,效果还不错,一共有两种解决方案,一种是设置请求头,一种是upstream的名称不要包含下划线,挨个验证呗

解决方案验证:

  1. upstream的名称不要包含下划线,修改upstream的名称

    myUpstream

重启nginx,结果成功解决

  1. 设置请求头

    proxy_set_header Host $host;

重启nginx,结果成功解决

  1. 原因总结

Nginx 的 upstream 名称带有下划线时出现 400 错误,主要原因与 HTTP 协议的规范有关。
在 HTTP 协议中,规范建议域名和其他标识符应该遵循某些规则。具体到 Nginx 的 upstream 名称,下划线 _ 并不是一个被广泛接受的字符。虽然 Nginx 对此的支持有所变化,但在某些版本或配置中,下划线可能会导致解析或处理问题。
特别说明: 关于这个的原因我也不太确定,我只是提供了我认可的一种解释

相关推荐
维尔切32 分钟前
Shell 脚本编程:函数
linux·运维·自动化
云泽8081 小时前
从ENIAC到Linux:计算机技术与商业模式的协同演进
linux·运维·服务器
wheeldown1 小时前
【Linux】【实战向】Linux 进程替换避坑指南:从理解 bash 阻塞等待,到亲手实现能执行 ls/cd 的 Shell
linux·运维·bash
ZeroNews内网穿透1 小时前
企业远程访问方案选择:何时选内网穿透,何时需要反向代理?
运维·服务器·网络·python·安全
看好多桂花树1 小时前
Nginx 优化
运维·nginx
羑悻的小杀马特2 小时前
Docker 容器化部署核心实战:从镜像仓库管理、容器多参数运行到 Nginx 服务配置与正反向代理原理解析
nginx·docker·容器·镜像仓库
NiKo_W2 小时前
Linux 深入理解权限
linux·运维·服务器
zzywxc7872 小时前
自动化测试框架是软件测试的核心基础设施,通过预设规则和脚本自动执行测试用例,显著提高测试效率和覆盖率。
运维·人工智能·自动化·prompt·测试用例·流程图
郝学胜-神的一滴2 小时前
深入探索 Python 元组:从基础到高级应用
运维·服务器·开发语言·python·程序人生
CheungChunChiu3 小时前
嵌入式 Linux 启动机制全解析:从 Boot 到 Rootfs
linux·运维·服务器·ubuntu·uboot·boot·extboot