Docker Compose中间件集群自动恢复需健康检查、重启策略与启动依赖控制协同实现：健康检查须反映真实业务状态并设start_period；重启策略依中间件特性差异化配置；依赖启动必须基于service_healthy而非容器启动。
要让 Docker Compose 编排的中间件集群具备自动恢复能力，关键不是靠“监控+人工干预”，而是通过健康检查 + 重启策略 + 启动依赖控制三层协同实现故障感知与自动响应。下面从配置逻辑、实战要点和常见陷阱三方面说清楚。
健康检查必须反映真实业务状态
只检查进程是否存活远远不够。比如 Redis 容器进程在，但内存满载、无法响应命令，或 PostgreSQL 进程运行中，但连接池耗尽、拒绝新连接——这类“假活”状态必须被识别。
推荐做法：
- 对 Redis：用
redis-cli ping或redis-cli info | grep loading判断是否就绪且未加载中 - 对 PostgreSQL：用
pg_isready -U postgres -d mydb检查连接可用性及数据库可访问性 - 对 Kafka：调用
kafka-broker-api或检查curl -s http://localhost:9092/actuator/health（若启用了 Spring Boot Actuator） - 所有健康检查需设置
start_period（如 60s），给中间件留出初始化时间，避免启动阶段误判为失败
重启策略要匹配中间件特性
不同中间件对重启的容忍度和恢复逻辑差异很大，不能一概用 always：
-
Redis / Kafka Broker：适合
unless-stopped。它们是无状态或日志追加型服务，崩溃后重启即可快速恢复；宿主机重启后也应自动拉起 -
PostgreSQL / MySQL：建议
on-failure:3。数据库异常退出往往意味着数据损坏或配置错误，盲目无限重启可能掩盖问题；限制最多重试 3 次，再失败就停住并告警 -
ZooKeeper 集群节点：慎用
always。单节点反复重启可能引发脑裂或会话混乱，应配合外部仲裁或使用on-failure+ 日志分析定位根因
依赖启动顺序必须靠 healthcheck 驱动
depends_on 默认只等容器“启动成功”（即 ENTRYPOINT 进程 running），但中间件真正就绪往往慢得多。必须升级为基于健康状态的等待：
示例（PostgreSQL 启动后，应用才启动）：
services:
db:
image: postgres:15
environment:
POSTGRES_DB: appdb
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d appdb"]
interval: 15s
timeout: 5s
retries: 5
start_period: 90s
<p>app:
image: myapp:latest
depends_on:
db:
condition: service_healthy # 关键：等 db 健康检查通过才启动
这样能避免应用启动时连不上数据库报错退出，继而触发不必要的重启循环。
补充建议：轻量级兜底自愈（Autoheal）
如果部署环境较简单（如单机测试/边缘场景），且部分中间件未内置健康检查，可引入 willfarrell/autoheal 作为补充：
- 它会定期扫描所有容器，对状态为
unhealthy的自动执行docker restart - 通过标签控制范围，例如只监控带
autoheal=true标签的中间件容器 - 不替代原生健康检查，而是作为第二道防线，防止健康检查配置遗漏或失效
