简介一个进程常驻与优先级控制的Android工程探索包包含csdnactivity与servicelive1两个独立模块适合对系统服务机制感兴趣的中高级开发者研究。内容覆盖守护进程模式、服务管理器注册、启动脚本设置及第三方工具等常见保活方案并涉及Linux nice值、Windows优先级类等调度策略对理解服务生命周期和资源管控具有参考价值。压缩包共69个文件其中Java源码20个、图片素材20个、XML配置18个、AIDL接口2个以及gradle、proguard等构建配置和jar依赖整体约16.9MB目录结构清晰便于按模块分析。已有319人在CSDN学习下载。借助源码、界面截图和跨进程通信示例读者可以对照实现自己的进程管理方案同时了解内存占用、系统兼容性等实际落地问题。1. 进程常驻不是 nohup 挂后台先分清“跑起来”和“守得住”不少开发者第一次接触“进程常驻”是在远程服务器上跑一个采集脚本关掉终端后发现数据停了重跑又报“端口被占用”。问题不在脚本逻辑而在“进程跟随终端退出、失控后无人拉起”。进程常驻的本质是让一个进程脱离会话长期运行并且随时能被管控、崩溃后能被拉回而“内含多个module”则是在解决另一个问题进程一旦活得久、任务多就不能再写成一个几万行的单文件必须拆成可独立加载、可单独启停、能互相通信的多个模块。这篇文章面向的是写后台服务、数据采集、消息处理或自研网关的开发者读完你能得到一套可直接落地的常驻框架主进程负责信号与生命周期module负责具体业务中间靠注册表和事件总线解耦最后还能应对“进程假死、模块崩溃、日志爆盘”这些真实翻车场景。这套方案不依赖任何第三方重型框架用标准库就能搭起来。2. 主进程骨架信号响应与退出码是你最先要写对的东西大部分常驻进程翻车不是业务代码写得差而是“退出机制”没定清楚。进程常驻进程常驻核心是“活着的时候能干活该退的时候退得干净挂了之后有人能把它拉起来”。这三件事分别对应信号处理、优雅退出和退出码语义。我在搭这类框架时第一件事不是写业务module而是先把主进程的骨架定好。2.1 常驻进程的三个基础前台运行、信号接管与退出码常见的做法是让进程以“前台模式”运行然后交给 systemd、supervisor 这类进程托管工具来守护而不是自己在代码里做 daemonize 双 fork。原因很实际daemonize 之后进程的输出、日志、标准错误全都脱离标准流排错非常痛苦。前台运行则能让托管工具直接捕获 stdout/stderr日志和状态全归托管方统一管理。这也是容器和云原生环境下更常见的部署姿势。进程一旦被托管就绕不开信号。Linux 下最常处理的三个信号是SIGTERM托管工具通知进程“请优雅退出”这是系统默认的 stop 方式、SIGINT终端 CtrlC、SIGHUP挂断常用作“重新加载配置”的触发信号。我在骨架里会为 SIGTERM 和 SIGINT 注册同一个退出处理函数为 SIGHUP 单独注册一个重载函数。这样运维执行 systemctl stop 或直接 kill 命令时进程能先清理资源再退出而不是立刻暴毙。退出码是另一个容易被忽略的点。托管工具默认根据进程退出码决定要不要重启所以常驻进程必须明确区分0 表示正常退出如人为 stop非 0 表示异常退出如未捕获异常、资源初始化失败需要用不同退出码区分“主动退出”和“被动崩溃”。下面这个表是我常用的退出码约定退出码含义托管工具应对0收到 SIGTERM 后的正常退出不重启1未捕获异常导致崩溃尝试重启2配置校验失败启动即失败不重启等人工介入3关键模块连续失败被熔断等冷却期后重启托管工具拿这个退出来判断是否拉起、多久拉起后重试码错了整个守护策略就乱套了。2.2 最小主进程代码信号、事件循环与 module 启停主进程的职责是加载配置、启动 module、监听信号、在收到退出信号时反向停止 module。下面这个骨架是我常用作新项目起点的小进程框架先不接业务# main.py 常驻进程最小骨架 import signal import sys import time # 从配置读取需要加载的模块名这里先写死演示 MODULES [collector, heartbeat, forwarder] def start_modules(modules: list): 按注册顺序启动模块 for name in modules: try: # 实际实现里这一步是调用模块的 on_create on_start print(f[main] start module: {name}) except Exception as exc: print(f[main] module {name} start failed: {exc}) # 关键模块启动失败要给出明确退出码 sys.exit(2) def stop_modules(modules: list): 逆序停止模块保证依赖方先退、被依赖方后退 for name in reversed(modules): try: print(f[main] stop module: {name}) except Exception as exc: print(f[main] module {name} stop error: {exc}) def handle_signal(signum, frame): SIGTERM/SIGINT 统一走优雅退出 print(f[main] received signal {signum}, start shutdown) stop_modules(MODULES) sys.exit(0) def handle_reload(signum, frame): SIGHUP 触发配置重载不退出进程 print([main] received SIGHUP, reload config) # 这里调用各 module 的 on_reload signal.signal(signal.SIGTERM, handle_signal) signal.signal(signal.SIGINT, handle_signal) signal.signal(signal.SIGHUP, handle_reload) def run(): start_modules(MODULES) while True: # 主循环只做轻量工作检查心跳、刷新配置、处理队列 # 收到退出信号后信号处理函数会抛出 SystemExit循环自然结束 time.sleep(1) if __name__ __main__: run()这里有几个参数值得说明。time.sleep(1)决定主循环的检查频率如果模块之间有毫秒级的心跳或队列要求sleep 要降到 0.1 甚至更小但 CPU 占用会上升大部分常驻服务做到秒级检查就够我一般习惯从 1 秒起步压测时再调小。sys.exit(2)表示“启动失败”与前面退出码表对应托管工具看到 2 就知道不应该立刻拉起。信号处理函数里先停止模块再退出是保证数据库连接、临时文件等资源能被正确释放的关键一步。2.3 用 systemd 托管让退出码变成重启策略代码写对了还得有托管工具来守它。我之前最常用的是 systemd它语法简单、系统自带适合单机部署。下面这段 unit 文件可以直接放到/etc/systemd/system/demo.service使用[Unit] Descriptiondemo resident service Afternetwork.target [Service] Typesimple WorkingDirectory/opt/demo ExecStart/usr/bin/python3 /opt/demo/main.py Restarton-failure RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.targetTypesimple对应前台运行模式表示主进程本身不是守护进程Restarton-failure表示只有非 0 退出码才重启配合前文退出码约定人为 stop退出码 0不会误重启RestartSec5是重启间隔避免崩溃后疯狂拉起耗尽 CPU。PYTHONUNBUFFERED1这个环境变量常被忽略但很重要它让 Python 的 print 输出不打进缓冲否则 systemd 看到的日志可能有延迟甚至缺失。如果用 supervisor等价配置是autostarttrue和autorestarttrue语义类似不再赘述。3. 多 module 的组织方式注册表、生命周期钩子与加载顺序“内含多个module”是从单文件脚本迈向工程化的关键一步。module 拆得好不好看的不是代码量而是生命周期的边界是否清晰谁来加载它、什么时候初始化、什么时候开始跑业务、什么时候释放资源、出问题了谁能把它单独停掉。我在设计时会让每个 module 都继承同一个基类实现固定的钩子方法再由一个注册表统一管理。3.1 先定 Module 的接口生命周期钩子一个常驻进程里的 module至少要具备四个生命周期阶段创建加载配置、启动开始业务、停止释放资源、重载配置变更。我一般会把这些阶段固化成基类方法强制所有 module 按同一套规范实现。下面是基类的示例# module_base.py 定义所有 module 的统一接口 class Module: name base_module requires [] # 依赖的其他模块名用于决定加载顺序 def on_create(self, config: dict): 启动阶段第一步加载配置、建立连接、预创建资源 这个阶段不要启动业务线程只做准备工作 pass def on_start(self, ctx): 启动阶段第二步开始执行业务逻辑 例如开启定时任务、注册事件回调、启动消费线程 pass def on_stop(self): 停止阶段关闭连接、停止线程、清理临时文件 必须是无阻塞或带超时的否则会拖死退出流程 pass def on_reload(self, new_config: dict): 配置重载SIGHUP 触发后逐字段更新 pass把on_create和on_start拆成两步是刻意的。原因在于连接类资源数据库连接池、消息队列客户端建立得越早越好但具体业务投放要等所有模块都创建完毕才安全。如果某个模块在on_create阶段失败主进程可以快速给出失败退出码不用等待业务启动到一半才报错。on_stop必须带超时这条我在后面避坑章节会展开。3.2 模块扫描与注册不硬编码按目录自动发现主进程里写死模块列表只适合 Demo真实服务里 module 会越来越多我一般做法是“目录自动发现 依赖排序”。即把每个 module 放在独立目录中模块管理器扫描目录、加载文件、登记到注册表# loader.py 按目录扫描并注册所有 module import importlib.util import sys from pathlib import Path MODULES_REGISTRY {} def load_modules_from_dir(module_dir: str): 扫描指定目录下的所有 module 文件并注册 module_dir Path(module_dir) for file in module_dir.glob(*.py): if file.name.startswith(_): continue # 跳过 _ 开头的私有/辅助文件 module_name file.stem spec importlib.util.spec_from_file_location(module_name, file) module importlib.util.module_from_spec(spec) sys.modules[module_name] module spec.loader.exec_module(module) if hasattr(module, module): target module.module MODULES_REGISTRY[target.name] target print(f[loader] registered module: {target.name}) def sorted_by_dependency(): 按 requires 字段做简单拓扑排序 保证被依赖的模块先被创建 ordered [] visited set() def visit(name): if name in visited: return visited.add(name) mod MODULES_REGISTRY.get(name) if mod: for dep in mod.requires: visit(dep) ordered.append(name) for name in MODULES_REGISTRY: visit(name) return ordered参数说明glob(*.py)是识别粒度以“一个文件一个 module”为约定目录太深时就要改成递归扫描_开头文件跳过是为了把辅助代码和业务 module 分开sorted_by_dependency里visit是深度优先的拓扑排序保证requires里声明的依赖在前。这比手工维护启动顺序可靠得多新增模块也不需要改主进程代码放进去就自动被发现。3.3 启停顺序的成熟约定创建正序、停止逆序有了依赖排序启停顺序就固定了创建和启动按依赖正序执行停止按依赖逆序执行。这个约定的逻辑是被依赖的模块如配置中心、连接池必须先存在依赖方才能使用停止时则反过来依赖方要先停掉被依赖方才可以安全释放资源。否则会发生“业务模块还在发消息底层连接已经被关了”这种诡异报错。常见的专业做法是增加一个“配置指纹”机制主进程在每次 SIGHUP 后计算配置文件的校验值并和上一次对比只有变了才调用on_reload。这样能避免空重载带来的无用副作用。整条生命周期的对应关系如下表时机主进程动作module 对应方法进程启动扫描注册模块加载文件首次启动按依赖正序执行创建on_create依赖就绪按依赖正序启动业务on_start接收 SIGHUP对比配置指纹on_reload接收 SIGTERM按依赖逆序停止on_stop4. module 之间的通信事件总线比直接调用更好维护多 module 架构里最忌讳的事就是 module A 直接 import module B 的类和方法。短期看着省事一旦模块数量超过五六个依赖会变成一团乱麻你改 B 的接口签名A 和 C 都要跟着改B 崩了A 调用它的地方全部报错。所以我在做多 module 项目时会固定引入一层“事件总线”让模块之间只订阅和发布事件不直接引用对方。4.1 用 30 行实现一个线程安全的事件总线先看代码再讲道理# event_bus.py 一个线程安全的最小事件总线 import threading from collections import defaultdict class EventBus: def __init__(self): self._subscribers defaultdict(list) self._lock threading.Lock() def subscribe(self, event_type: str, handler): 订阅事件handler 是回调函数 with self._lock: self._subscribers[event_type].append(handler) def publish(self, event_type: str, **payload): 发布事件逐个调用订阅者 单个 handler 的异常会被隔离不影响其他订阅者 with self._lock: handlers list(self._subscribers.get(event_type, [])) for handler in handlers: try: handler(**payload) except Exception as exc: # 这里只记录日志不要让订阅者异常扩散到发布者 print(f[event] handler error: {exc})publish里先取出 handlers 再做遍历是为了避免遍历过程中有人修改订阅列表导致运行时错误handler的异常用 try/except 包住是刻意做的“故障隔离”。如果发布方被订阅方拖垮事件总线就会变成另一个单点故障。这个总线我限制了宽度不做通配符匹配、不做事件持久化刚够 module 之间解耦。4.2 什么状态该共享、什么不该共享模块多了之后绕不开“共享状态”问题。我的经验法则很简单只共享不可变数据例如配置、版本号、启动时间连接类是资源不是状态该共用的是“连接池”而不是“某个连接对象”。数据库连接如果多个 module 共用一个连接一个模块慢查询就能把其他模块全部阻塞。常见做法是主进程启动时创建一个连接池对象放入一个只读的上下文ctx里传给每个 module 的on_start每个 module 需要用连接时从池里借用用完归还。可变的业务状态则应该通过事件总线传播而不是用共享字典。例如“采集模块拿到了新数据”就发布一个data.arrived事件处理模块订阅这个事件再做事。这样做的好处是数据来源方从来不知道数据去向新增一个消费者模块不需要改动生产者的代码。我在实际项目中用这个模式做过“采集 → 清洗 → 落地”的三模块链路新增一个审计模块时只添加了订阅代码没动过前两个模块。4.3 模块崩溃了不能拉着主进程陪葬事件总线能隔离调用层面的异常但 module 内部线程抛错、死锁、内存暴涨这类问题总线管不了。我需要让主进程能感知每个 module 是否还“活着”。最可靠也最便宜的手段是心跳每个 module 在业务循环里定期更新自己的心跳时间戳主进程在事件循环里统一检查。超过阈值就认为模块“假死”记一次失败连续失败到达上限就执行单模块重启如果重启也失败就按退出码约定让整个进程重启或者暂时禁用该模块并让相关依赖降级运行。先给出一个心跳检查器的示例# watchdog.py 检查模块心跳超时记录失败次数 import time from collections import defaultdict class Watchdog: def __init__(self, timeout10, max_failures3): self.timeout timeout # 心跳超时阈值单位秒 self.max_failures max_failures self._last_beat {} self._failures defaultdict(int) def beat(self, module_name: str): module 在业务循环里调用这个方法来报平安 self._last_beat[module_name] time.time() def check(self): 主进程每次事件循环调用返回需要重启的模块列表 now time.time() stale [] for name, last in self._last_beat.items(): if now - last self.timeout: self._failures[name] 1 if self._failures[name] self.max_failures: stale.append(name) self._failures[name] 0 else: self._failures[name] 0 return staletimeout10和max_failures3是需要根据业务调的参数心跳间隔越短、timeout 越小检出动越灵敏但误杀概率越大。我一般把 timeout 设为心跳周期的 3 倍以上避免偶发的调度抖动触发误判。“连续失败 3 次才重启”这条缓冲能过滤掉单次的瞬时卡顿让进程更稳定。5. 常驻进程的常见翻车现场日志、守护与资源回收排查这章集中记录我在维护常驻进程时踩过的五个真实坑每条都按“现象 → 原因 → 解决”来整理。这些问题都不是业务逻辑错误而是“进程活得久了才会暴露”的资源与状态问题不排查的时候很难想到。5.1 现象磁盘空间被占满删了日志文件也没用现象经常性磁盘告警用命令删除/var/log下的大日志文件后df显示空间仍然被占用。原因日志轮转工具按计划把日志文件重命名或切割但常驻进程的 stdout/stderr 仍握着旧文件句柄继续向那个“已删除”的 inode 写入数据空间被秘密占满。解决在处理日志轮转时要么让托管工具配置copytruncate要么在进程内部实现“文件被重命名后重新打开”的逻辑。最简单的做法是在 systemd unit 文件里将StandardOutputfile:指向固定路径并让 logrotate 配合 copytruncate更可控的做法是把日志交给进程内的定时器检测当前输出文件的 inode 变化定期重开。之后我再写常驻进程时都会把“日志重开”作为一个定时子任务而不是放任 stdout 一直挂着。5.2 现象kill 掉进程后端口仍被占用重启报 address already in use现象进程崩溃后立刻重启服务报端口被占用等几十秒才恢复。原因进程收到 SIGKILL 强制结束没有机会走优雅退出socket 没有正常关闭仍处于 TIME_WAIT 状态或者孤儿进程没有处理完事件循环就被强杀监听套接字未释放。解决优先保证所有终止都走 SIGTERM 优雅退出避免把kill -9当默认手段同时在初始化网络服务时设置SO_REUSEADDR。排查时先确认到底是 TIME_WAIT 还是另一进程在监听用netstat -tlnp看监听状态即可分辨不要动不动就重启机器。5.3 现象module 升级后运行行为还是旧逻辑现象改了 module 文件重启进程后表现跟旧版一模一样。原因加载器在 Python 的sys.modules里缓存了旧模块对象重新执行文件后对象没有正确替换或者是托管配置里WorkingDirectory指错路径加载了另一个副本。解决实现重载钩子时主动从sys.modules中弹出对应模块再重新走一遍注册流程校验方式上取模块文件内容做哈希和内存中的版本比对不同才执行重载。更隐蔽的是托管配置里的路径错误排查时优先ExecStart是否指向了正确目录再怀疑代码缓存。我把这两条写进每次升级的 checklist手滑概率大幅下降。5.4 现象定时任务半夜偶尔不执行现象进程内的定时任务用绝对时间判断“现在是几点了”来判断触发大部分时间正常偶尔某天整个时段都不触发。原因进程运行在容器或跨时区环境里默认时区不一致更隐蔽的是系统在冬令时/夏令时切换时一天会重复或缺失一小时凡是“每天等一小时”的逻辑都可能错过触发窗口。解决进程内部一律以 UTC 时间计算到展示层再转本地时区触发时刻写成固定时间戳而不是“每小时检查一次现在几点”调度周期用“距上次执行已过 N 秒”而不是“当前分钟等于 0 才执行”可以彻底绕开时区跳变。之后再写常驻任务我都会在配置中心里显式声明timezone: UTC。5.5 现象kill 后进程退出卡住最后只能强杀现象执行 stop 后进程长时间不退出托管工具等到超时再强制杀掉导致下次启动恢复变慢。原因shutdown 流程里存在阻塞调用没有设置超时比如在on_stop里等待某个外部请求返回、等待一个永远不来的线程 join或等待消息队列的 ACK。解决为所有阻塞操作统一加超时启动阶段的超时设长一些停止阶段的超时设短一些线程 join 一律thread.join(timeout)最稳妥的退出流程是先“停止接收新任务”再“等待在途任务”最后“无条件退出”。我把这套顺序固化在基类的on_stop里任何新 module 都不允许覆盖这个结构只能填具体的资源清理逻辑。6. 进阶技巧让进程“带伤运行”的模块级熔断与自恢复走到这里你已经有了主进程、模块注册表、事件总线、心跳看门狗以及一套避坑清单。接下来要解决的是最让人头疼的问题一个模块反复崩溃时如何不拖垮整个常驻进程。进阶点是把“单次失败容忍”升级为“连续失败熔断”并在熔断后具备自恢复能力。6.1 熔断计数与模块自动禁用我在 Watchdog 的基础上为每个 module 维护一个滑动窗口失败计数连续失败达到阈值就触发熔断暂时禁用该模块禁用后不再调用它的on_start同时把它发布的业务降级为“降级响应”。熔断状态要设置冷却期例如 60 秒后自动解除禁用让模块尝试恢复。参数设置参考心跳超时 10 秒、失败阈值 3 次、冷却期 60 秒线上负载高的环境可以把冷却期拉到 300 秒避免频繁重启造成的抖动。6.2 假死检测与单模块重启单模块重启要带着“重置”语义执行不是简单调用on_start而是要完整走on_stop清理旧现场再重新on_create on_start。我在主进程里增加一个restart_module(name)接口内部按依赖逆序停掉该模块及其下游依赖再按依赖正序重新拉起。这里的坑是“重置必须先停干净再建”旧线程没销毁就开新线程轻则泄漏重则直接触发端口冲突。6.3 事件回放与状态补偿模块重启期间它可能错过事件总线上的一些消息直接把数据丢失是不可接受的。我给事件总线加了一个“环形缓冲”副作用每个事件在内存里保留最近 5 分钟数据模块重启成功后先订阅一个replay.request事件由总线把暂停期间错过的事件补发过去。代价是内存占用收益是数据不丢。生产环境里我会按事件类型分组只对关键业务事件做回放非关键事件不做。这套“熔断 单模块重启 事件回放”组合下来我遇到的最大收获是一个采集模块反复崩溃时主进程和转发模块还能持续提供旧数据的查询服务整体从“全挂”降级为“局部牺牲”这个体验差异对运维和用户都很明显。我的习惯是把熔断参数写进配置中心并带上修改记录每次调参都先观察一个完整冷却周期不急着看到立竿见影的效果。希望这篇能帮你在搭建常驻进程时少走几步弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 18:20:39 · 阅读 1.2k 常驻进程守护实战：从信号处理、多模块到崩溃自愈的完整方案
简介一个进程常驻与优先级控制的Android工程探索包包含csdnactivity与servicelive1两个独立模块适合对系统服务机制感兴趣的中高级开发者研究。内容覆盖守护进程模式、服务管理器注册、启动脚本设置及第三方工具等常见保活方案并涉及Linux nice值、Windows优先级类等调度策略对理解服务生命周期和资源管控具有参考价值。压缩包共69个文件其中Java源码20个、图片素材20个、XML配置18个、AIDL接口2个以及gradle、proguard等构建配置和jar依赖整体约16.9MB目录结构清晰便于按模块分析。已有319人在CSDN学习下载。借助源码、界面截图和跨进程通信示例读者可以对照实现自己的进程管理方案同时了解内存占用、系统兼容性等实际落地问题。1. 进程常驻不是 nohup 挂后台先分清“跑起来”和“守得住”不少开发者第一次接触“进程常驻”是在远程服务器上跑一个采集脚本关掉终端后发现数据停了重跑又报“端口被占用”。问题不在脚本逻辑而在“进程跟随终端退出、失控后无人拉起”。进程常驻的本质是让一个进程脱离会话长期运行并且随时能被管控、崩溃后能被拉回而“内含多个module”则是在解决另一个问题进程一旦活得久、任务多就不能再写成一个几万行的单文件必须拆成可独立加载、可单独启停、能互相通信的多个模块。这篇文章面向的是写后台服务、数据采集、消息处理或自研网关的开发者读完你能得到一套可直接落地的常驻框架主进程负责信号与生命周期module负责具体业务中间靠注册表和事件总线解耦最后还能应对“进程假死、模块崩溃、日志爆盘”这些真实翻车场景。这套方案不依赖任何第三方重型框架用标准库就能搭起来。2. 主进程骨架信号响应与退出码是你最先要写对的东西大部分常驻进程翻车不是业务代码写得差而是“退出机制”没定清楚。进程常驻进程常驻核心是“活着的时候能干活该退的时候退得干净挂了之后有人能把它拉起来”。这三件事分别对应信号处理、优雅退出和退出码语义。我在搭这类框架时第一件事不是写业务module而是先把主进程的骨架定好。2.1 常驻进程的三个基础前台运行、信号接管与退出码常见的做法是让进程以“前台模式”运行然后交给 systemd、supervisor 这类进程托管工具来守护而不是自己在代码里做 daemonize 双 fork。原因很实际daemonize 之后进程的输出、日志、标准错误全都脱离标准流排错非常痛苦。前台运行则能让托管工具直接捕获 stdout/stderr日志和状态全归托管方统一管理。这也是容器和云原生环境下更常见的部署姿势。进程一旦被托管就绕不开信号。Linux 下最常处理的三个信号是SIGTERM托管工具通知进程“请优雅退出”这是系统默认的 stop 方式、SIGINT终端 CtrlC、SIGHUP挂断常用作“重新加载配置”的触发信号。我在骨架里会为 SIGTERM 和 SIGINT 注册同一个退出处理函数为 SIGHUP 单独注册一个重载函数。这样运维执行 systemctl stop 或直接 kill 命令时进程能先清理资源再退出而不是立刻暴毙。退出码是另一个容易被忽略的点。托管工具默认根据进程退出码决定要不要重启所以常驻进程必须明确区分0 表示正常退出如人为 stop非 0 表示异常退出如未捕获异常、资源初始化失败需要用不同退出码区分“主动退出”和“被动崩溃”。下面这个表是我常用的退出码约定退出码含义托管工具应对0收到 SIGTERM 后的正常退出不重启1未捕获异常导致崩溃尝试重启2配置校验失败启动即失败不重启等人工介入3关键模块连续失败被熔断等冷却期后重启托管工具拿这个退出来判断是否拉起、多久拉起后重试码错了整个守护策略就乱套了。2.2 最小主进程代码信号、事件循环与 module 启停主进程的职责是加载配置、启动 module、监听信号、在收到退出信号时反向停止 module。下面这个骨架是我常用作新项目起点的小进程框架先不接业务# main.py 常驻进程最小骨架 import signal import sys import time # 从配置读取需要加载的模块名这里先写死演示 MODULES [collector, heartbeat, forwarder] def start_modules(modules: list): 按注册顺序启动模块 for name in modules: try: # 实际实现里这一步是调用模块的 on_create on_start print(f[main] start module: {name}) except Exception as exc: print(f[main] module {name} start failed: {exc}) # 关键模块启动失败要给出明确退出码 sys.exit(2) def stop_modules(modules: list): 逆序停止模块保证依赖方先退、被依赖方后退 for name in reversed(modules): try: print(f[main] stop module: {name}) except Exception as exc: print(f[main] module {name} stop error: {exc}) def handle_signal(signum, frame): SIGTERM/SIGINT 统一走优雅退出 print(f[main] received signal {signum}, start shutdown) stop_modules(MODULES) sys.exit(0) def handle_reload(signum, frame): SIGHUP 触发配置重载不退出进程 print([main] received SIGHUP, reload config) # 这里调用各 module 的 on_reload signal.signal(signal.SIGTERM, handle_signal) signal.signal(signal.SIGINT, handle_signal) signal.signal(signal.SIGHUP, handle_reload) def run(): start_modules(MODULES) while True: # 主循环只做轻量工作检查心跳、刷新配置、处理队列 # 收到退出信号后信号处理函数会抛出 SystemExit循环自然结束 time.sleep(1) if __name__ __main__: run()这里有几个参数值得说明。time.sleep(1)决定主循环的检查频率如果模块之间有毫秒级的心跳或队列要求sleep 要降到 0.1 甚至更小但 CPU 占用会上升大部分常驻服务做到秒级检查就够我一般习惯从 1 秒起步压测时再调小。sys.exit(2)表示“启动失败”与前面退出码表对应托管工具看到 2 就知道不应该立刻拉起。信号处理函数里先停止模块再退出是保证数据库连接、临时文件等资源能被正确释放的关键一步。2.3 用 systemd 托管让退出码变成重启策略代码写对了还得有托管工具来守它。我之前最常用的是 systemd它语法简单、系统自带适合单机部署。下面这段 unit 文件可以直接放到/etc/systemd/system/demo.service使用[Unit] Descriptiondemo resident service Afternetwork.target [Service] Typesimple WorkingDirectory/opt/demo ExecStart/usr/bin/python3 /opt/demo/main.py Restarton-failure RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.targetTypesimple对应前台运行模式表示主进程本身不是守护进程Restarton-failure表示只有非 0 退出码才重启配合前文退出码约定人为 stop退出码 0不会误重启RestartSec5是重启间隔避免崩溃后疯狂拉起耗尽 CPU。PYTHONUNBUFFERED1这个环境变量常被忽略但很重要它让 Python 的 print 输出不打进缓冲否则 systemd 看到的日志可能有延迟甚至缺失。如果用 supervisor等价配置是autostarttrue和autorestarttrue语义类似不再赘述。3. 多 module 的组织方式注册表、生命周期钩子与加载顺序“内含多个module”是从单文件脚本迈向工程化的关键一步。module 拆得好不好看的不是代码量而是生命周期的边界是否清晰谁来加载它、什么时候初始化、什么时候开始跑业务、什么时候释放资源、出问题了谁能把它单独停掉。我在设计时会让每个 module 都继承同一个基类实现固定的钩子方法再由一个注册表统一管理。3.1 先定 Module 的接口生命周期钩子一个常驻进程里的 module至少要具备四个生命周期阶段创建加载配置、启动开始业务、停止释放资源、重载配置变更。我一般会把这些阶段固化成基类方法强制所有 module 按同一套规范实现。下面是基类的示例# module_base.py 定义所有 module 的统一接口 class Module: name base_module requires [] # 依赖的其他模块名用于决定加载顺序 def on_create(self, config: dict): 启动阶段第一步加载配置、建立连接、预创建资源 这个阶段不要启动业务线程只做准备工作 pass def on_start(self, ctx): 启动阶段第二步开始执行业务逻辑 例如开启定时任务、注册事件回调、启动消费线程 pass def on_stop(self): 停止阶段关闭连接、停止线程、清理临时文件 必须是无阻塞或带超时的否则会拖死退出流程 pass def on_reload(self, new_config: dict): 配置重载SIGHUP 触发后逐字段更新 pass把on_create和on_start拆成两步是刻意的。原因在于连接类资源数据库连接池、消息队列客户端建立得越早越好但具体业务投放要等所有模块都创建完毕才安全。如果某个模块在on_create阶段失败主进程可以快速给出失败退出码不用等待业务启动到一半才报错。on_stop必须带超时这条我在后面避坑章节会展开。3.2 模块扫描与注册不硬编码按目录自动发现主进程里写死模块列表只适合 Demo真实服务里 module 会越来越多我一般做法是“目录自动发现 依赖排序”。即把每个 module 放在独立目录中模块管理器扫描目录、加载文件、登记到注册表# loader.py 按目录扫描并注册所有 module import importlib.util import sys from pathlib import Path MODULES_REGISTRY {} def load_modules_from_dir(module_dir: str): 扫描指定目录下的所有 module 文件并注册 module_dir Path(module_dir) for file in module_dir.glob(*.py): if file.name.startswith(_): continue # 跳过 _ 开头的私有/辅助文件 module_name file.stem spec importlib.util.spec_from_file_location(module_name, file) module importlib.util.module_from_spec(spec) sys.modules[module_name] module spec.loader.exec_module(module) if hasattr(module, module): target module.module MODULES_REGISTRY[target.name] target print(f[loader] registered module: {target.name}) def sorted_by_dependency(): 按 requires 字段做简单拓扑排序 保证被依赖的模块先被创建 ordered [] visited set() def visit(name): if name in visited: return visited.add(name) mod MODULES_REGISTRY.get(name) if mod: for dep in mod.requires: visit(dep) ordered.append(name) for name in MODULES_REGISTRY: visit(name) return ordered参数说明glob(*.py)是识别粒度以“一个文件一个 module”为约定目录太深时就要改成递归扫描_开头文件跳过是为了把辅助代码和业务 module 分开sorted_by_dependency里visit是深度优先的拓扑排序保证requires里声明的依赖在前。这比手工维护启动顺序可靠得多新增模块也不需要改主进程代码放进去就自动被发现。3.3 启停顺序的成熟约定创建正序、停止逆序有了依赖排序启停顺序就固定了创建和启动按依赖正序执行停止按依赖逆序执行。这个约定的逻辑是被依赖的模块如配置中心、连接池必须先存在依赖方才能使用停止时则反过来依赖方要先停掉被依赖方才可以安全释放资源。否则会发生“业务模块还在发消息底层连接已经被关了”这种诡异报错。常见的专业做法是增加一个“配置指纹”机制主进程在每次 SIGHUP 后计算配置文件的校验值并和上一次对比只有变了才调用on_reload。这样能避免空重载带来的无用副作用。整条生命周期的对应关系如下表时机主进程动作module 对应方法进程启动扫描注册模块加载文件首次启动按依赖正序执行创建on_create依赖就绪按依赖正序启动业务on_start接收 SIGHUP对比配置指纹on_reload接收 SIGTERM按依赖逆序停止on_stop4. module 之间的通信事件总线比直接调用更好维护多 module 架构里最忌讳的事就是 module A 直接 import module B 的类和方法。短期看着省事一旦模块数量超过五六个依赖会变成一团乱麻你改 B 的接口签名A 和 C 都要跟着改B 崩了A 调用它的地方全部报错。所以我在做多 module 项目时会固定引入一层“事件总线”让模块之间只订阅和发布事件不直接引用对方。4.1 用 30 行实现一个线程安全的事件总线先看代码再讲道理# event_bus.py 一个线程安全的最小事件总线 import threading from collections import defaultdict class EventBus: def __init__(self): self._subscribers defaultdict(list) self._lock threading.Lock() def subscribe(self, event_type: str, handler): 订阅事件handler 是回调函数 with self._lock: self._subscribers[event_type].append(handler) def publish(self, event_type: str, **payload): 发布事件逐个调用订阅者 单个 handler 的异常会被隔离不影响其他订阅者 with self._lock: handlers list(self._subscribers.get(event_type, [])) for handler in handlers: try: handler(**payload) except Exception as exc: # 这里只记录日志不要让订阅者异常扩散到发布者 print(f[event] handler error: {exc})publish里先取出 handlers 再做遍历是为了避免遍历过程中有人修改订阅列表导致运行时错误handler的异常用 try/except 包住是刻意做的“故障隔离”。如果发布方被订阅方拖垮事件总线就会变成另一个单点故障。这个总线我限制了宽度不做通配符匹配、不做事件持久化刚够 module 之间解耦。4.2 什么状态该共享、什么不该共享模块多了之后绕不开“共享状态”问题。我的经验法则很简单只共享不可变数据例如配置、版本号、启动时间连接类是资源不是状态该共用的是“连接池”而不是“某个连接对象”。数据库连接如果多个 module 共用一个连接一个模块慢查询就能把其他模块全部阻塞。常见做法是主进程启动时创建一个连接池对象放入一个只读的上下文ctx里传给每个 module 的on_start每个 module 需要用连接时从池里借用用完归还。可变的业务状态则应该通过事件总线传播而不是用共享字典。例如“采集模块拿到了新数据”就发布一个data.arrived事件处理模块订阅这个事件再做事。这样做的好处是数据来源方从来不知道数据去向新增一个消费者模块不需要改动生产者的代码。我在实际项目中用这个模式做过“采集 → 清洗 → 落地”的三模块链路新增一个审计模块时只添加了订阅代码没动过前两个模块。4.3 模块崩溃了不能拉着主进程陪葬事件总线能隔离调用层面的异常但 module 内部线程抛错、死锁、内存暴涨这类问题总线管不了。我需要让主进程能感知每个 module 是否还“活着”。最可靠也最便宜的手段是心跳每个 module 在业务循环里定期更新自己的心跳时间戳主进程在事件循环里统一检查。超过阈值就认为模块“假死”记一次失败连续失败到达上限就执行单模块重启如果重启也失败就按退出码约定让整个进程重启或者暂时禁用该模块并让相关依赖降级运行。先给出一个心跳检查器的示例# watchdog.py 检查模块心跳超时记录失败次数 import time from collections import defaultdict class Watchdog: def __init__(self, timeout10, max_failures3): self.timeout timeout # 心跳超时阈值单位秒 self.max_failures max_failures self._last_beat {} self._failures defaultdict(int) def beat(self, module_name: str): module 在业务循环里调用这个方法来报平安 self._last_beat[module_name] time.time() def check(self): 主进程每次事件循环调用返回需要重启的模块列表 now time.time() stale [] for name, last in self._last_beat.items(): if now - last self.timeout: self._failures[name] 1 if self._failures[name] self.max_failures: stale.append(name) self._failures[name] 0 else: self._failures[name] 0 return staletimeout10和max_failures3是需要根据业务调的参数心跳间隔越短、timeout 越小检出动越灵敏但误杀概率越大。我一般把 timeout 设为心跳周期的 3 倍以上避免偶发的调度抖动触发误判。“连续失败 3 次才重启”这条缓冲能过滤掉单次的瞬时卡顿让进程更稳定。5. 常驻进程的常见翻车现场日志、守护与资源回收排查这章集中记录我在维护常驻进程时踩过的五个真实坑每条都按“现象 → 原因 → 解决”来整理。这些问题都不是业务逻辑错误而是“进程活得久了才会暴露”的资源与状态问题不排查的时候很难想到。5.1 现象磁盘空间被占满删了日志文件也没用现象经常性磁盘告警用命令删除/var/log下的大日志文件后df显示空间仍然被占用。原因日志轮转工具按计划把日志文件重命名或切割但常驻进程的 stdout/stderr 仍握着旧文件句柄继续向那个“已删除”的 inode 写入数据空间被秘密占满。解决在处理日志轮转时要么让托管工具配置copytruncate要么在进程内部实现“文件被重命名后重新打开”的逻辑。最简单的做法是在 systemd unit 文件里将StandardOutputfile:指向固定路径并让 logrotate 配合 copytruncate更可控的做法是把日志交给进程内的定时器检测当前输出文件的 inode 变化定期重开。之后我再写常驻进程时都会把“日志重开”作为一个定时子任务而不是放任 stdout 一直挂着。5.2 现象kill 掉进程后端口仍被占用重启报 address already in use现象进程崩溃后立刻重启服务报端口被占用等几十秒才恢复。原因进程收到 SIGKILL 强制结束没有机会走优雅退出socket 没有正常关闭仍处于 TIME_WAIT 状态或者孤儿进程没有处理完事件循环就被强杀监听套接字未释放。解决优先保证所有终止都走 SIGTERM 优雅退出避免把kill -9当默认手段同时在初始化网络服务时设置SO_REUSEADDR。排查时先确认到底是 TIME_WAIT 还是另一进程在监听用netstat -tlnp看监听状态即可分辨不要动不动就重启机器。5.3 现象module 升级后运行行为还是旧逻辑现象改了 module 文件重启进程后表现跟旧版一模一样。原因加载器在 Python 的sys.modules里缓存了旧模块对象重新执行文件后对象没有正确替换或者是托管配置里WorkingDirectory指错路径加载了另一个副本。解决实现重载钩子时主动从sys.modules中弹出对应模块再重新走一遍注册流程校验方式上取模块文件内容做哈希和内存中的版本比对不同才执行重载。更隐蔽的是托管配置里的路径错误排查时优先ExecStart是否指向了正确目录再怀疑代码缓存。我把这两条写进每次升级的 checklist手滑概率大幅下降。5.4 现象定时任务半夜偶尔不执行现象进程内的定时任务用绝对时间判断“现在是几点了”来判断触发大部分时间正常偶尔某天整个时段都不触发。原因进程运行在容器或跨时区环境里默认时区不一致更隐蔽的是系统在冬令时/夏令时切换时一天会重复或缺失一小时凡是“每天等一小时”的逻辑都可能错过触发窗口。解决进程内部一律以 UTC 时间计算到展示层再转本地时区触发时刻写成固定时间戳而不是“每小时检查一次现在几点”调度周期用“距上次执行已过 N 秒”而不是“当前分钟等于 0 才执行”可以彻底绕开时区跳变。之后再写常驻任务我都会在配置中心里显式声明timezone: UTC。5.5 现象kill 后进程退出卡住最后只能强杀现象执行 stop 后进程长时间不退出托管工具等到超时再强制杀掉导致下次启动恢复变慢。原因shutdown 流程里存在阻塞调用没有设置超时比如在on_stop里等待某个外部请求返回、等待一个永远不来的线程 join或等待消息队列的 ACK。解决为所有阻塞操作统一加超时启动阶段的超时设长一些停止阶段的超时设短一些线程 join 一律thread.join(timeout)最稳妥的退出流程是先“停止接收新任务”再“等待在途任务”最后“无条件退出”。我把这套顺序固化在基类的on_stop里任何新 module 都不允许覆盖这个结构只能填具体的资源清理逻辑。6. 进阶技巧让进程“带伤运行”的模块级熔断与自恢复走到这里你已经有了主进程、模块注册表、事件总线、心跳看门狗以及一套避坑清单。接下来要解决的是最让人头疼的问题一个模块反复崩溃时如何不拖垮整个常驻进程。进阶点是把“单次失败容忍”升级为“连续失败熔断”并在熔断后具备自恢复能力。6.1 熔断计数与模块自动禁用我在 Watchdog 的基础上为每个 module 维护一个滑动窗口失败计数连续失败达到阈值就触发熔断暂时禁用该模块禁用后不再调用它的on_start同时把它发布的业务降级为“降级响应”。熔断状态要设置冷却期例如 60 秒后自动解除禁用让模块尝试恢复。参数设置参考心跳超时 10 秒、失败阈值 3 次、冷却期 60 秒线上负载高的环境可以把冷却期拉到 300 秒避免频繁重启造成的抖动。6.2 假死检测与单模块重启单模块重启要带着“重置”语义执行不是简单调用on_start而是要完整走on_stop清理旧现场再重新on_create on_start。我在主进程里增加一个restart_module(name)接口内部按依赖逆序停掉该模块及其下游依赖再按依赖正序重新拉起。这里的坑是“重置必须先停干净再建”旧线程没销毁就开新线程轻则泄漏重则直接触发端口冲突。6.3 事件回放与状态补偿模块重启期间它可能错过事件总线上的一些消息直接把数据丢失是不可接受的。我给事件总线加了一个“环形缓冲”副作用每个事件在内存里保留最近 5 分钟数据模块重启成功后先订阅一个replay.request事件由总线把暂停期间错过的事件补发过去。代价是内存占用收益是数据不丢。生产环境里我会按事件类型分组只对关键业务事件做回放非关键事件不做。这套“熔断 单模块重启 事件回放”组合下来我遇到的最大收获是一个采集模块反复崩溃时主进程和转发模块还能持续提供旧数据的查询服务整体从“全挂”降级为“局部牺牲”这个体验差异对运维和用户都很明显。我的习惯是把熔断参数写进配置中心并带上修改记录每次调参都先观察一个完整冷却周期不急着看到立竿见影的效果。希望这篇能帮你在搭建常驻进程时少走几步弯路。本文还有配套的精品资源点击获取