服务高可用

一、Keepalive：理论架构、如何实现的集群高可用？

Keepalived软件主要通过VRRP协议实现高可用功能的。VRRP是Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障问题，它能够保证当个别节点宕机时，整个网络可以不间断地运行。keepalived除了能够管理LVS软件外，还可以作为其他服务（Nginx，Haproxy、MySQL等）的高可用解决方案软件。

📌 组成结构：

角色 作用
主节点（Master） 持有 VIP，对外提供服务
备节点（Backup） 监控主节点状态，主节点故障后接管 VIP
VIP（Virtual IP） 虚拟 IP，始终只有一个节点持有，客户端通过它访问服务
健康检查（optional） 可配置对后端服务的探测，例如检查 Nginx、MySQL 是否存活

keepalive可以实现：

1、主备切换，优先级，当主故障时，可以自动切换到备，主恢复之后，如果主的优先级比备高，还是会自动的切换到主。

2、故障检测和恢复功能

3、主备之间通过组播地址（224.0.0.18），互相发送健检查的报文，确定主备之间通信（确定双方是否工作正常）。

4、通过配置vip来实现集群的入口，vrrp是一个冗余（一方工作另一方备着）协议，主在工作时，备完全不参与集群的工作，只是监听主的状态。

二、Keepalive：基于nignx做服务高可用，配置nginx主备，主宕从上

主机 角色 所需服务 说明
nginx1 主节点（Master）:192.168.152.132 Nginx + Keepalived 持有 VIP，正常提供服务
nginx2 备节点（Backup）:192.168.152.134 Nginx + Keepalived 监控主节点，故障时接管 VIP
客户端 测试访问端 curl、浏览器等 用于访问 VIP 检验漂移

1.两台服务器都安装Keepalived

[root@nginx2 conf]# yum -y install keepalived

2.配置主节点

[root@nginx2 conf]# vim /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state MASTER
    interface ens33  #特别注意：interface 网卡名称必须是实际存在的网卡！
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.152.200     #配置vip
    }   
}

3.配置备节点

[root@nginx3 html]# vim /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state BACKUP   #修改为备节点
    interface ens33  #特别注意：interface 网卡名称必须是实际存在的网卡！
    virtual_router_id 51
    priority 90      #备节点写 90 或更小
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.152.200     #配置vip
    }   
}

4.配置健康脚本并在配置文件里添加脚本

主服务器

[root@nginx2 conf]# vim /etc/keepalived/chk_nginx.sh

#!/bin/bash
pidof nginx > /dev/null 2>&1 || exit 1

[root@nginx2 conf]# chmod +x /etc/keepalived/chk_nginx.sh
[root@nginx2 conf]# vim /etc/keepalived/keepalived.conf 
#将vrrp_script chk_nginx添加在global_defs模块后
vrrp_script chk_nginx {
    script "/etc/keepalived/chk_nginx.sh"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.152.200
    }
    track_script {
        chk_nginx
    }                  #添加脚本
}
[root@nginx2 conf]# systemctl restart keepalived

备服务器

[root@nginx3 html]# vim /etc/keepalived/chk_nginx.sh

#!/bin/bash
pidof nginx > /dev/null 2>&1 || exit 1

[root@nginx3 html]# chmod +x /etc/keepalived/chk_nginx.sh
[root@nginx3 html]# vim /etc/keepalived/keepalived.conf 
#将vrrp_script chk_nginx添加在global_defs模块后
vrrp_script chk_nginx {
    script "/etc/keepalived/chk_nginx.sh"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.152.200
    }
    track_script {
        chk_nginx
    }               #添加脚本
}
[root@nginx3 html]# systemctl restart keepalived

4.启动服务

#主服务器和备服务器分别启动
[root@nginx2 conf]# systemctl start keepalived
[root@nginx2 conf]# systemctl enable keepalived

[root@nginx3 html]# systemctl start keepalived
[root@nginx3 html]# systemctl enable keepalived

5.验证

访问192.168.152.200

正常访问后,关闭主服务器,再次访问192.168.152.200

[root@nginx2 conf]# systemctl stop nginx

页面还可以正常访问,从备服务器查看vip是否存在

[root@nginx3 html]# ip a | grep 192.168.152.200
    inet 192.168.152.200/32 scope global ens33

三、LVS：理论架构、如何实现的？负载均衡算法有哪些？

1.LVS （Linux Virtual Server）理论架构

