docker compose本身不提供跨主机高可用，但可通过healthcheck、命名卷和service_healthy依赖实现单机环境下的服务韧性、数据韧性与依赖韧性，为生产级编排奠定可验证配置基线。
要让容器化应用真正“扛得住”，关键不是堆机器，而是设计好服务间的协作关系、数据持久性、故障响应和弹性边界。Docker Compose 本身不提供跨主机调度或自动故障转移，但它能为你搭建一个结构清晰、可复现、易调试的本地高生存性集群基础——这是生产级编排（如 Swarm 或 Kubernetes）前最关键的验证层。
明确“高生存能力”在 Compose 中的实际含义
在单机 Compose 环境下，“高生存能力”主要体现在三方面：服务不因单点崩溃而整体失效、关键数据不随容器销毁丢失、组件异常时有明确恢复路径。它不等于“高可用”（HA），但为 HA 提供了可验证的配置基线。
- 服务韧性：通过 healthcheck 定义存活探针，配合 restart_policy 让容器在进程退出后自动重启（如 restart: unless-stopped）
- 数据韧性：所有有状态服务（MySQL、Redis、PostgreSQL 等）必须使用命名卷（named volume）或绑定宿主机路径，避免用 anonymous volume
- 依赖韧性：用 depends_on + condition: service_healthy 强制等待上游服务就绪，而不是仅靠启动顺序
用 healthcheck 和 restart 策略兜住基础运行
默认情况下，Compose 启动容器后就认为它“已就绪”，但实际数据库可能还在初始化、应用可能还没连上中间件。不加健康检查，上游服务一启动就发请求，大概率失败。
- 为 MySQL 服务添加健康检查：healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"]
timeout: 20s
retries: 10
start_period: 30s - 搭配 restart 策略：restart: on-failure:3（失败最多重试 3 次）或 restart: unless-stopped（除非手动停，否则始终拉起）
- 注意：depends_on 不会等 healthcheck 通过，必须显式写 condition: service_healthy 才生效
用命名卷 + 初始化脚本保障数据不丢
容器删了，数据还在，这才是“生存”的底线。匿名卷（anonymous volume）在 docker-compose down 后会被自动清理；而命名卷（如 db-data）默认保留。
- 定义命名卷：volumes:
- db-data:/var/lib/mysql
volumes:
db-data: - 首次启动时，MySQL 会自动初始化并生成数据文件；后续重启直接加载已有数据
- 如需预置 SQL 或用户权限，把 .sql 文件放入 init 目录，挂载到 /docker-entrypoint-initdb.d/，MySQL 启动时自动执行
模拟多节点协同：主从、读写分离与降级逻辑
真正的生存能力来自架构冗余。Compose 虽不能自动切换主库，但可以静态定义主从拓扑，让应用层具备 fallback 能力。
- 定义两个 MySQL 服务：mysql-master 和 mysql-slave，通过 replication 配置建立主从关系（需自定义镜像或 entrypoint 脚本）
- 应用连接字符串中同时列出两个地址，并启用 read-only fallback（如 JDBC 的 allowPublicKeyRetrieval=true&autoReconnect=true）
- 用 nginx 或 haproxy 做简易 TCP 层负载均衡，监听 3306，后端指向 master 和 slave，配置健康检查自动剔除离线节点
