KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

后端进程模型与连接治理 · 课程导读 — keel 龙骨

后端进程模型与连接治理 的参考信息：后端进程模型与连接治理 · 课程导读

你现在的起点

• 用 Python 写过 FastAPI 或异步服务，但说不清「一个 uvicorn 进程里有几个 event loop」；
• 用过 SQLAlchemy / asyncpg / redis 客户端的连接池，当它是开箱即用的黑盒；
• 听过「fork 子进程之后连接池要重建」这类传说，不知道什么时候是真的、什么时候是讹传。

如果你符合上面这几条，这门课就是为你写的。它不教任何具体业务，只回答一个长期困扰后端开发者的问题：进程、线程、事件循环这些并发单元，和连接池这类有状态资源，到底应该怎么划分归属。

一条能走通的学习路径

01 三种并发单元（进程 / 线程 / event loop，GIL 边界，拓扑怎么选）
  → 02 fork、exec 与文件描述符（继承的精确规则，Popen 默认不继承的真相）
  → 03 连接池的三条共享边界（进程 / event loop / 线程，归属判定原则）
  → 04 失败模式排查手册（随机协议错误、Event loop is closed、连接泄漏）

两个必须先纠偏的认知

1. 「subprocess 拉起的子进程会继承数据库连接」在 Python 3.4+ 默认参数下是错的。 PEP 446 之后 fd 默认不可继承，subprocess.Popen 默认 close_fds=True，socket 传不过去。真正踩坑的是 fork 型模型（gunicorn preload、multiprocessing 进程池、os.fork()）。第 2 章会把规则摆到字节级。
2. 连接池的共享边界不止一条。 跨进程不能共享是大家都知道的；跨 event loop 不能共享（Event loop is closed）和跨线程的差别（同步池可以、异步池不行）同样致命。三条边界合起来才是一套完整的归属判断。

学完这门课你能做什么

• 为「HTTP 服务 + 后台任务」选对并发拓扑，说清进程隔离、独立扩缩、崩溃隔离各自的代价；
• 拉起子进程时能判断「这个场景 fd 会不会传过去」，并写出防御性的 dispose + 懒加载重建；
• 拿到 terminating connection due to protocol error、Event loop is closed、连接数涨满这类症状时，有确定的排查路径而不是抓瞎重启。

前置要求

• 会用 Python 的 asyncio 基础（async / await / 异步生成器）；建议先读 yield 详解课；
• 建议先读高并发工程课的异步正确性一章，本课在其基础上往进程模型与资源归属推进。

进入 keel 阅读