当前位置： 首页 > news >正文

【运维进阶】高可用和负载均衡技术

news 2025/8/25 5:50:28

高可用和负载均衡技术

集群概念

集群是什么

集群（Cluster）是由多台独立计算机（节点）通过网络连接组成的一个整体系统，这些节点在软件（如集群管理工具、调度系统）的协调下，像 “一台逻辑计算机” 一样协同工作，共同完成单台计算机难以承担的计算、存储、服务等任务。

核心特点
  1. 协同工作：节点间并非独立运行，而是通过统一的管理机制分配任务、共享资源，目标是高效完成特定业务（如数据处理、服务部署）。
  2. 可扩展性：当业务需求增长时，无需替换现有设备，只需新增节点加入集群，即可提升整体性能（如计算能力、存储容量）。
  3. 高可用性：集群支持 “故障转移”—— 若某台节点故障，其负责的任务会自动转移到其他正常节点，避免服务中断（比如网站集群，单台服务器宕机不影响用户访问）。
  4. 资源共享：节点可共享集群内的硬件资源（如存储磁盘、CPU 算力）和软件资源（如数据库、应用程序），避免资源浪费。
常见类型（按用途划分）
类型核心用途典型场景举例
计算集群集中多节点算力，处理大规模计算任务科学计算（如气象模拟）、AI 训练、大数据分析（Hadoop 集群）
存储集群整合多节点存储资源，提供大容量、高可靠存储企业数据备份、云存储（如 Ceph 集群）、视频监控数据存储
服务集群部署同一服务到多节点，实现高可用、高并发网站服务（Nginx 集群）、数据库集群（MySQL 主从集群）、API 服务集群

Load Balance cluster(负载均衡集群)

即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。

例如：四兄弟开裁缝铺，生意特别多，一个人做不下来，老是延误工期，于是四个兄弟商量：老大接订单, 三个兄弟来干活。客户多起来之后，老大根据一定的原则(policy) 根据三兄弟手上的工作量来分派新任务。

High Availability cluster(高可用集群)

利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。

例如：两兄弟开早餐铺，生意不大，但是每天早上7点到9点之间客户很多并且不能中断。为了保证2个小时内这个早餐铺能够保证持续提供服务，两兄弟商量几个方法:

方法一：平时老大做生意，老二这个时间段在家等候，一旦老大无法做生意了，老二就出来顶上，这个叫做 Active/Standby(双机冷备)

方法二：平时老大做生意，老二这个时候就在旁边帮工，一旦老大无法做生意，老二就马上顶上，这个叫做Active/Passive(双机热备)

方法三：平时老大卖包子，老二也在旁边卖豆浆，老大有问题，老二就又卖包子，又卖豆浆，老二不行了，老大就又卖包子，又卖豆浆。这个叫做Active/Active (dual Active)(双机互备)。

High Performance Computing clustering(高性能计算集群)

即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域，比如基因分析、化学分析等。

例如：10个兄弟一起做手工家具生意，一个客户来找他们的老爹要求做一套非常复杂的仿古家具，一个人做也可以做，不过要做很久很久，为了1个星期就交出这一套家具，10个兄弟决定一起做。老爹把这套家具的不同部分分开交给儿子们作，然后每个儿子都在做木制家具的加工，最后拼在一起。老爹是scheduler任务调度器，儿子们是compute node. 他们做的工作叫做作业。

简单类比理解

可以把集群看作 “团队”：单台计算机是 “单个员工”，集群就是 “一个团队”—— 团队有统一的负责人（集群管理工具），根据成员（节点）的能力分配工作，有人请假（节点故障）时，其他人会接手其任务，确保团队目标（业务需求）按时完成，且团队规模可随时扩招（新增节点）。

负载均衡集群

负载均衡集群是服务集群的核心类型之一，其核心目标是通过特定算法将客户端的请求（如网页访问、API 调用、数据请求等）均匀分配到集群中的多个节点（服务器），避免单节点因请求过载而性能下降或宕机，最终实现 “高并发处理能力” 与 “服务稳定性” 的双重保障。

