异步消息处理业务容器停止需确保“完成当前消息+拒收新消息+安全退出”：必须让应用进程为pid 1（用exec或tini），注册sigterm处理逻辑暂停拉取、等待提交offset并设超时，同时调大docker/k8s停止宽限期，并配合mq手动ack与预停机接口。
异步消息处理业务（如消费 kafka、rabbitmq 或 rocketmq 消息）对容器停止特别敏感：若在处理中强行终止，易导致消息重复、丢失或状态不一致。配置合理的停止策略，核心是“给够时间完成当前消息 + 拒绝新消息 + 安全退出”，而非简单等待超时。
确保信号能传到应用主进程
很多消息消费者用 shell 启动（如 CMD sh -c "java -jar consumer.jar"），此时 shell 占据 PID 1，会拦截 SIGTERM，应用收不到。必须让消费者进程直接作为 PID 1：
- 改用 exec 格式启动：
CMD ["java", "-jar", "consumer.jar"] - 若需环境准备（如 chmod、生成配置），用轻量 init 工具（如 tini）：
ENTRYPOINT ["/sbin/tini", "--"]，再接 CMD - 验证方式：进容器执行
ps -o pid,comm，确认 java / node / python 进程 PID 是 1
应用层注册消息处理的优雅关闭逻辑
不能只等 HTTP server 关闭——消息消费者没有请求入口，关键在消息循环和确认机制：
- 收到 SIGTERM 后立即停止拉取消息（如 Kafka consumer 调用
consumer.pause()或关闭 poll 循环） - 等待当前正在处理的消息完成并成功提交 offset（如
consumer.commitSync()） - 设置合理超时（如 60 秒），超时未提交则记录告警并强制退出，避免无限挂起
- Go 示例：用
context.WithTimeout包裹 commit 操作；Java Spring Boot 可用@EventListener(ContextClosedEvent.class)触发清理
调整 Docker 停止超时与编排参数
默认 10 秒远不够处理一条重逻辑消息。需按业务最大单条耗时 × 安全冗余倍数来设：
- Docker CLI：
docker run --stop-timeout=90 ... - Docker Compose：
stop_grace_period: 90s（写在 service 下） - Kubernetes：
terminationGracePeriodSeconds: 90，且确保 readinessProbe 在收到信号后快速失败（如健康检查返回 503），防止新消息路由进来 - 注意：
terminationGracePeriodSeconds应 ≥stop_timeout，否则 K8s 会提前强杀
配合消息中间件的可靠性机制
容器停机只是环节之一，需端到端协同：
- Kafka：启用
enable.auto.commit=false，手动控制 offset 提交时机；消费者组 re-balance 时自动触发 graceful shutdown 流程 - RabbitMQ：使用 manual ack，shutdown 前确保所有 unack 消息已处理并
basic.ack - 加一层“预停机”标记：服务暴露
/actuator/stop-consume接口，运维先调用它暂停消费，再发docker stop，双重保险
