可靠发布专题 07｜服务重启时，什么应该继续、什么应该停止

导语：在系统发布或运维场景里，服务重启并不是单纯的“关掉再开”。正确划定重启边界，决定哪些组件可以继续运行、哪些必须暂停，是降低故障面、保证数据一致性与可恢复性的关键。本文面向有工程实践经验的读者，围绕 Web、worker、scheduler 与数据服务的启动顺序，给出可操作的判断原则、建议顺序与落地步骤，并指出常见误区。

基本判断原则：以可恢复性和一致性为界

在决定某个组件重启时，应把关注点回归到两个核心目标：保证数据不会丢失（或能被可靠恢复）、保证系统能在可接受时间内恢复到一致状态。基于这两点，可以形成几条判断线：

• 写操作相关的服务优先保证后端持久层可用或可回放。若写请求会直接落到数据库或持久化队列上，后端必须在可用或能回放的状态之前不允许新写入。
• 短暂无害的读操作在后端可用前可以有限放行，但必须保证不会导致缓存污染或错误的业务决策（例如错误的缓存写入策略）。
• 异步 worker 消费需要考虑幂等性与任务可重入，若任务不可幂等则在后端或队列不稳定时应停止消费。
• 调度器（scheduler）负责触发新的作业或任务，它的暂停窗口通常比单个 worker 更长，因为调度器触发会产生新的负荷并可能引入重复执行风险。

这些原则在落地时，会被转换为“哪些应该继续运行、哪些应该停止”的明确操作：保持只读、暂停调度、阻止外部流量、drain-in-flight 等。

推荐的启动与停止顺序（常见场景）

下面给出一种常见且保守的停止/启动顺序，适用于需要保证持久性和一致性的互联网后端服务（单体或微服务结合消息队列的架构）。实际场景需结合业务弹性和 SLA 调整。

停止（从对外层到核心的顺序）：
1. 先停止外部流量：将负载均衡器（或 ingress）中的实例从流量池移除，前端不再接收新请求。保持现有连接的优雅关闭（drain）。
2. 暂停调度器：停止产生新任务或定时作业，防止在后端切换期间生成新的异步负载。
3. 停止 worker 消费：在确保没有正在处理的关键事务或在确认任务可中止/重试的前提下，worker 执行 drain，等待当前任务完成或移动未完成任务回队列。
4. 停止 application 写入：若应用可以切换到只读模式，应先禁写防止 schema 变更或不一致的数据写入到后端。
5. 关闭或降级缓存与消息代理（视情况而定）：对于依赖消息代理的操作，确保消息持久化与复制完成；对于缓存，可选择保留或清空，取决于缓存一致性策略。
6. 最后停止数据库或核心数据服务（仅在必须时，例如做底层升级或重启集群节点）。

启动（逆向）：
1. 启动数据库与核心数据服务，等待达成健康与副本同步/达成 quorum。
2. 启动消息代理与持久化队列（确保持久化配置生效并与存储同步）。
3. 启动 worker，开启消费但一般先采用有限并发或观察期，以便发现问题时快速回退。
4. 启动调度器并逐步恢复定时任务的触发频率或开启少量任务。
5. 恢复应用写入并逐步增加流量，最后把实例放回负载均衡池。

该顺序的逻辑是：先保证能够持久化和回放数据的基础设施可用，再恢复会生成持久化事件的消费者与触发器，最后恢复对外服务。

可操作的重启边界与步骤清单

下面列出可直接执行的检查点和操作步骤，便于在运维 runbook 中落地。

1. 健康检查与 readiness/liveness 区分
   - 确保负载均衡使用 readiness 来决定是否发送新流量，liveness 仅用于检测死锁或崩溃重启。
   - 在重启前，把实例设置为 not-ready，使得流量被逐步转移走。

2. Drain 而非直接 kill
   - Web 层：等待正在进行的请求完成，限制新请求进入。合理设置超时，避免被长时间挂起的连接拖死整个发布。
   - Worker：优先 finish 当前任务或将任务放回队列，避免中断会话或产生半完成状态。

3. Pause 调度器（Scheduler）
   - 对于 CronJob 或 Airflow 一类工具，重启窗口内应暂停任务触发，避免在基础设施尚未就绪时产生任务堆积或重复执行。

4. 验证持久化与副本同步
   - 对于数据库和消息队列，检查复制、持久化配置与落盘状态。Redis 这类缓存若用作持久化队列，需要关注持久化文档与 RDB/AOF 配合策略（参见 Redis Persistence 文档）。
   - 对于 Celery 或其他异步框架，确认 broker（如 RabbitMQ/Redis）与 backend 的可靠交付特性，并参考相应文档安排消费策略（参考 Celery 文档）。

5. 控制流量恢复节奏
   - 先以小流量恢复，观察错误率、队列长度和延迟指标，再逐步放大。
   - 对关键路径设置临界报警，恢复过程中出现回归时能快速切回维护模式。

6. 处理 schema 变更与迁移
   - 大幅的 schema 变更应在服务可以兼容双写双读或按阶段回滚的前提下进行。重启并非迁移的替代方案；在迁移窗口里，应确保所有消费者与生产者遵守兼容策略。

在任何发布/重启场景中，先保证“能恢复的最小基线”再开放新的工作负荷；越早允许产生持久化写入，回退成本越高。

常见误区与容易犯的错误

• 误区一：只靠 liveness probe 即可。把重启逻辑完全交给 liveness 通常会在重启时丢失优雅下线的机会，导致请求被中断或任务半完成。应使用 readiness 进行流量排空。
• 误区二：认为缓存可以随意丢弃。很多系统把缓存作为性能关键路径，但重启清空缓存可能触发缓存穿透、雪崩或误导业务逻辑。必须在恢复时控制缓存预热与落地策略。
• 误区三：worker 容忍所有任务重试。任务不幂等或对外部系统产生副作用时，盲目重试会造成重复扣款、重复通知等严重问题。在这种场景下，重启时应停止消费并手动审查未完成任务。
• 误区四：忽视消息代理的持久化与复制。部分团队把消息代理当作瞬时传递层，重启时没有确认消息持久化导致丢单。必须核查 broker 的持久化策略以及重启后队列状态（参见 Celery 与 Redis 文档以理解各自的持久语义）。
• 误区五：单节点思维。在分布式数据库或代理中，单节点重启可能破坏 quorum，引发故障转移或写入中断。重启计划需考虑集群拓扑与副本分布。

操作演练与监控指标建议

要把重启策略变成可执行的 runbook，建议做以下演练与指标设定：

• 计划性演练：在非高峰期进行演练，模拟不同组件失效或重启，记录恢复时间、错误率和数据一致性检查结果。
• 指标与告警：设置关键指标包括队列长度、未完成任务数、写入错误率、数据库复制延迟、缓存命中率与服务健康率，针对每项设置分级告警。
• 回滚触发条件：定义明确的回滚阈值，例如 5 分钟内错误率上升 3 倍或队列长度增长超过基线 2 倍即触发回滚。
• 文档化恢复步骤：包括如何检查消息是否丢失、如何手动重放任务、如何回退 schema 变更等，避免在紧急情况下手足无措。

延伸阅读

• Celery Documentation: https://docs.celeryq.dev/en/stable/
• Redis Persistence Documentation: https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/