节点宕机如何可用

“节点宕机如何可用”通常指在分布式系统（如 Kubernetes、微服务、数据库集群、消息队列等）中，当某个节点不可用（宕机、断网、故障）时，系统如何继续保持服务可用。核心思路是冗余 + 自动故障转移 + 健康探测。下面按常见场景说明。

一、通用原则

1. 无单点（SPOF）：关键组件至少 2 个副本
2. 健康检查：定时探测节点/服务状态
3. 自动切换：故障节点被剔除，流量转移
4. 数据一致性：根据业务选 CP 或 AP

二、不同场景下的“节点宕机如何可用”

1. Kubernetes 节点宕机

• Pod 多副本 + 反亲和

  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels: { app: nginx }
          topologyKey: kubernetes.io/hostname
  

• 节点 NotReady → 控制器重新调度 Pod 到其他节点
• 使用 Deployment / StatefulSet 保证副本数
• 存储用 PV（远程存储，如 NAS、云盘），避免本地盘丢失

✅ 结果：节点宕机，Pod 自动漂移到健康节点

2. 微服务（Spring Cloud / Dubbo / gRPC）

• 注册中心（Nacos / Eureka / ZooKeeper）
  • 节点宕机 → 注册中心剔除实例
• 客户端负载均衡（Ribbon / LoadBalancer）
  • 自动选健康实例
• 熔断降级（Sentinel / Hystrix）
  • 节点失败 → 快速失败或走降级逻辑

✅ 结果：请求不打到宕机节点

3. 数据库节点宕机

MySQL

• 主从复制 + 哨兵/Orchestrator
• 主宕机 → 从库提升为主
• 应用通过 VIP / Proxy（MyCat、ProxySQL）访问

Redis

• 哨兵模式 / Cluster
• 主节点宕机 → 哨兵选新主
• 客户端自动感知

Elasticsearch

• 多副本（replicas ≥ 1）
• 节点宕机 → 分片重新分配

✅ 结果：写/读不中断（短暂切换）

4. 消息队列（Kafka / RocketMQ）

• 多 Broker + 多副本
• ISR 机制保证数据不丢
• 消费者组重平衡

✅ 结果：节点宕机，消息仍可生产消费

5. 负载均衡层

• L4/L7 负载均衡（Nginx、HAProxy、SLB）
• 后端节点健康检查
• 节点宕机 → 不参与转发

✅ 结果：用户无感知

三、典型高可用架构示例

用户
 ↓
SLB（多可用区）
 ↓
K8s 节点A  节点B  节点C
 ↓
数据库主从 + 哨兵
 ↓
远程存储 PV

四、常见误区

❌ 只部署单节点
❌ 本地磁盘存重要数据
❌ 无健康检查
❌ 故障后人工介入慢

五、一句话总结

节点宕机不可怕，怕的是“只有一个节点”和“没有自动转移能力”。

如果你指的是某一具体系统（如 K8s、MySQL、Redis、Kafka、自研服务），可以告诉我，我给你更针对性的方案。