一、核心原理

负载均衡集群的工作流程可简化为 3 步，核心依赖 “负载均衡器（Load Balancer）” 这个 “调度中枢”：

  1. 请求接入：所有客户端请求不会直接访问后端节点，而是先发送到负载均衡器（集群的 “入口”，可单机或双机热备确保自身高可用）。
  2. 智能分配：负载均衡器根据预设的 “负载均衡算法”，结合后端各节点的实时状态（如 CPU 使用率、内存占用、当前连接数），判断哪个节点最适合处理新请求，并将请求转发给该节点。
  3. 节点响应：后端节点处理请求后，将结果返回给客户端（部分架构中结果会先回传给负载均衡器，再由其转发给客户端）。

整个过程对客户端 “透明”—— 用户感知不到背后有多台服务器，只觉得是在访问一台 “性能极强” 的服务器。

二、关键特性

  1. 请求均匀分发：避免 “单节点过载、其他节点闲置” 的资源浪费，最大化利用集群整体算力。
  2. 高并发支撑：通过多节点并行处理请求，集群能承载的并发量远高于单节点（例如单节点能扛 1 万并发，10 节点集群可支撑 8-10 万并发，具体取决于算法和业务特性）。
  3. 故障自动隔离：负载均衡器会实时监控后端节点状态，若某节点故障（如宕机、服务无响应），会自动将其从 “可用节点列表” 中剔除，不再分配新请求；待节点恢复后，再重新纳入集群，确保服务不中断。
  4. 可弹性扩展：业务高峰期时，只需新增后端节点并加入集群，负载均衡器会自动识别并分配请求，无需修改客户端配置，快速提升服务承载能力。

三、常见负载均衡算法（核心调度逻辑）

不同场景适配不同算法，以下是最常用的几种：

算法类型核心逻辑适用场景
轮询（Round Robin）按节点顺序依次分配请求（1→2→3→1→2→3…）后端所有节点硬件配置一致、业务无状态（如静态网页服务）
加权轮询（Weighted RR）给性能强的节点设置更高 “权重”，分配更多请求（如权重 3 的节点比权重 1 的多接 3 倍请求）节点硬件配置不一致（如部分节点 CPU / 内存更强）
最少连接（Least Connections）优先将请求分配给当前连接数最少的节点业务请求处理时间差异大（如动态 API 服务，部分请求耗时久）
IP 哈希（IP Hash）根据客户端 IP 计算哈希值，固定将某 IP 的请求分配给同一节点需要 “会话保持” 的场景（如用户登录后，后续请求需到同一节点获取登录状态）

四、典型应用场景

  • Web 服务：如电商网站、门户网站（通过 Nginx/LVS 负载均衡集群，支撑双 11、春运购票等高峰期高并发）。
  • API 服务：如移动 App 后端 API、第三方开放平台 API（分散请求压力，避免单节点因大量调用崩溃）。
  • 数据库读写分离：部分负载均衡器（如 ProxySQL）可将 “读请求” 分配到多个从库，“写请求” 转发到主库，减轻主库压力。
  • 云服务场景：公有云（如阿里云 SLB、AWS ELB）的核心组件，为用户提供弹性、高可用的负载均衡服务。

五、常见实现工具

  • 硬件级：F5 BIG-IP（性能强、稳定性高，但成本昂贵，适合大型企业核心业务）。
  • 软件级：
    • Nginx：轻量高效，支持 HTTP/HTTPS 协议，适合七层（应用层）负载均衡。
    • LVS（Linux Virtual Server）：基于 Linux 内核，性能接近硬件，适合四层（传输层，如 TCP 协议）负载均衡。
    • HAProxy：支持四层和七层，功能丰富，常用于高要求的企业级服务。

HAProxy

官网 https://www.haproxy.org/

文档 https://www.haproxy.org/#docs

下载 https://www.haproxy.org/#down

