Python
最近在重新设计一个任务系统时，我顺便把自己对 Python，尤其是 CPython 应用场景的理解重新梳理了一遍。 这次讨论的背景是一个典型的异步任务服务： 上游提交任务 API 立即返回 task_id 后台 worker 慢慢执行 用户通过 task_id 查询任务状态 任务主要是 LLM 调用、图片下载、外部 HTTP 请求这类 I/O 型工作。 一开始关注的是队列、Redis、PostgreSQL、worker 并发控制这些问题。但聊到后面，其实更核心的问题变成了： Python 到底应该放在什么位置？ 哪些并发适合 Python？ 哪些并发不要硬塞给 Python？ FastAPI、协程、线程、数据库之间应该怎么分工？ 这篇文章就是这次思考的整理。 一、我不想抛弃 Python，
Go
最近我在写 worker 任务系统的时候，重新理解了一遍 Python 和 Go 的并发差异。 以前写 Python，多 worker 经常要考虑： 多进程怎么管理？ 日志会不会串？ 一个 worker 崩了怎么办？ 怎么吃满多核心？ 后来换成 Go，发现一个进程里开多个 goroutine worker 就很自然： go worker(1) go worker(2) go worker(3) go worker(4) 日志也好管，状态也好管，而且单进程还能利用多个 CPU 核心。 一开始很容易误会成： Python 不行，Go 行 但更准确的理解应该是： Python 和
Go
最近我在做 worker 任务系统的时候，突然意识到一个很关键的问题： 以前写 Python，多 worker 的时候经常要小心日志串、文件切割乱、时间不好管理。 但是换成 Go 以后，一个进程里开多个 goroutine worker，反而可以比较自然地写到同一个日志文件里。 一开始我以为这是“Python 和 Go 写日志能力不一样”，后来想明白了，核心不是日志本身，而是： Python 常见 worker 模型：多进程 Go 常见 worker 模型：单进程 + 多 goroutine 这背后其实是两个语言在并发模型上的巨大差异。 一、进程、线程、goroutine 先分清楚 先把几个概念捋一下。 进程：操作系统分配资源的单位 线程：CPU 调度执行的基本单位
Python
本文记录了一个 FastAPI 异步任务服务在并发架构上的思考和演进过程。这个服务的本质很简单：接收客户端请求，转发给下游 AI API，把结果存起来供客户端轮询。它不做复杂的业务计算，不做数据聚合，就是一个纯转发层——接活、派活、存结果。正因为场景足够简单，我们才有机会做一次化繁为简的架构妥协，把原本"看起来该用任务队列"的设计砍到只剩三行核心配置。 一、先说清楚场景：我们到底在干什么 这个服务做的事情可以用一句话概括： 客户端提交参数 → 服务转发给下游 AI API → 等结果 → 存 Redis → 客户端来取。 关键特征： * 纯 IO 转发：服务本身不做任何 CPU 密集计算，所有耗时都花在等下游 API 返回。一次调用几秒到几十秒不等，全是网络等待。 * 异步模式：客户端提交任务后立即拿到 task_id，
陕公网安备61011302002223号