组件 作用 典型软件
调度器（Director/Load Balancer） 位于 IP 层（L4），接收客户端请求并按照调度算法把包转发到后端 Real Server ip_vs 内核模块 + ipvsadm / keepalived
Real Server（RS） 真正处理业务逻辑的服务器，可以是 Web、API、数据库读节点等 任意 TCP/UDP 服务
共享存储或数据同步 保证各 RS 之间数据一致性（静态文件、会话、数据库） NFS、Ceph、Redis、MySQL replica 等
健康检查/高可用 定期探测 RS 状态、故障隔离；探测 Director 自身并进行主备切换 keepalived、lvs-healthd

LVS 在 Linux 内核层完成包的重写和转发，不需要用户态代理进程，因而转发效率极高，可轻松撑到数十甚至数百 Gbps。

常见三种集群转发模式：

  1. NAT（SNAT/DNAT）模式
    调度器既改目的地址也改源地址，易穿防火墙；流量回程仍经过调度器，性能瓶颈明显。
  2. DR（Direct Routing）模式
    只有报文的目标 MAC 被修改，IP 不变；回复流量直接回客户端，性能最佳，要求 RS 与 VIP 同网段。
  3. TUN（IP Tunneling）模式
    调度器把包封装为 IP-in-IP 发给 RS，RS 解封后直接回客户端；跨网段、性能次于 DR、好于 NAT。

在实践中，生产最常见的是 DR 模式 + Keepalived：一个或两个 Director 通过 VRRP 漂移 VIP，再通过 IPVS 把流量分配给后端 RS。

2.如何实现

一、基本架构准备

  1. 准备一台调度器（Director） 和若干台 后端真实服务器（Real Server）
  2. Director 配置一个对外的虚拟IP（VIP），客户端请求统一访问这个 VIP

二、开启 LVS 核心功能

  1. 在 Director 上启用 Linux 内核的 LVS 功能（使用 ipvs 模块）
  2. 在 Real Server 上配置好业务服务（如 Web、API）

三、设置调度规则

  1. 在 Director 上配置 LVS 的调度规则，将 VIP 的访问请求转发到多个 Real Server 上
  2. 选择合适的负载均衡算法（如轮询、最少连接、源地址散列等）

四、后端响应优化（根据模式）

​ 根据使用的转发模式（如 DR、NAT、TUN）决定 Real Server 的 VIP 和网络行为

  • 常用的是 DR 模式，Real Server 配置“伪VIP”，并禁止回应 ARP

五、加上高可用与健康检查

​ 使用 Keepalived 或其他工具实现：

  • Director 的 主备切换（通过 VRRP 漂移 VIP）
  • Real Server 的 健康检查与自动移除

六、最终结果

  1. 客户端访问 VIP → LVS 透明调度 → 健康、负载合理的 Real Server → 服务返回
  2. 即使某台 Real Server 或主调度器故障，系统也能自动切换，不影响访问。

3.LVS 支持的负载均衡算法

调度器选项 名称 适用场景与特点
rr 轮询 Round-Robin 每个连接按顺序分发，RS 性能相近时最简单
wrr 加权轮询 根据服务器权值分发，权值可手动或动态调整
lc 最少连接 Least-Connection 把新连接分配给当前连接数最少的 RS
wlc 加权最少连接 考虑连接数 / 权重，适合性能差异大
lblc 本地最少连接 (Locality-Based LC) 针对多网段缓存服务器，保持同一客户端/目的 IP 的局部性
lblcr 带复制的本地最少连接 在 lblc 基础上自动复制热点 RS
dh 目标散列 Destination Hashing 按目标 IP hash，适合防火墙后端或透明代理
sh 源散列 Source Hashing 按源 IP hash，保持会话粘性
sed 最短期望延迟 Shortest Expected Delay 动态计算 (连接数+1)/权重，倾向空闲且高权值 RS
nq 不排队 Never Queue 若 RS 连接数超过其权重则跳过，低延迟抢占式

经验：Web 场景常用 wrr 或 wlc；长连接或需要会话保持可用 sh；缓存集群可用 lblc/lblcr。

四、LVS：基于两台nginx做负载均衡，lvs将请求负载均衡转发到两个nginx上

环境说明

主机角色 IP地址 描述
LVS调度器（Director） 192.168.152.131 对外提供服务入口，配置 VIP 和 LVS
Nginx后端1 192.168.152.133 提供真实服务
Nginx后端2 192.168.152.134 提供真实服务
VIP（虚拟IP） 192.168.152.200 客户端访问这个地址，由 LVS 调度到后端