介绍

简介

  • 一款开源的负载均衡软件，支持 TCP（四层）和 HTTP（七层）代理。

  • 以高性能和高并发著称，广泛应用于互联网企业。

特点

  • 支持四层（TCP）和七层（HTTP）代理。

  • 内置多种负载均衡算法（轮询、最少连接、源地址哈希等）。

  • 高并发性能强，支持数十万连接。

  • 提供健康检查，能自动剔除故障节点。

  • 提供状态统计页面，便于运维监控。

常见负载均衡算法

  • roundrobin：轮询，默认方式。

  • leastconn：最少连接，优先选择连接数少的服务器。

  • source：根据请求源 IP 分配，保证同一 IP 始终访问同一服务器。

HAProxy 实践
部署：
[root@centos7 ~ 22:10:32]# vim /etc/hosts
[root@centos7 ~ 22:11:10]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
#####
10.1.8.10    lb.xiexin.cloud        lb
10.1.8.11    web1.xiexincloud       web1
10.1.8.12    web2.xiexin.cloud      web2
10.1.8.13    web3.xiexin.cloud      web3
10.1.8.20    router.xiexin.cloud    router
10.1.8.21    client1.xiexin.cloud   client1
10.1.1.21    client2.xiexin.cloud   client2

lb

添加一块网卡，选vm1sethost 10[root@lb ~ 22:13:52]# nmcli connection modify 7f031843-1f62-3beb-8783-8888d08dc2b8 connection.id ens37 ipv4.method manual ipv4.addresses 10.1.1.10/24
[root@lb ~ 22:14:27]# nmcli connection up ens37
连接已成功激活（D-Bus 活动路径：/org/freedesktop/NetworkManager/ActiveConnection/8）
[root@lb ~ 12:34:40]# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
ens33            UP             10.1.8.10/24 fe80::20c:29ff:fe80:a684/64 
ens37            UP             10.1.1.10/24 fe80::ee29:4731:589:aa3c/64

router

和lb一样，也要添加网卡还有上面的操作+
# 开启路由
[root@router ~ 22:28:57]# echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
[root@router ~ 22:29:15]# sysctl -p
net.ipv4.ip_forward = 1# 防火墙
[root@router ~ 22:29:26]# systemctl enable firewalld.service --now
Created symlink from /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service to /usr/lib/systemd/system/firewalld.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/firewalld.service to /usr/lib/systemd/system/firewalld.service.
[root@router ~ 22:29:39]# firewall-cmd --set-default-zone=trusted
success
[root@router ~ 22:29:44]# firewall-cmd --add-masquerade --permanent 
success

client2

 网卡选vm1nmcli connection modify ens33 ipv4.address 10.1.1.21/24
hostnamectl set-hostname client2.xiexin.cloud[root@client2 ~ 22:35:24]# ip r
default via 10.1.8.2 dev ens33 proto static metric 100 
10.1.1.0/24 dev ens33 proto kernel scope link src 10.1.1.21 metric 100 
10.1.8.2 dev ens33 proto static scope link metric 100 
[root@client2 ~ 22:35:31]# nmcli connection modify ens33 ipv4.gateway 10.1.1.20
[root@client2 ~ 22:35:39]# nmcli connection up ens33 
连接已成功激活（D-Bus 活动路径：/org/freedesktop/NetworkManager/ActiveConnection/2）
[root@client2 ~ 22:35:44]# ip r
default via 10.1.1.20 dev ens33 proto static metric 100 
10.1.1.0/24 dev ens33 proto kernel scope link src 10.1.1.21 metric 100
http 模式

配置 web

