我们来系统性地回答：LVS 四层是否支持会话同步？主备切换能否实现连接不断？
✅ 一、简明结论（面试可用）
标准 LVS + Keepalived 架构中，四层连接无法在主备切换时保持不断。
虽然 LVS 工作在四层（TCP/UDP），但默认情况下 不保存连接状态表的同步机制，主节点宕机后，备节点无法接管"半开连接"，客户端会感知到连接中断。
但是，通过
conn_sync模块（IPVS Sync Daemon） ，可以实现 连接状态同步 ，从而在主备切换时做到 几乎无感的连接恢复（接近"连接不断"）。
✅ 二、LVS 主备架构与连接状态问题
1. 标准 LVS-DR/NAT/TUN 模式
- LVS 调度器（Director）维护一个 连接哈希表（Connection Hash Table）
- 记录每个 TCP 连接的五元组（源IP、源端口、目的IP、目的端口、协议）和对应的后端 Real Server
- 用于实现 会话保持（Persistence） 和 连接跟踪
2. 主备切换时的问题
- 主节点宕机 → 内存中的连接表丢失
- 备节点虽然通过 VRRP 接管 VIP，但 没有连接状态
- 新到达的数据包无法匹配到后端 RS
- 客户端连接中断（收到
RST或超时）
✅ 三、解决方案：conn_sync（连接状态同步）
LVS 提供了 IPVS Connection Sync 机制，通过 ipvsadm 和 keepalived 配置，实现主备节点之间的连接状态同步。
📌 核心组件
| 组件 | 作用 |
|---|---|
ip_vs_sync 内核模块 |
负责序列化连接状态并发送 |
sync daemon（同步守护进程） |
在主节点上运行，将连接表广播给备节点 |
multicast/unicast 网络 |
用于传输同步数据 |
🔧 配置示例（Keepalived + conn_sync）
主节点配置（MASTER）
markdown
conf
深色版本
global_defs {
router_id LVS_MASTER
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {
192.168.1.100/24 dev eth0 label eth0:0
}
}
# 启用连接同步（主节点发送）
virtual_server 192.168.1.100 80 {
delay_loop 6
lb_algo rr
lb_kind DR
protocol TCP
# 启用连接同步
sync_threshold 3 10
persistent_connection # 启用持久连接跟踪
real_server 192.168.1.20 80 {
weight 1
TCP_CHECK {
connect_port 80
connect_timeout 3
}
}
}备节点配置（BACKUP）
markdown
conf
深色版本
vrrp_instance VI_1 {
state BACKUP
priority 90
# ... 其他同主节点
}
# 启用连接同步（备节点接收）
virtual_server 192.168.1.100 80 {
sync_threshold 3 10
persistent_connection
# ... real server 配置
}⚙️ 关键参数说明
| 参数 | 说明 |
|---|---|
persistent_connection |
启用连接持久化跟踪（必须开启） |
sync_threshold |
同步阈值，格式 sync_max wakeup_rate sync_max=3：最多缓存 3 个新连接再同步 wakeup_rate=10：每 10ms 触发一次同步 |
lvs_sync_daemon_interface |
指定同步通信接口（可选） |
✅ 四、连接同步工作原理
css
深色版本
客户端 → [VIP: 192.168.1.100]
↓
[ LVS Master ] ←──────────────┐
│ │
├→ 建立 TCP 连接 │
├→ 记录到 conn_table │
└→ 通过 multicast/unicast │
发送 conn_state │
▼ │
[ LVS Backup ] ←──────────────┘
↑
实时接收连接状态- 主节点每建立一个新连接，就通过 组播或单播 将连接状态发送给备节点
- 备节点将其存入本地连接表
- 当主节点宕机，备节点接管 VIP 后，已有连接可继续处理
- 客户端几乎无感知（可能丢 1~2 个包，TCP 重传恢复）
✅ 五、是否真正"连接不断"？
| 场景 | 是否断连 | 说明 |
|---|---|---|
| 短连接（HTTP/1.1） | 可能丢包，但 TCP 重传恢复 | 用户无感 |
| 长连接（WebSocket、数据库连接） | 基本不断 | 连接状态已同步 |
| 大文件上传/下载 | 可能短暂中断，自动恢复 | 依赖 TCP 重传 |
| 切换瞬间的新连接 | 正常处理 | 新主节点已有完整连接表 |
✅ 所以：不是 100% 不断，但可做到"业务无感"恢复。
✅ 六、限制与注意事项
| 限制 | 说明 |
|---|---|
| 性能开销 | 同步大量连接会增加网络和 CPU 开销 |
| 延迟 | 同步有微秒级延迟，不适合超高频交易 |
| 网络要求 | 主备节点需低延迟、高带宽网络（建议万兆内网） |
| 最大连接数 | 受 sync_threshold 和网络带宽限制 |
| 不支持 UDP 会话保持 | UDP 无连接，难以同步状态 |
✅ 七、对比 Nginx 主备
| 特性 | LVS + conn_sync | Nginx + Keepalived |
|---|---|---|
| 工作层级 | 四层（TCP/UDP） | 七层（HTTP） |
| 连接状态同步 | ✅ 支持（conn_sync） |
❌ 不支持 |
| 主备切换是否断连 | ⚠️ 几乎不断（TCP 可恢复） | ❌ 断连 |
| 适用场景 | 高并发 TCP 服务（如数据库、游戏） | Web 服务（可配合客户端重试） |
✅ 八、面试常见问题 & 回答
Q1：LVS 主备切换能不断连接吗？
答 ： 默认不能。但通过启用
persistent_connection和sync_threshold，可以实现连接状态同步，使备节点在接管后能继续处理原有连接，达到"业务无感"的效果。
Q2：conn_sync 是实时同步的吗？
答 ： 是准实时的。通过
sync_threshold控制同步频率，通常延迟在毫秒级，足够应对大多数场景。
Q3：为什么 Nginx 不能同步连接而 LVS 可以？
答 ： 因为 LVS 工作在四层，内核级维护连接表，可通过
ip_vs_sync模块同步； Nginx 工作在七层，连接状态在用户态，且无内置同步机制，难以实现。
✅ 总结
| 问题 | 回答 |
|---|---|
| LVS 四层会话可以同步吗？ | ✅ 可以，通过 conn_sync 模块 |
| 主备切换连接不断吗？ | ⚠️ 不是绝对不断，但可做到 TCP 层自动恢复，业务无感 |
| 如何配置？ | 启用 persistent_connection + sync_threshold |
| 适用场景 | 高可用 TCP 服务（如 MySQL、Redis、游戏服务器） |
💡 金句收尾 ： "LVS 通过
ip_vs_sync实现了四层连接状态的主备同步，是少数能在主备切换时接近'无损'的开源方案。它弥补了 Keepalived 仅漂移 IP 的不足，真正实现了四层负载均衡的高可用。"
掌握这个知识点，说明你对 LVS 的理解远超普通运维，极具竞争力。