nacos高可用集群需三节点以上、raft选主、共享mysql持久化、前端负载均衡接入及客户端缓存降级。核心是不宕机、不丢数、不乱配，缺一不可。
微服务配置中心高可用集群不是靠堆机器，而是靠分层设计和关键机制协同工作。核心目标就三个：不宕机、数据不丢、配置不乱。下面从最实际的落地角度讲清楚怎么做。
多节点集群 + Raft 选主保障服务不中断
单点配置中心是生产环境红线，必须至少部署 3 个 Nacos 节点（推荐奇数，如 3 或 5），节点间通过 Raft 协议自动选举主节点、同步状态。 - 主节点负责写入（如新增配置、发布变更）和部分元数据管理 - 所有节点都可响应客户端读请求（配置拉取、服务发现查询） - 当前主节点宕机时，剩余节点在几秒内完成重新选举，新主接管，客户端无感知（配合负载均衡器） - 注意：所有节点必须能互相访问 9848（gRPC 同步端口）和 9849（Raft 选举端口），网络不通会导致脑裂或集群分裂统一持久化存储避免配置丢失
Nacos 内置的嵌入式数据库仅限单机测试，生产必须对接外部 MySQL（5.7+，建议主从架构）。 - 创建共享数据库（如 `nacos_config`），执行官方 `tables_nacos.sql` 初始化表结构 - 所有 Nacos 节点共用同一套数据库连接参数（URL、用户名、密码） - 配置项 `spring.datasource.platform=mysql` 和 `db.num=1` 必须显式设置 - 数据库本身做高可用（如 MySQL MHA 或云数据库的高可用版），否则 DB 挂了，整个集群就退化为只读甚至不可用客户端接入层必须加负载均衡
客户端不能直连某一台 Nacos 实例，否则节点故障即断连。正确方式是： - 在集群前端部署稳定入口：物理机用 Nginx / HAProxy，K8s 环境用 Service + Ingress 或 LoadBalancer 类型 Service - 客户端配置指向这个统一地址（如 `http://nacos-prod:8848`），由负载均衡器做健康检查与流量分发 - Spring Cloud Alibaba 默认支持该模式，只需配置 `spring.cloud.nacos.config.server-addr=nacos-prod:8848` - 不推荐客户端自己做轮询或随机选节点——无法感知节点真实健康状态，容易把请求打到已失联但未下线的实例容错与降级不能只靠集群本身
高可用不只是服务端的事，客户端也要有兜底能力： - 开启本地缓存：Nacos Client 默认会在 `~/nacos/config/` 下缓存已加载的配置，重启或短暂断连时可降级使用 - 配合 `@RefreshScope` + `/actuator/refresh` 实现配置热更新，避免每次改配置都重启服务 - 关键业务可叠加配置快照（Snapshot）机制或引入 Apollo 的 Namespace 分级灰度能力，防止误操作全量推送 - 监控必须覆盖：集群节点状态（`/nacos/v1/console/server/state`）、Raft 角色（LEADER/FOLLOWER）、MySQL 连接数、配置变更推送成功率不复杂但容易忽略。