web1.2.3都要配置
# 给每台后端 Web 服务器额外准备一组“测试服务”# 部署 web
[root@web1-3 ~ 22:40:16]# yum install -y nginx
[root@web1-3 ~ 22:40:21]# echo Welcome to $(hostname) > /usr/share/nginx/html/index.html 
[root@web1-3 ~ 22:40:27]# systemctl enable nginx.service --now
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.[root@web1-3 ~ 22:40:33]# systemctl enable nginx.service --now
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.# 测试
# 访问后端 nginx
[root@client1 ~ 22:40:41]# curl 10.1.8.11
Welcome to web1.xiexin.cloud
[root@client1 ~ 22:40:44]# curl 10.1.8.12
Welcome to web2.xiexin.cloud
[root@client1 ~ 22:40:48]# curl 10.1.8.13
Welcome to web3.xiexin.cloud# 准备虚拟主机
[root@web1-3 ~ 22:45:14]# cat > /etc/nginx/conf.d/vhost-test.conf <<'EOF'
> server {
>     listen       81;
>     root         /test;
> }
> EOF
[root@web1-3 ~ 22:45:20]# systemctl restart nginx# 准备测试文件
[root@web1-3 ~ 22:45:29]# mkdir /test
[root@web1-3 ~ 22:45:36]# echo hello txt from $(hostname -s) > /test/index.txt
[root@web1-3 ~ 22:45:44]# echo hello html from $(hostname -s) > /test/index.html# 测试
[root@client1 ~ 22:45:51]# curl http://web1:81/
hello html from web1
[root@client1 ~ 22:45:55]# curl http://web2:81/
hello html from web2
[root@client1 ~ 22:45:59]# curl http://web3:81/
hello html from web3
配置 haproxy

情况1

# 轮询负载均衡[root@lb ~ 22:50:35]# yum install -y haproxy# 先备份一份再修改
[root@lb ~ 22:50:41]# cp /etc/haproxy/haproxy.cfg{,.ori}
[root@lb ~ 22:50:44]# vim /etc/haproxy/haproxy.cfg
# 在最后添加
frontend front_webbind *:80use_backend  back_web#acl test url_reg -i \.txt$#use_backend test if testbackend back_webbalance     roundrobinserver web1 10.1.8.11:80 checkserver web2 10.1.8.12:80 checkserver web3 10.1.8.13:80 check# frontend：定义前端，监听在 *:80
# use_backend back_web：转发到 back_web
# backend back_web：定义后端负载均衡池
# balance roundrobin：轮询算法
# check：启用健康检查，不可用的节点会被自动摘掉# 启动服务
[root@lb ~ 22:50:53]# systemctl start haproxy# 测试
# balance roundrobin → 轮询调度算法
[root@client1 ~ 22:53:28]# curl http://lb.xiexin.cloud/
Welcome to web1.xiexin.cloud
[root@client1 ~ 22:53:31]# curl http://lb.xiexin.cloud/
Welcome to web2.xiexin.cloud
[root@client1 ~ 22:53:36]# curl http://lb.xiexin.cloud/
Welcome to web3.xiexin.cloud# for循环测试
[root@client2 ~ 22:54:01]# for i in {1..90}; do curl http://lb.xiexin.cloud; done
[root@client2 ~ 22:54:16]# for i in {1..90}; do curl -s http://lb.xiexin.cloud; done | sort | uniq -c30 Welcome to web1.xiexin.cloud30 Welcome to web2.xiexin.cloud30 Welcome to web3.xiexin.cloud

情况二

# ACL 访问控制 + 轮询调度[root@lb ~ 22:55:18]# vim /etc/haproxy/haproxy.cfg
frontend front_webbind *:80default_backend  back_webacl test url_reg -i \.txt$use_backend back_test if testbackend back_webbalance     roundrobinserver web1 10.1.8.11:80 checkserver web2 10.1.8.12:80 checkserver web3 10.1.8.13:80 checkbackend back_testbalance    roundrobinserver test1 10.1.8.11:81 checkserver test2 10.1.8.12:81 checkserver test3 10.1.8.13:81 check# bind *:80 → 前端监听 80 端口
# default_backend back_web → 默认转发到 back_web （80 端口的 nginx）
# acl test url_reg -i \.txt$ → 定义 ACL 规则：如果 URL 以 .txt 结尾
# use_backend back_test if test → 如果匹配到 .txt 文件，就转发到 back_test[root@lb ~ 22:55:34]# systemctl restart haproxy# 测试
[root@client2 ~ 22:55:41]# for i in {1..90}; do curl -s http://lb.xiexin.cloud/index.txt; done | sort | uniq -c 30 hello txt from web130 hello txt from web230 hello txt from web3# 普通请求 (/ 或 .html) → 走 80 端口后端
# .txt 请求 → 走 81 端口后端，并且被 平均轮询到 web1/web2/web3

