高可用的核心是消除单点故障而非防御——需对服务层无状态化、数据库启用半同步复制、基础设施跨可用区部署，并确保监控链路冗余。
单点故障无法“防住”，只能“消除”——所有依赖单一实例的组件，必须被设计成可替换、可伸缩、可自动恢复的冗余单元。
服务层必须做无状态拆分
有状态的服务（比如直接在本地磁盘存 session、用单机 Redis 缓存用户登录态）天然就是单点。一旦机器宕机，连接断开、数据丢失、会话失效，用户立刻感知到故障。
- HTTP 服务要剥离 session：改用
JWT或把 session 存到独立的Redis 集群（不是单节点），并配置readReplicas和sentinel或Redis Cluster模式 - 应用进程本身不能存关键状态：比如订单处理中缓存在内存里的支付结果，必须落库或发消息到
Kafka/RocketMQ，由下游消费幂等处理 - 部署至少 2 个实例，并通过
nginx或ALB做健康检查 + 自动摘除（检查路径如/health，返回 200 才转发）
数据库高可用不能只靠主从切换
MySQL 主从延迟大、切换过程可能丢事务、VIP 切换有 DNS 缓存问题——这些都会导致“看似高可用，实则不可用”。
- 避免应用直连
master地址：用中间件如ShardingSphere-Proxy或DBRouter统一管理读写分离和故障转移逻辑 - 主从同步必须开启
semi-sync，并设置rpl_semi_sync_master_timeout=1000（单位毫秒），防止主库卡死时写请求无限阻塞 - 定期压测
failover流程：模拟主库宕机，验证从库升主耗时是否在30s内，且应用重连后不报Connection refused或Unknown database
基础设施层要规避隐性单点
很多人做了多可用区部署，却忘了负载均衡器、DNS 解析、配置中心这些“看不见的枢纽”也是单点。
-
SLB或ALB必须跨可用区部署，且后端目标组绑定的实例要打上AvailabilityZone标签，避免健康检查误判 - DNS 不要用单家服务商：
Cloudflare+阿里云云解析双线配置，TTL 设为60，故障时手动切权重 -
Nacos/Consul集群至少 3 节点，且必须部署在不同物理机或不同Availability Zone；客户端 SDK 要启用failFast=false和重试逻辑，别一连不上就崩
真正的高可用不是堆机器，而是让每个环节都回答一个问题：“它挂了，系统还能不能走通关键路径？”——这个判断比任何架构图都重要。最容易被忽略的是监控告警链路本身：如果 Prometheus 实例单点运行，又没配 remote_write 到长期存储，故障期间你根本不知道哪块出了问题。
