KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
后端进程模型与连接治理 — keel 龙骨
面向后端开发者的进程模型课:进程/线程/事件循环的选型边界、fork 与 exec 的继承规则(PEP 446 与 close_fds 的真相)、连接池的三条共享边界(进程/event loop/线程)与归属判定图、以及从随机协议错误到连接涨满的失败排查手册。
面向后端开发者的进程模型课:进程/线程/事件循环的选型边界、fork 与 exec 的继承规则(PEP 446 与 close_fds 的真相)、连接池的三条共享边界(进程/event loop/线程)与归属判定图、以及从随机协议错误到连接涨满的失败排查手册。
章节目录
- 01 · 三种并发单元:进程、线程、事件循环怎么选 — 后端服务的每一个「并发」决定,最终都要落到三种单元之一上。选错单元的症状各不相同:该用进程的用了线程,表现为 CPU 打不满却卡顿;该用 asyncio 的用了进程池,表现为内存翻倍还慢。这一章先把三种单元的边界画清楚,再用一个真实拓扑把决策走一遍。
- 02 · fork、exec 与文件描述符:子进程到底继承了什么 — 「fork 之后连接池要重建」是后端圈流传最广的工程传说之一——它的麻烦在于一半是真的。这一章把继承规则摆到字节级:什么情况下 socket 会传给子进程、什么情况下默认就传不过去,以及防御性 dispose 为什么仍然值得写。
- 03 · 连接池的三条共享边界:进程、事件循环、线程 — 第 2 章讲透了进程边界。但「Event loop is closed」这种报错和进程毫无关系——它是第二条边界。这一章把连接池的归属规则补完整:三条边界、一张判定图、一条通用原则。
- 04 · 失败模式排查手册:从报错反推根因 — 前三章是「从原因到结果」,这一章反过来:给你真实故障的症状,训练你反推根因的能力。四个症状按出现频率排序,每个都给出排查路径和确定性的验证方法。读法建议:先只看症状栏,自己推一遍再看答案。