在之前的操作中两台nginx服务器已经配置完成

暂停nginx2和nginx3的keepalived服务

nginx2：
[root@nginx2 keepalived]# systemctl stop keepalived
nginx3：
[root@nginx3 keepalived]# systemctl stop keepalived

步骤 1：在两台nginx服务器上绑定 VIP 到本地回环接口

nginx2：
[root@nginx2 keepalived]# ip addr add 192.168.152.200/32 dev lo

nginx3：
[root@nginx3 keepalived]# ip addr add 192.168.152.200/32 dev lo
#用 /32 是为了不影响正常路由，也避免冲突。

步骤 2：在两台nginx服务器上配置系统参数，禁止 ARP 应答 VIP

nginx2：
[root@nginx2 keepalived]# cat >> /etc/rc.local <<EOF
 ip addr add 192.168.152.200/32 dev lo
 echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
 echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
 echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
 echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
 EOF
[root@nginx2 keepalived]# chmod +x /etc/rc.d/rc.local

nginx3：
[root@nginx3 keepalived]# cat >> /etc/rc.local <<EOF
 ip addr add 192.168.152.200/32 dev lo
 echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
 echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
 echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
 echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
 EOF
[root@nginx3 keepalived]# chmod +x /etc/rc.d/rc.local
#避免两台机器都响应 VIP 的 ARP 请求，防止冲突。

步骤3：LVS 调度服务器启用 IP 转发功能

[root@nginx1 ~]# echo 1 > /proc/sys/net/ipv4/ip_forward

可持久化设置 /etc/sysctl.conf：

[root@nginx1 ~]# vim /etc/sysctl.conf 

net.ipv4.ip_forward = 1

[root@nginx1 ~]# sysctl -p
net.ipv4.ip_forward = 1

步骤4：LVS 调度服务器配置 VIP

[root@nginx1 ~]# ip addr add 192.168.152.200/32 dev lo

也可以使用 ip a 查看是否生效。

步骤5：LVS 调度服务器安装并使用 ipvsadm 配置 LVS

[root@nginx1 ~]# yum install -y ipvsadm

添加 LVS 转发规则：

[root@nginx1 ~]# ipvsadm -A -t 192.168.152.200:80 -s rr
[root@nginx1 ~]# ipvsadm -a -t 192.168.152.200:80 -r 192.168.152.133:80 -g
[root@nginx1 ~]# ipvsadm -a -t 192.168.152.200:80 -r 192.168.152.134:80 -g

说明：

  • -A：添加虚拟服务（VIP+Port）
  • -s rr：采用轮询调度算法
  • -a：添加真实服务器
  • -g：使用 DR（Direct Routing）模式

步骤6：LVS 调度服务器查看 LVS 状态

