Linux高可用常见面试题

𝑴𝒓.𝑳𝒊𝒖𝒄𝒚原创2026/2/7面试题Linux高可用常见面试题约 2261 字大约 8 分钟...

1、高可用的核心设计原则？

┌─────────────────────────────────────────┐
│         消除单点故障（SPOF）             │
│    任何组件都有备份，故障时自动切换        │
├─────────────────────────────────────────┤
│         冗余设计（Redundancy）           │
│    主备、主主、集群多节点部署             │
├─────────────────────────────────────────┤
│         故障自动检测与恢复                │
│    心跳检测、健康检查、自动故障转移        │
├─────────────────────────────────────────┤
│         负载均衡（Load Balancing）        │
│    流量分发，避免单节点过载               │
└─────────────────────────────────────────┘

2、脑裂（Split-Brain）是什么？如何解决？

项目	说明
现象	集群中多个节点同时认为自己是主节点
危害	数据冲突、双写导致数据丢失
原因	网络分区、心跳中断、仲裁机制失效

解决方案：

# 1. 仲裁机制（Quorum）
#    节点数必须 > 总节点数/2，否则拒绝服务
#    例如：5节点集群，至少3个节点存活

# 2. Fencing（隔离）
#    STONITH（Shoot The Other Node In The Head）
#    强制关闭故障节点电源

# 3. 奇数节点设计
#    避免平票，如3节点、5节点

3、keeplived 工作原理是什么，使用的是什么协议？

┌─────────┐         VRRP协议          ┌─────────┐
│  Master │  ←────────────────────→  │  Backup │
│ 优先级100│    组播224.0.0.18         │ 优先级90 │
│ 持有VIP │                         │ 待命    │
└────┬────┘                         └────┬────┘
     │                                   │
     └──────────→ VIP: 192.168.1.100 ←───┘
                  （虚拟IP，对外服务）

keepalived 使用的是VRRP(虚拟路由冗余)协议，主服务器会向从服务器发送VRRP报文，通知从服务器主服务器存活，此时VIP存在于主服务器上；当从服务器接收不到主服务器发送的VRRP报文时，判断主服务器宕机，此时VIP漂移至从服务器，并且接替主服务器工作；

4、keeplived 有哪些模块？并说下他们各自的作用

答：keepalived主要有三个模块，分别是core、check和vrrp

core模块为keepalived的核心，负责主进程的启动、维护及全局配置文件的加载和解析。
vrrp模块是虚拟路由冗余协议，实现VIP漂移。
check负责健康检查，常见的方式有端口检查及URL检查。

答：虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip（该路由器所在局域网内其他机器的默认路由为该vip），master会发组播，当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。

6、简述LVS的工作模式及其工作过程？

答：LVS 有三种负载均衡的模式，分别是VS/NAT（nat 模式）、VS/DR（路由模式）、VS/TUN（隧道模式）。

# NAT模式（VS-NAT）

原理：首先负载均衡器接收到客户的请求数据包时，根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后负载均衡器就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址（RIP）。真实服务器响应完请求后，查看默认路由，把响应后的数据包发送给负载均衡器，负载均衡器在接收到响应包后，把包的源地址改成虚拟地址（VIP）然后发送回给客户端。

优点：集群中的服务器可以使用任何支持TCP/IP的操作系统，只要负载均衡器有一个合法的IP地址。

缺点：扩展性有限，当服务器节点增长过多时，由于所有的请求和应答都需要经过负载均衡器，因此负载均衡器将成为整个系统的瓶颈。

# IP隧道模式（VS-TUN）

原理：首先负载均衡器接收到客户的请求数据包时，根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后负载均衡器就把客户端发送的请求报文封装一层IP隧道（T-IP）转发到真实服务器（RS）。真实服务器响应完请求后，查看默认路由，把响应后的数据包直接发送给客户端，不需要经过负载均衡器。

优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，也能处理很巨大的请求量。

缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持“IP Tunneling”。

# 直接路由模式（VS-DR）

原理：首先负载均衡器接收到客户的请求数据包时，根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后负载均衡器就把客户端发送的请求数据包的目标MAC地址改成后端真实服务器的MAC地址（R-MAC）。真实服务器响应完请求后，查看默认路由，把响应后的数据包直接发送给客户端，不需要经过负载均衡器。

优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，也能处理很巨大的请求量。

缺点：需要负载均衡器与真实服务器RS都有一块网卡连接到同一物理网段上，必须在同一个局域网环境。

7、Nginx vs LVS vs HAProxy 对比？