Nginx

介绍

Nginx（发音为 “engine x”）是一款由俄罗斯开发者 Igor Sysoev 开发的高性能、轻量级的 HTTP 服务器 / 反向代理服务器 / 负载均衡器，同时也支持邮件代理服务。其设计核心围绕 “高并发、低资源消耗”，自 2004 年发布以来，凭借优异的性能和稳定性，成为全球最主流的 Web 服务组件之一（据统计，全球 TOP 100 万网站中，超 30% 采用 Nginx 作为核心服务）。

一、核心定位与核心优势

Nginx 的核心价值在于解决 “高并发场景下的服务效率与稳定性” 问题，主要优势可概括为以下 4 点：

1. 超高并发处理能力

Nginx 采用异步非阻塞 I/O 模型（epoll 模型，Linux 下），不同于 Apache 传统的 “多进程 / 多线程” 模型（每个请求对应一个进程 / 线程，高并发时资源消耗剧增）。

  • 原理：单进程 / 多进程（默认 1 个主进程 + 多个工作进程）可同时处理数万甚至数十万并发连接，每个工作进程仅占用少量内存（通常每个进程内存消耗在 2-4MB）。
  • 场景：能轻松支撑电商秒杀、春运购票、大型直播等 “瞬间高并发” 场景，是高流量网站的首选。

2. 轻量级与低资源消耗

  • 代码简洁：核心代码仅数万行，无冗余模块，启动速度极快（通常毫秒级启动）。
  • 资源占用低：正常运行时，主进程负责管理配置和工作进程，工作进程数量可根据 CPU 核心数配置（如 4 核 CPU 配置 4 个工作进程），整体内存和 CPU 消耗远低于同类服务器（如 Apache）。

3. 功能全面且灵活

Nginx 不仅是 HTTP 服务器，还具备丰富的扩展功能，可通过 “模块” 灵活扩展（官方模块 + 第三方模块），核心功能包括：

  • HTTP 服务：静态资源（HTML、CSS、JS、图片、视频）高效分发，支持 gzip 压缩、浏览器缓存、SSL/TLS 加密（HTTPS）等。
  • 反向代理：作为客户端与后端服务（如 Tomcat、Node.js、Python 服务）的中间层，接收客户端请求后转发给后端节点，隐藏后端服务地址，提升安全性，同时实现 “动静分离”（Nginx 处理静态资源，后端处理动态请求）。
  • 负载均衡：作为负载均衡器，支持轮询、加权轮询、最少连接等算法，将请求均匀分配到后端多节点，支撑高并发并实现服务高可用。
  • 邮件代理：支持 IMAP/POP3/SMTP 协议，可作为邮件服务器的代理，实现邮件请求的转发和负载均衡。

4. 高稳定性与可靠性

  • 主从进程架构：主进程（Master）负责读取配置、管理工作进程（Worker），工作进程负责处理实际请求；若某工作进程异常崩溃，主进程会立即重启新的工作进程，确保服务不中断。
  • 热部署与热更新：支持在不停止服务的情况下，更新配置文件（nginx -s reload）、升级 Nginx 版本，满足生产环境 “零停机维护” 的需求。
二、典型应用场景

Nginx 的灵活性使其适配多种业务场景，以下是最常见的 4 类：

