什么是优雅停机？服务发布时，正在处理的请求怎么办？

知识点详解：进程退出之前，哪些工作还没有结束？

先看一个被直接切断的请求

假设接口正在生成报告，已经从数据库取完数据，准备把文件保存下来。这时发布脚本直接终止进程。

用户可能只收到连接断开，但服务端到底做到哪一步，并不清楚。如果任务已经产生了部分结果，重试还可能再次执行。

所以，停机不能只看“进程已经消失”。要看哪些任务还在执行，以及系统能不能判断它们的结果。

摘流量与停止接单，是两层控制

负载均衡不再给实例分配新流量，负责的是入口分发。应用拒绝接受新的任务，负责的是实例自己的工作边界。

流量配置需要传播，已有连接也可能继续存在。仅修改健康状态，不一定能让所有路径立即停止发请求。

应用可以进入 draining 状态，不再接收新的业务任务，同时让已接收任务完成。不同服务器对连接与新请求的处理方式不同，尤其是长连接和多路复用协议，不能只按“关一个端口”理解。

这个过程要和负载均衡、服务发现及探针规则配合。让实例不可接收新流量，不代表立刻把它当成需要强制重启的故障进程。

为什么资源要最后关闭？

正在执行的请求，可能还需要数据库、缓存和外部连接。如果先关连接池，再等请求结束，请求就失去了完成工作的条件。

合理顺序通常是停止接收新任务、等待在途任务、关闭资源、退出进程。后台线程、定时任务和消息消费者，也要进入同一套生命周期管理，不能 HTTP 已经停了，后台还不断创建新工作。

Spring Boot 的 优雅停机文档 说明了支持的服务器与生命周期行为，也提供了阶段等待时间配置。其他运行时需要按实际服务器核对，不能把某个框架的默认行为套到所有应用。

超时任务应该怎么处理？

平台通常只给进程一段退出时间，超过以后会强制结束。应用的收尾时间，需要给资源关闭和最后退出留出余量。

例如平台总窗口是三十秒，应用不能把整整三十秒都用于等待请求，再开始关资源。这个数字只是解释预算关系，实际设置要根据平台与任务时长确定。

对能取消的任务，传递取消信号并保存必要状态；对需要可靠恢复的长任务，可以拆成可重试步骤，或者交给持久化任务系统。生成报告这样耗时较长的工作，也未必适合一直占着同步 HTTP 请求。

“优雅”表示尽量有序，并不保证所有任务都能在任何情况下完成。

消费消息时，最怕哪两种顺序？

第一种是先确认消息，再执行业务。进程中途退出，消息已经被确认，工作却没做完。

第二种是业务完成，但还没来得及确认就退出。队列可能重投，业务会再执行一次。

因此停机时要停止接收新消息，让在途处理走完正常确认流程。处理未完成的消息按队列协议释放或等待重投，业务本身做幂等。不能承诺只靠一个停机钩子，就能获得所有系统的恰好一次执行。

怎样验证，而不是只写一个信号监听？

准备慢请求、长连接和正在执行的消费任务，在它们运行时触发真实退出流程。

检查新工作是否继续进入、旧任务是否有机会完成、等待是否受限、资源是否正确关闭。再主动让某个任务超过窗口，验证中断后的重试或恢复。

测试还要经过真实入口。只在应用内部调用关闭函数，看不到负载均衡传播和平台强制结束带来的影响。

面试官继续追问

收到 SIGTERM 后睡十秒，可以吗？

固定等待可以配合入口传播，但不能代替跟踪在途任务。有的请求已经完成，有的十秒后仍未结束，单纯睡眠不知道区别。

WebSocket 要等连接自然断开吗？

如果连接可能长期存在，就需要应用协议告知迁移、关闭连接或恢复会话。不能无限等待，也不能假设所有长连接都能按短请求处理。

优雅停机能保证发布不丢数据吗？

不能单独保证。事务、消息确认、幂等和恢复机制决定业务可靠性，停机流程只是减少可控中断的一部分。

面试速记卡

• 先停止新工作，再等待在途任务，最后释放资源。
• 入口摘流量和应用拒绝新任务，需要配合。
• 连接池别早于依赖它的任务关闭。
• 应用收尾窗口要小于平台总退出预算。
• 消费消息按完成情况确认，重投仍需要业务幂等。
• 用真实入口与超时任务验证退出流程。