特性	Nginx	LVS	HAProxy
层级	7层（应用层）	4层（传输层）	4层/7层
性能	高（万级并发）	最高（百万级）	高（十万级）
功能	反向代理、静态服务、缓存	纯负载均衡	专业负载均衡
健康检查	被动+主动	需配合Keepalived	主动，更精细
会话保持	ip_hash/sticky	persistence	cookie/source
适用	Web服务、动静分离	大规模流量入口	数据库、TCP服务

8、MySQL 高可用方案有哪些？

方案	原理	切换方式	适用场景
主从复制	binlog异步复制	人工切换	读写分离，非高可用
MHA	主从+Manager管理	自动故障切换	传统MySQL高可用
MGR	组复制，Paxos协议	自动	MySQL 5.7+，推荐
InnoDB Cluster	MGR+MySQL Router	自动	官方完整方案
Galera	同步多主复制	自动	Percona/MariaDB

MHA架构：

┌─────────┐     主从复制      ┌─────────┐
│  Master │ ←──────────────→ │  Slave1 │
│ (写节点) │                  │(读节点/备主)│
└────┬────┘                  └────┬────┘
     │                            │
     └──────────→ ┌─────────┐ ←───┘
                  │ MHA Node│（监控+数据备份）
                  │ MHA Manager│（故障检测+切换）
                  └─────────┘

9、Redis 高可用方案？

方案	架构	数据一致性	适用
主从复制	一主多从	异步，可能丢失	读写分离
Sentinel	主从+哨兵监控	最终一致	自动故障转移
Cluster	分片集群，无中心	异步	大规模数据

Sentinel原理：

# 3个Sentinel节点监控主从集群
┌─────────┐    ┌─────────┐    ┌─────────┐
│ Sentinel│ ←→ │ Sentinel│ ←→ │ Sentinel│
│   1     │    │   2     │    │   3     │
└────┬────┘    └────┬────┘    └────┬────┘
     │              │              │
     └──────────────┼──────────────┘
                    ↓
              ┌─────────┐
              │  Master │
              └────┬────┘
                   │
              ┌────┴────┐
           ┌──┐       ┌──┐
        Slave  Slave  Slave

关键配置

# sentinel.conf
sentinel monitor mymaster 127.0.0.1 6379 2    # 2个Sentinel同意才判定故障
sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判定下线
sentinel failover-timeout mymaster 60000       # 故障转移超时60秒

10、设计一个高可用的Web架构？

┌─────────────────────────────────────────┐
│              接入层（DNS/CDN）           │
│    智能DNS + CDN静态加速 + WAF防护        │
├─────────────────────────────────────────┤
│              负载层（LVS/HAProxy）       │
│    LVS-DR + Keepalived双机热备           │
├─────────────────────────────────────────┤
│              网关层（Nginx/OpenResty）    │
│    反向代理 + 限流 + 缓存 + SSL卸载       │
├─────────────────────────────────────────┤
│              应用层（无状态服务）          │
│    Nginx/PHP/Java多节点 + 健康检查        │
├─────────────────────────────────────────┤
│              数据层                      │
│    MySQL MGR主从 + Redis Cluster + ES    │
├─────────────────────────────────────────┤
│              存储层                      │
│    分布式文件系统（Ceph/MinIO/OSS）       │
├─────────────────────────────────────────┤
│              运维监控层                   │
│    Prometheus + Grafana + ELK + 告警      │
└─────────────────────────────────────────┘

11、高可用架构中的常见问题及解决方案都有哪些？

问题	现象	解决方案
脑裂	双主冲突，数据不一致	仲裁机制 + Fencing
数据延迟	主从复制延迟，读不到最新数据	强制读主 + 半同步复制
会话保持	用户登录后跳到另一台服务器	Session共享（Redis）+ Sticky Session
雪崩效应	一个服务故障引发连锁反应	熔断降级（Hystrix/Sentinel）+ 限流
热点数据	某个Key访问量过大	本地缓存 + Key打散

12、LVS与Nginx做负载均衡的优缺点？

LVS做四层负载，nginx七层负载（四层）
LVS只针对流量进行分发，不需要考虑后端应用；nginx只能做web和mail的负载均衡；
LVS的负载调度算法比nginx负载调度算法多；
LVS只能做前端负载，nginx还可以做WEB服务和缓存；
LVS没有节点健康检查，nginx可以自动剔除宕机节点；
LVS负载能力比nginx强；
nginx支持正则匹配，根据内容进行分发，LVS不支持；