应用场景核心作用示例
静态资源服务器高效分发 HTML、CSS、图片、视频等静态资源，通过 gzip 压缩和缓存减少带宽消耗网站的静态资源（如官网的图片、前端打包后的 JS 文件）直接由 Nginx 提供服务
反向代理 + 动静分离Nginx 接收所有请求，静态请求自己处理，动态请求（如接口调用）转发给后端服务电商网站：Nginx 处理商品图片（静态），将 “下单请求” 转发给 Tomcat 后端（动态）
负载均衡器将高并发请求分配到后端多节点，避免单节点过载，提升服务可用性App 后端 API 服务：Nginx 把用户请求转发给 3 台 Node.js 节点，实现并发支撑
HTTPS 终端集中处理 SSL/TLS 加密解密（代替后端服务处理），减少后端资源消耗所有客户端 HTTPS 请求先到 Nginx，解密后再转发给后端 HTTP 服务，提升效率
三、核心架构（简单理解）

Nginx 采用 “主进程 + 工作进程” 的多进程架构，核心流程如下：

  1. 主进程（Master Process）：
    • 启动时读取并验证配置文件（nginx.conf）。
    • 根据配置创建指定数量的工作进程（Worker Process）。
    • 监控工作进程状态，若工作进程崩溃则自动重启。
    • 接收管理员指令（如启动、停止、重载配置）。
  2. 工作进程（Worker Process）：
    • 数量通常配置为与 CPU 核心数一致（充分利用多核资源，避免进程切换开销）。
    • 每个工作进程独立处理客户端请求，通过异步非阻塞 I/O 模型高效处理大量并发连接。
四、总结

Nginx 凭借 “高并发、低资源、稳可靠、功能全” 的特性，成为现代 Web 架构中不可或缺的组件 —— 无论是小型网站的静态资源服务，还是大型互联网企业的高并发核心集群，Nginx 都能发挥关键作用。其简单的配置、丰富的模块生态和优异的性能，使其成为开发者和运维人员的首选工具之一。

Nginx 实践
配置 router

同上

# 开启路由
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 或者
# sed -i "s/ip_forward=0/ip_forward=1/g" /etc/sysctl.conf
sysctl -p
配置 web

和haproxy一样

配置 Nginx 代理
# Nginx 反向代理 + 负载均衡# 在负载均衡器 lb 上安装 nginx
[root@lb ~ 22:57:25]# yum install -y nginx# 配置 upstream 与代理规则
[root@lb ~ 22:57:38]# vim /etc/nginx/conf.d/proxy.conf
[root@lb ~ 22:57:44]# cat /etc/nginx/conf.d/proxy.conf
upstream web {server 10.1.8.11:80;server 10.1.8.12:80;server 10.1.8.13:80;
}
server {listen       80;server_name  www.xiexin.cloud;root         /usr/share/nginx/html;# Load configuration files for the default server block.include /etc/nginx/default.d/*.conf;location / {# 添加如下语句proxy_pass http://web;}
}# upstream web {} 定义后端服务器池 (web1、web2、web3)
# proxy_pass http://web; 把请求转发给 upstream 组
# 默认 round-robin 轮询算法，会依次把请求分发到 11、12、13[root@lb ~ 22:57:51]# systemctl restart nginx.service# 客户端域名解析
[root@client2 ~ 22:58:01]# echo "10.1.8.10 www.xiexin.cloud www" >> /etc/hosts
[root@client1 ~ 22:58:10]# echo "10.1.8.10 www.xiexin.cloud www" >> /etc/hosts# 测试负载均衡效果
[root@client2 ~ 22:58:21]# curl http://www.xiexin.cloud
Welcome to web1.xiexin.cloud
[root@client2 ~ 22:58:25]# curl http://www.xiexin.cloud
Welcome to web2.xiexin.cloud
[root@client2 ~ 22:58:33]# curl http://www.xiexin.cloud
Welcome to web3.xiexin.cloud
负载均衡-算法
[root@lb ~ 23:02:33]# vim /etc/nginx/conf.d/proxy.conf
upstream web {server 10.1.8.11:80 weight=10;server 10.1.8.12:80 weight=20;server 10.1.8.13:80 weight=30;
}[root@client2 ~ 23:02:48]# for i in {1..90}; do curl -s http://www.xiexin.cloud/; done | sort | uniq -c15 Welcome to web1.xiexin.cloud30 Welcome to web2.xiexin.cloud45 Welcome to web3.xiexin.cloud