[root@nginx1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.152.200:80 rr
  -> 192.168.152.133:80           Route   1      0          0         
  -> 192.168.152.134:80           Route   1      0          0

步骤7：客户端测试验证

五、LVS：基于《三》，使用wrk命令进行压力测试，使用不同的lvs 算法进行模拟测试。并记录每个算法的负载情况。

使用 wrk 对 LVS 进行压测，依次测试以下算法：

  1. rr：轮询（Round Robin）
  2. wrr：加权轮询（Weighted Round Robin）
  3. lc：最少连接（Least Connection）

✅ 环境准备

确保以下前提：

  • LVS（192.168.152.200）调度器已配置好；
  • 后端 Nginx 服务器（如 192.168.152.133 和 192.168.152.134）可用；
  • 后端主页设置了标识，如下 
    <h1>This is nginx2</h1>
<h1>This is nginx3</h1>

✅ 测试工具准备

如果你没有 wrk 工具，可按如下方式安装（以 CentOS 为例）：

# 安装依赖
[root@localhost ~]# yum install -y epel-release
[root@localhost ~]# yum install -y git make gcc openssl-devel
[root@localhost ~]# yum groupinstall -y "Development Tools"

# 克隆 wrk 源码
[root@localhost ~]# git clone https://github.com/wg/wrk.git

# 进入目录并编译
[root@localhost ~]# cd wrk
[root@localhost wrk]# make

# 拷贝到系统路径
[root@localhost wrk]# cp wrk /usr/local/bin/

# 验证是否安装成功
[root@localhost wrk]# wrk --version

✅rr：轮询（Round Robin）

[root@nginx1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.152.200:80 rr
  -> 192.168.152.133:80           Route   1      1          0         
  -> 192.168.152.134:80           Route   1      3          0

测试

[root@localhost wrk]# wrk -t2 -c2 -d10s http://192.168.152.200/
Running 10s test @ http://192.168.152.200/
  2 threads and 2 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.37ms    1.56ms  17.47ms   84.10%
    Req/Sec     1.04k   262.66     1.72k    65.50%
  20657 requests in 10.03s, 5.12MB read
Requests/sec:   2060.31
Transfer/sec:    523.03KB
  • -t2：使用 2 个线程
  • -c2：总共保持 2 个连接
  • -d10s：测试持续 10 秒
  • http://192.168.152.200/：请求的目标地址（你的 LVS 虚拟IP）

📊 输出结果解读：

Running 10s test @ http://192.168.152.200/
  2 threads and 2 connections

说明这次测试使用了 2 个线程、2 个连接，持续 10 秒。

mathematica复制编辑  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.37ms    1.56ms  17.47ms   84.10%
    Req/Sec     1.04k   262.66     1.72k    65.50%

含义解释：

  • Latency（延迟）：
    • 平均 1.37 毫秒：每次请求的响应时间平均为 1.37ms；
    • 最大延迟 17.47 毫秒：在测试中最慢的一次响应用了 17ms；
    • Stdev（标准差）1.56ms：大多数请求的延迟在 ±1.56ms 的范围波动；
    • 84.10% 的请求延迟落在这个标准差范围内，说明延迟稳定性较好。
  • Req/Sec（每秒请求数）：
    • 每个线程平均处理 约 1040 个请求/秒；
    • 峰值线程请求率可达 1720 个请求/秒；
    • 65.5% 的请求数落在平均值±标准差的区间内。
20657 requests in 10.03s, 5.12MB read
Requests/sec:   2060.31
Transfer/sec:    523.03KB

含义解释：

  • 总请求数： 20657 次（总共发出了 2 万次 HTTP 请求）；
  • 持续时间： 10.03 秒（略多于设定的 10s，是正常现象）；
  • QPS（Requests/sec）： 2060.31 次/秒，表示你这个 LVS 系统当前的实际处理能力；
  • 带宽： 每秒传输了约 523KB 数据。

✅ 总结评估：

项目 表现
吞吐率 👍 良好，2K QPS（对于 2 连接来说相当不错）
延迟 👍 很低，约 1.37ms
网络传输 👍 正常（以返回页大小计算，说明 Nginx 配置和 LVS 配置正常）
连接数设置 ⚠️ 较低，只有 2 个连接（可以适当提高压测负载）

✅wrr：加权轮询（Weighted Round Robin）

一、清除现有 LVS 配置

[root@nginx1 ~]# ipvsadm -C

这一步会清空当前所有 LVS 虚拟服务和真实服务器的配置。

二、设置 wrr（加权轮询）算法

LVS VIP 是 192.168.152.200:80，后端服务器为：

  • 192.168.152.133（权重高，例如权重 3）
  • 192.168.152.134（权重低，例如权重 1）

👉 添加规则命令：

# 添加虚拟服务，指定调度算法为 wrr
[root@nginx1 ~]# ipvsadm -A -t 192.168.152.200:80 -s wrr

# 添加真实服务器1（高权重）
[root@nginx1 ~]# ipvsadm -a -t 192.168.152.200:80 -r 192.168.152.133 -g -w 3

# 添加真实服务器2（低权重）
[root@nginx1 ~]# ipvsadm -a -t 192.168.152.200:80 -r 192.168.152.134 -g -w 1

说明：

  • -s wrr：使用加权轮询算法；
  • -g：DR 模式（Direct Routing）；
  • -w：设置服务器的权重。

三、确认配置是否生效

[root@nginx1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.152.200:80 wrr
  -> 192.168.152.133:80           Route   3      0          0         
  -> 192.168.152.134:80           Route   1      0          0

测试

[root@localhost wrk]# wrk -t2 -c2 -d10s http://192.168.152.200/
Running 10s test @ http://192.168.152.200/
  2 threads and 2 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.18ms    1.46ms  18.38ms   86.97%
    Req/Sec     1.24k   458.48     2.26k    59.00%
  24693 requests in 10.04s, 6.12MB read
Requests/sec:   2460.68
Transfer/sec:    624.66KB

-t2：使用 2 个线程；

-c2：2 个并发连接（整个测试仅维护两个连接）；

-d10s：测试持续时间为 10 秒；

http://192.168.152.200/：目标是 LVS 的 VIP。

📊 输出解读

Running 10s test @ http://192.168.152.200/
  2 threads and 2 connections

说明测试成功开始，共用 2 个线程、2 个连接。

  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.18ms    1.46ms  18.38ms   86.97%
    Req/Sec     1.24k   458.48     2.26k    59.00%

各字段含义如下：

项目 数值 含义说明
Avg Latency 1.18 ms 每个请求平均响应时间为 1.18 毫秒（很快）
Max Latency 18.38 ms 最慢一次请求耗时 18 毫秒
Req/Sec 平均每线程 1240 次请求/秒（即总 QPS 接近 2480）
Stdev 请求数波动较大（458.48）说明负载不太均衡，可能和 wrr 权重相关 
24693 requests in 10.04s, 6.12MB read
Requests/sec:   2460.68
Transfer/sec:    624.66KB

含义：

  • 总请求数：24,693 次（比之前的 20,657 明显增加）；
  • 总耗时：10.04 秒；
  • QPS（Requests/sec）：约 2460.68；
    • 对比之前 rr 算法测试的 2060 QPS，有小幅上升；
  • 带宽使用：每秒传输 624.66 KB；

✅ 总结：表现良好，略优于 rr

项目 rr（轮询） wrr（加权轮询）
请求总数 20,657 24,693
QPS 2060 2460
延迟 1.37ms 1.18ms（更低）

✅ lc：最少连接（Least Connection）

✅ 一、清除现有 LVS 配置

[root@nginx1 ~]# ipvsadm -C

✅ 二、配置 LVS 使用 lc（Least Connection）算法

👉 添加新的调度规则：

# 添加虚拟服务，设置调度算法为 lc（最少连接）
[root@nginx1 ~]# ipvsadm -A -t 192.168.152.200:80 -s lc

# 添加服务器（权重默认即可）
[root@nginx1 ~]# ipvsadm -a -t 192.168.152.200:80 -r 192.168.152.133 -g
[root@nginx1 ~]# ipvsadm -a -t 192.168.152.200:80 -r 192.168.152.134 -g

说明：

  • -s lc：表示使用最少连接算法；
  • -g：DR 模式（Direct Routing）；
  • 不需要设置权重，lc 自动根据后端连接数动态调度。

✅ 三、确认配置是否正确

[root@nginx1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.152.200:80 lc
  -> 192.168.152.133:80           Route   1      0          0         
  -> 192.168.152.134:80           Route   1      0          0

✅ 四、进行 wrk 压力测试

[root@localhost wrk]# wrk -t2 -c2 -d10s http://192.168.152.200/
Running 10s test @ http://192.168.152.200/
  2 threads and 2 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.37ms    1.58ms  17.45ms   84.12%
    Req/Sec     1.05k   254.46     1.51k    59.50%
  20896 requests in 10.04s, 5.18MB read
Requests/sec:   2080.39
Transfer/sec:    528.15KB

📌 补充说明：lc 算法适用场景

  • 适合连接持续时间不均的应用（如：长连接、请求处理时间差异大）；
  • 不是简单轮流分配，而是根据谁连接数少，就调度给谁。

LVS三种调度算法的总结

✅ 测试的三个 LVS 算法总结如下：

算法 含义 流量分配策略 适用场景
rr 轮询（Round Robin） 每个请求轮流发给后端 后端服务器性能一致、请求处理时间近似
wrr 加权轮询（Weighted RR） 按权重比例调度 一台服务器性能更强或优先处理更多请求
lc 最少连接（Least Connection） 当前连接数最少的服务器优先接收请求 请求处理时间差异大、长连接、非对称负载

📊 实际测试结果对比：

算法 请求总数 QPS（Req/sec） 平均延迟 数据吞吐 备注
rr 20,657 2,060.31 1.37 ms 523.03 KB/s 平均分配，基本稳定
wrr 24,693 2,460.68 1.18 ms 624.66 KB/s 高权重服务器分担更多请求，整体性能提升
lc 20,896 2080.39 2080.39 528.15 根据连接实时分配，适合动态负载场景

📊 性能对比分析

✅ QPS（吞吐性能）：

  • wrr 表现最强：2460 QPS，明显高于其他两种；
  • rr 和 lc 相近：约 2060~2080 QPS；

✅ 延迟：

  • wrr 的 平均延迟最低（1.18ms）；
  • rr 和 lc 平均延迟都为 1.37ms，波动也较稳定；

✅ 吞吐量（数据传输速度）：

  • 同样是 wrr > lc ≈ rr，符合性能排序；