如何设计系统高可用，避免单点故障？比如负载均衡、主从复制、集群部署。

1) 【一句话结论】系统高可用设计需通过多维度冗余（硬件、网络、服务）、负载均衡分散流量、主从复制保障数据一致性、集群部署实现服务容错，共同避免单点故障。

2) 【原理/概念讲解】
老师：咱们先讲核心概念，系统高可用本质是“冗余+容错”。

• 负载均衡（LBA）：核心是分发网络请求到多个后端服务器，避免单台服务器过载。类比：交通枢纽（如北京站）分发旅客到不同站台，减少单站压力。
• 主从复制：主节点处理写请求，从节点同步数据，主节点故障时从节点切换为主。类比：银行账本（主账本）和分账本（从账本），主账本更新后同步到分账本，保证数据一致性。
• 集群部署：多个服务实例部署在不同节点，某个节点故障时其他实例接管。类比：团队协作（如项目组），一人请假，其他人继续工作。

3) 【对比与适用场景】

技术	定义	核心特性	典型使用场景	注意点
负载均衡	分发网络请求到多个后端服务器	均衡流量、提高吞吐量、故障切换	Web服务器、API网关	会话粘性配置、算法选择（轮询/加权）
主从复制	主节点处理写，从节点同步数据	数据一致性、读写分离	数据库（MySQL、MongoDB）、缓存（Redis）	同步延迟、主从切换成本
集群部署	多个服务实例部署在不同节点	服务冗余、故障转移	微服务架构、分布式系统	通信成本、状态同步、资源管理

4) 【示例】

• 负载均衡（Nginx）：

  upstream backend {
      server 192.168.1.1:8080;
      server 192.168.1.2:8080;
      server 192.168.1.3:8080;
      # round-robin 轮询
  }
  server {
      listen 80;
      server_name example.com;
      location / {
          proxy_pass http://backend;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
      }
  }
  

• 主从复制（MySQL）：

  # 主节点配置
  [mysqld]
  server_id=1
  log_bin=/var/log/mysql/mysql-bin.log
  binlog_format=row
  
  # 从节点配置
  [mysqld]
  server_id=2
  log_bin=/var/log/mysql/mysql-bin.log
  replicate_host=192.168.1.1
  replicate_user=repl
  replicate_password=secret
  replicate_port=3306
  

• 集群部署（微服务）：用户服务部署在3个节点，通过负载均衡访问，数据库主从复制保障数据，服务间通过Kafka异步通信。

5) 【面试口播版答案】
面试官您好，关于系统高可用设计，核心思路是通过多维度冗余来避免单点故障。首先，负载均衡通过分发请求到多台服务器，避免单台过载，比如用Nginx轮询多个后端实例。其次，主从复制保障数据一致性，主节点写数据，从节点同步，比如MySQL主从架构，主节点故障时从节点切换。最后，集群部署通过多实例冗余，某个节点故障时其他实例接管，比如微服务架构中多个服务实例部署在不同机器。三者结合，从流量分发、数据同步、服务冗余三个层面提升高可用性。

6) 【追问清单】

• 问题1：负载均衡的算法选择（如轮询、加权轮询、最少连接）如何影响性能？
  回答要点：加权轮询适合资源不均的服务器，最少连接适合长连接场景。
• 问题2：主从复制中，主从切换的延迟如何处理？
  回答要点：可通过半同步复制或双主复制减少延迟，或设置主节点健康检查。
• 问题3：集群部署中，服务间的通信如何保证高可用？
  回答要点：通过消息队列（如Kafka）解耦，保证异步通信的高可用。
• 问题4：硬件层面的冗余（如双电源、双网卡）是否属于系统高可用设计？
  回答要点：硬件冗余是基础，但软件层面的设计更重要，两者结合。
• 问题5：如何评估系统的高可用性指标（如SLA）？
  回答要点：通过监控和故障转移时间来衡量，如99.9%或99.99%的SLA。

7) 【常见坑/雷区】

• 忽略会话粘性导致用户状态丢失。
• 主从复制延迟导致数据不一致。
• 集群部署中服务间通信故障导致服务雪崩。
• 负载均衡算法选择不当导致资源分配不均。
• 未考虑网络单点故障（如单网关）。