核心在于数据库层主从+代理实现读写分离与微服务层适配：主从容器需独立配置、挂载数据卷，ProxySQL统一路由SQL类型；微服务连接代理地址，规避强一致性读问题，并通过volumes、restart等保障状态持久与自愈。
用 Docker Compose 部署具备读写分离特性的有状态微服务集群，核心在于两层协同：一是数据库层实现主从结构与读写流量分发，二是微服务层适配该结构并保障状态一致性。它不是单纯堆叠容器，而是围绕“数据可分、访问可路由、故障可收敛”来组织服务依赖。
数据库层：用主从容器+代理实现读写分离
MySQL 或 PostgreSQL 主从复制必须通过多个容器明确区分角色（如 mysql-master、mysql-slave-1、mysql-slave-2），不能靠单个镜像启动多实例自动形成复制关系。你需要：
- 为每个数据库节点配置独立的
my.cnf（或postgresql.conf），启用 binlog / wal、设置 server-id、配置复制用户 - 在
docker-compose.yml中通过volumes挂载配置和数据目录，确保重启后状态不丢失 - 引入中间件代理（如 ProxySQL 或 MaxScale）作为统一入口，监听一个端口，按 SQL 类型（SELECT vs INSERT/UPDATE）自动路由到从库或主库
- 代理容器需通过
depends_on和健康检查（healthcheck）等待主从就绪后再启动，避免启动时连接失败
微服务层：代码与配置适配读写分离语义
微服务本身不直接感知主从，但必须配合底层架构做适配：
- 数据库连接地址统一指向代理服务名（如
proxysql:6033），而非具体 MySQL 容器名 - 业务代码中避免强依赖“刚写即读”——写操作后立刻查同一记录，可能因主从延迟读到旧值；必要时加
/*+ FORCE_MASTER */注释（ProxySQL 支持）或改走主库专用连接池 - 若使用 Spring Boot，可通过
AbstractRoutingDataSource在应用内做简单读写分离，但更推荐交由 ProxySQL 统一管控，降低服务复杂度 - 所有微服务（user-service、order-service 等）配置中的数据库地址、Nacos 地址都必须写成 Compose 中定义的服务名（如
mysql→ 实际是proxysql），不能写localhost或 IP
状态管理：确保有状态组件可恢复、可伸缩
有状态不仅指数据库，还包括缓存、注册中心等：
- Nacos 或 Eureka 若启 Standalone 模式，需挂载
data卷并设置PERSISTENCE=true，否则重启丢服务列表 - Redis 主从建议用
redis:alpine+redis.conf显式配置slaveof，或直接上 Redis Cluster 模式（需至少 6 个节点，Compose 可用scale快速拉起） - 各微服务自身的本地状态（如文件上传临时目录、日志归档路径）应通过
volumes挂载宿主机目录或命名卷，避免容器销毁后数据丢失 - 使用
restart: unless-stopped保证异常退出后自动恢复，对有状态服务尤为重要
部署与验证关键点
启动后不能只看容器是否 running，要验证实际链路是否生效：
- 进 ProxySQL 容器执行
mysql -uadmin -padmin -h127.0.0.1 -P6032，查stats_mysql_query_digest确认 SELECT 被分发到 slave，DML 走 master - 手动停掉
mysql-master，观察 ProxySQL 是否自动剔除主节点并触发告警；再启一个新主库，确认能否被自动发现或人工重配 - 调用微服务写接口后，立即查从库（绕过 ProxySQL 直连
mysql-slave-1），验证主从延迟在可接受范围内（通常 - 用
docker-compose logs -f userservice观察启动日志，确认成功连接 Nacos 和数据库，无Connection refused或UnknownHostException
