Docker Compose 的 restart 参数用于定义容器生命周期管理策略，包括 no、always、on-failure 和 unless-stopped 四种类型。文章详细解析了各策略在容器异常退出、系统重启及手动停止场景下的行为差异，探讨了退出码对重启决策的影响以及 Docker 守护进程状态的作用。此外，结合生产环境案例，介绍了数据库持久化配置、健康检查机制以及与日志组件配合实现高可用自愈架构的最佳实践，帮助开发者提升服务稳定性与容错能力。
Docker Compose 提供了一套灵活的容器生命周期管理机制，其中重启策略（restart policy）是确保服务高可用性的核心组成部分。通过在 docker-compose.yml 文件中配置 restart 字段，用户可以定义容器在不同场景下的自动重启行为，从而提升应用的容错能力与稳定性。
Docker Compose 支持以下几种常见的重启策略：
以下是一个使用 always 重启策略的典型服务配置：
version: '3.8'
services:
web:
image: nginx:alpine
restart: always
ports:
- "80:80"
上述配置中，restart: always 表示即使宿主机重启或容器异常退出，Docker 都会尝试重新启动该容器，适用于需要长期运行的关键服务。
Docker 的重启决策由守护进程（daemon）负责，而非 Docker Compose CLI。当容器停止后，Docker 守护进程会根据 restart 策略判断是否拉起容器。这一机制独立于 docker-compose up 命令的执行周期，具有持久性。
| 策略 | 异常退出时重启 | 系统重启后重启 | 手动停止后是否重启 |
|---|---|---|---|
| no | 否 | 否 | 否 |
| always | 是 | 是 | 是 |
| unless-stopped | 是 | 是 | 否 |
| on-failure | 是（仅失败） | 是（仅失败） | 否 |
graph TD
A[Container Stops] --> B{Check Restart Policy}
B -->|no| C[Do Not Restart]
B -->|always| D[Restart Container]
B -->|on-failure| E{Exit Code ≠ 0?}
E -->|Yes| D
E -->|No| C
B -->|unless-stopped| F{Manually Stopped?}
F -->|No| D
F -->|Yes| C
在系统配置中，no 作为默认策略通常表示禁用某项功能或关闭特定行为。该策略适用于对稳定性要求高、需最小化外部干扰的生产环境。
[feature]
auto_backup = no
debug_mode = no
上述配置明确关闭自动备份与调试模式，适用于正式上线的服务节点，避免冗余操作影响系统负载。
| 策略 | 含义 | 适用环境 |
|---|---|---|
| no | 关闭功能 | 生产环境 |
| yes | 启用功能 | 开发/测试 |
在 Kubernetes 中，restartPolicy: Always 确保 Pod 中的容器无论因何原因退出，都会被自动重启。这一策略适用于长期运行的服务型应用，如 Web 服务器或消息队列。
apiVersion: v1
kind: Pod
metadata:
name: nginx-always
spec:
restartPolicy: Always
containers:
- name: nginx
image: nginx:latest
上述配置中，restartPolicy 设置为 Always，表示只要容器终止，kubelet 就会立即重启它。该策略不关心退出码，始终触发重启。
| 场景 | 是否推荐 Always | 说明 |
|---|---|---|
| Web 服务 | ✅ 推荐 | 需持续可用，异常退出应立即恢复 |
| 批处理任务 | ❌ 不推荐 | 应使用 OnFailure 或 Never |
在容器化部署中，on-failure 重启策略允许服务在非零退出码时有条件地重启，适用于短暂异常恢复。
restart: on-failure:5
该配置表示容器仅在失败时重启，最多尝试 5 次。超过次数后将停止重启，便于故障排查。
此策略适用于批处理任务或阶段性运行的服务，结合日志系统可精准定位第几次失败原因，提升运维效率。
在容器化服务管理中，unless-stopped 是 Docker 容器重启策略的一种关键模式，确保容器在宿主机重启后自动恢复运行，除非被手动停止。
{
"RestartPolicy": {
"Name": "unless-stopped",
"MaximumRetryCount": 0
}
}
该配置常用于生产环境的长期运行服务。当 Docker 守护进程启动时（如系统重启），所有处于'暂停但未停止'状态的容器将自动恢复运行，保障服务连续性。
适用于数据库、消息队列等需持久运行的核心服务，在保证高可用的同时，保留管理员手动终止的控制权。
在分布式系统中，异常恢复策略往往依赖关键参数的取值设定。不同的配置可能引发截然不同的恢复路径和系统表现。
// 配置 A：固定间隔重试
config := RetryConfig{
MaxRetries: 3,
ReconnectInterval: time.Second * 2,
BackoffEnabled: false,
}
该配置在短暂网络中断后能快速恢复，但在持续故障下会频繁尝试连接，增加服务压力。
// 配置 B：启用指数退避
config := RetryConfig{
MaxRetries: 5,
ReconnectInterval: time.Second,
BackoffEnabled: true, // 每次延迟翻倍
}
此方案在面对持久性异常时更温和，避免雪崩效应，但恢复延迟较高。
| 配置类型 | 恢复速度 | 系统压力 | 适用场景 |
|---|---|---|---|
| 固定间隔 | 快 | 高 | 瞬时故障 |
| 指数退避 | 慢 | 低 | 网络震荡 |
容器的退出码是决定其是否需要重启的关键依据。Kubernetes 等编排系统根据退出码判断容器终止原因，并结合重启策略（RestartPolicy）做出响应。
apiVersion: v1
kind: Pod
spec:
containers:
- name: app
image: nginx
restartPolicy: OnFailure # 仅在非 0 退出时重启
当 restartPolicy 设为 OnFailure 时，系统检测到非 0 退出码将自动重启容器；而 Always 则无论退出码如何均重启。
| 退出码 | 含义 | OnFailure 行为 |
|---|---|---|
| 0 | 成功退出 | 不重启 |
| 1 | 应用错误 | 重启 |
| 137 | 被 SIGKILL 终止 | 重启 |
Docker 守护进程（dockerd）的运行状态直接影响容器的生命周期管理。当系统重启或服务异常终止时，守护进程是否自动恢复取决于其配置和宿主机的初始化系统。
可通过以下命令查看 Docker 守护进程状态：
systemctl status docker
该命令输出包含服务活跃状态、PID、内存占用及最近日志，用于判断守护进程是否正常运行。
Docker 服务在以下场景会触发重启：
systemctl restart docker 命令通过修改 /etc/docker/daemon.json 可增强稳定性：
{
"live-restore": true
}
启用 live-restore 后，即使守护进程重启，正在运行的容器仍保持运行状态，避免业务中断。
在 Kubernetes 等容器编排系统中，生产环境的故障恢复依赖于重启延迟（restartDelay）与重试次数（retryCount）的隐式策略。这些参数虽未显式暴露于配置文件，但由控制器内部逻辑自动推导。
控制器通常采用指数退避算法控制重启频率，避免雪崩效应。例如：
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: app-container
image: nginx
restartPolicy: Always
上述配置中，restartPolicy: Always 触发 kubelet 隐式执行重试。首次失败后延迟 10 秒，随后依次为 20 秒、40 秒，上限至 5 分钟。
该机制保障了资源稳定与快速恢复之间的平衡。
在高可用 Web 服务架构中，合理的重启策略能有效避免服务雪崩并提升系统自愈能力。通过配置智能的 restart policy，可确保容器或进程在异常时快速恢复。
services:
web:
image: nginx:latest
restart: unless-stopped
depends_on:
- db
该配置确保 Web 服务在宿主机重启或崩溃后自动拉起，适用于生产环境长期运行的服务。其中 unless-stopped 避免了手动停机维护时的意外重启。
| 场景 | 推荐策略 |
|---|---|
| 生产 Web 服务 | unless-stopped |
| 调试任务 | on-failure |
数据库容器在重启过程中可能面临数据丢失、连接中断和服务不可用等风险，尤其是在未配置持久化存储或未正确管理生命周期时。
version: '3'
services:
mysql:
image: mysql:8.0
volumes:
- db_data:/var/lib/mysql # 持久化数据卷
environment:
MYSQL_ROOT_PASSWORD: example
volumes:
db_data: # 声明命名卷，避免数据随容器删除而丢失
通过命名卷（named volume）将数据目录挂载到宿主机，确保即使容器重建，数据仍可保留并重新挂载。
添加健康检查可避免服务未就绪即被接入流量：
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 10s
timeout: 5s
retries: 3
该配置确保数据库完全启动后才标记为健康，降低重启后立即访问失败的概率。
在高可用日志系统中，确保日志收集组件具备无状态重启能力是保障数据不丢失的关键。通过将采集位点（如文件偏移量）持久化到外部存储，组件重启后可从上次记录位置恢复。
使用轻量级键值存储记录每个日志源的读取偏移：
{
"log_source": "/var/log/app.log",
"inode": 123456,
"offset": 204800
}
该结构以文件 inode 和 offset 作为断点续传依据，避免因路径相同但文件轮转导致重复读取。
在容器化部署中，通过组合健康检查与重启策略可构建具备自愈能力的系统。Kubernetes 提供就绪（readiness）和存活（liveness）探针，结合合适的 restartPolicy，能自动恢复异常实例。
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3
restartPolicy: Always
上述配置表示每 10 秒检测一次应用健康状态，启动后等待 30 秒开始首次检查。若连续 3 次失败，Kubelet 将重启容器。参数 initialDelaySeconds 避免应用未初始化完成被误判；periodSeconds 控制检测频率，平衡资源消耗与响应速度。
应用启动 → 健康检查通过 → 服务正常运行 → 检查失败 → 触发重启 → 重建实例恢复服务
该机制显著提升系统可用性，尤其适用于无状态服务的故障自动恢复场景。
在生产环境中部署微服务时，服务发现与健康检查机制必须协同工作。例如，使用 Consul 作为注册中心时，应配置定期的健康探测：
Check {
HTTP = "http://localhost:8080/health"
Interval = "10s"
Timeout = "2s"
}
这能确保故障实例被快速剔除，降低请求失败率。
统一日志格式是实现高效排查的前提。推荐使用结构化日志，如 JSON 格式输出，并包含关键字段：
结合 ELK 栈可实现集中式检索与告警。
某电商平台在大促期间遭遇数据库连接耗尽问题。通过调整 HikariCP 参数解决：
| 参数 | 原值 | 优化后 |
|---|---|---|
| maximumPoolSize | 20 | 50 |
| connectionTimeout | 30000 | 10000 |
| idleTimeout | 600000 | 300000 |
同时启用慢查询日志，定位并优化执行时间超过 500ms 的 SQL。
将安全检测嵌入 CI 流程可显著降低漏洞风险。使用 OWASP ZAP 在流水线中自动扫描：
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online
将JSON字符串修饰为友好的可读格式。 在线工具，JSON美化和格式化在线工具，online