高可用是大型架构核心，下面我详解99.99%高可用架构@mikechen
流量入口高可用
流量入口是用户访问的第一站，一旦挂掉，后续所有服务都不可达。
多入口 + 负载均衡：DNS + L4/L7 LB（SLB / LVS / Nginx），避免单点。
DNS ↓ L4/L7 LB（多活） ↓ 应用集群
Keepalived + LVS/Nginx： 通过 虚拟 IP (VIP) 技术，两台负载均衡器组成主备（Active-Standby）模式。
利用 Keepalived 检测心跳，一旦主节点宕机，备节点瞬间接管 VIP。
云原生方案： 使用云厂商提供的 SLB（负载均衡服务），通常自带跨可用区（AZ）的高可用能力。
应用层高可用
应用层，通常是无状态的（Stateless），因此高可用实现相对简单，重点在于扩展性与自愈力。
集群化部署（Horizontal Scaling）： 至少部署两个以上的实例，通过负载均衡进行分发。
健康检查（Health Check）： 负载均衡器实时监测应用存活状态，自动剔除故障实例。
限流、熔断与降级：
熔断（Circuit Breaker）： 当下游服务崩溃时，及时切断调用，防止雪崩。
降级（Fallback）： 核心功能受损时，保证基本功能可用（如：不显示推荐位，只显示搜索）。
多可用区部署： 实例分布在不同的机房机架或数据中心。
中间件高可用
中间件（消息队列、缓存）作为系统的“粘合剂”，通常依赖分布式协议保障可用性。
缓存高可用（Redis）： 哨兵模式（Sentinel）： 自动监控主从状态并执行故障转移。
集群模式（Cluster）： 数据分片存储，无中心化架构，任何节点故障不影响整体运行。
消息队列高可用（Kafka/RocketMQ）：
多副本机制： 消息写入多个 Broker，通过 Leader-Follower 选举机制。若 Leader 宕机，Follower 自动升级，确保消息不丢失且服务不中断。
数据层高可用
数据是系统的核心资产，高可用设计在保障可用性的同时，必须兼顾数据一致性。
主从切换（Master-Slave）： 半同步复制： 确保至少有一个从库收到数据再返回成功，防止主库宕机导致数据丢失。
自动仲裁（MHA/Orchestrator）： 自动监测主库存活。一旦故障，选出最佳从库并自动修改所有应用的连接指向。
双主多活/异地多活： 最极致的方案。在两个地域同时写入数据，通过数据同步组件（如 Canal/DTS）解决冲突。
分布式数据库： 如 TiDB，原生支持三副本存储和 Raft 协议，单点故障对业务完全透明。
mikechen睿哥
10年+一线大厂架构实战经验，就职于阿里、淘宝等一线大厂，操盘多个亿级大厂核心项目。