总结

nginx
优点
  • Nginx工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构。**它的正则规则比 HAProxy 更为强大和灵活，这也是它目前广泛流行的主要原因之一。**location 使用灵活，应用场合广泛。
  • Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大。
  • Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试需要比较长的时间了。
  • Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。
  • Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。
  • Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。
  • Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。
  • Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。
缺点
  • Nginx仅支持http、https和Email协议，这样就在适用范围上面小些，这个是它的缺点。
  • 对后端服务器的健康检查，只支持通过端口来检测，不支持通过 url 来检测。
  • 不支持 Session 的直接保持，但能通过 ip_hash 来解决。
haproxy
优点

  • HAProxy 支持虚拟主机。

  • HAProxy 的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的 url 来检测后端服务器的状态。

  • HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

  • HAProxy支持TCP协议的负载均衡转发，例如对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。

  • HAProxy 负载均衡策略非常多。

缺点
  • 对http分流，弱与nginx。
http://www.dtcms.com/a/348165.html

相关文章：

  • 港口集装箱编号识别误识率↓79%！陌讯多模态融合算法落地优化
  • 静电服漏检率↓79%！陌讯多模态识别算法在智慧安检的实战解析
  • 下料口堵塞误报率↓79%！陌讯多模态融合算法在工业物料输送的实战解析
  • 电子厂静电释放检测误报率↓81%！陌讯多模态融合算法在安全生产监控的落地实践
  • 【Linux】Java线上问题，一分钟日志定位
  • 【C语言强化训练16天】--从基础到进阶的蜕变之旅:Day12
  • lanczos算法的核心——Ritz向量的计算（主要思想为反向映射）
  • 《一次高并发场景下疑难Bug的深度排查与复盘》
  • 基于Langchain框架的DeepSeek-v3+Faiss实现RAG知识问答系统（含完整代码）
  • 【股票数据API接口12】如何获取股票近年分红数据之Python、Java等多种主流语言实例代码演示通过股票数据接口获取数据
  • AI-调查研究-59-机器人 行业职业地图：发展路径、技能要求与薪资全解读
  • Android - 用Scrcpy 将手机投屏到Windows电脑上
  • [创业之路-567]：数字技术、数字产品、数字资产、数字货币、数字企业、数字经济、数字世界、数字人生、数字智能、数字生命
  • 第一个小项目java
  • Linux 软件编程(十)网络编程：网络协议，UDP 与 TCP 知识点
  • 逆光场景识别率↑76%！陌讯多模态融合算法在手机拍照识别的落地实践​
  • 【网络运维】Shell 脚本编程： for 循环与 select 循环
  • ARINC 825板卡的应用
  • vue-pure-admin页面引入和功能添加流程解析
  • Smooze Pro for mac 鼠标手势增强软件
  • 力扣【1277. 统计全为1的正方形子矩阵】——从暴力到最优的思考过程
  • 商超客流密度统计误差率↓35%！陌讯多模态融合算法在零售智慧运营的实战解析
  • 智慧零售商品识别误报率↓74%！陌讯多模态融合算法在自助结算场景的落地优化
  • Ubuntu24.04 安装 Zabbix
  • 使用UE5开发2.5D开放世界战略养成类游戏的硬件配置指南
  • IDM 下载失败排查指南：全面解析与解决方案
  • 马斯克宣布开源Grok 2.5：非商业许可引争议，模型需8×40GB GPU运行，Grok 3半年后开源
  • Redis实战-缓存的解决方案（一）
  • 【贪心算法】day1
  • 【数学建模】灰色关联分析的核心步骤