Python
最近在重新设计一个任务系统时，我顺便把自己对 Python，尤其是 CPython 应用场景的理解重新梳理了一遍。 这次讨论的背景是一个典型的异步任务服务： 上游提交任务 API 立即返回 task_id 后台 worker 慢慢执行 用户通过 task_id 查询任务状态 任务主要是 LLM 调用、图片下载、外部 HTTP 请求这类 I/O 型工作。 一开始关注的是队列、Redis、PostgreSQL、worker 并发控制这些问题。但聊到后面，其实更核心的问题变成了： Python 到底应该放在什么位置？ 哪些并发适合 Python？ 哪些并发不要硬塞给 Python？ FastAPI、协程、线程、数据库之间应该怎么分工？ 这篇文章就是这次思考的整理。 一、我不想抛弃 Python，
Go
在讨论 PostgreSQL queue 方案之后，我又回头看了一下之前自己设想过的 Go + Redis 任务架构。 最早我脑子里的方案大概是： POST 创建任务 Redis 存状态 Go goroutine 直接处理 进程内 channel 控制并发 这个方案很直观，也很符合 Go 的写法。 用户请求进来后，API 生成一个 task_id，把任务状态写进 Redis，然后把任务塞进 Go 的 channel，由后台 goroutine 消费执行。并发控制就靠一个固定大小的 channel 或 worker pool，比如最多 20 个 goroutine 同时执行任务。 这个设计在单进程里确实很舒服。 但当我开始思考多进程、多容器、
架构
"What can't Postgres do?" —— 这两年技术圈最流行的一句话 "Use one database, but use it really well." —— Hacker News 上一条 2k+ 赞的评论 写在最前面:一张让人窒息的架构图 先看一张图,看看你眼熟不: [客户端] │ ▼ [API Gateway] ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ [业务服务] [认证服务] [搜索服务] │ │ │ ├──→ MySQL ├──→ Redis ├──→ Elast
架构
最近我对一个 LLM 任务服务做了一次比较完整的架构升级。 这个服务本身并不复杂：上游提交任务，我返回一个 task_id，后续上游再通过 task_id 查询任务状态和结果。任务的执行内容主要是调用 LLM 或相关多模态接口，单个任务耗时通常在几十秒以内。 最开始的实现是比较常见的组合： FastAPI + Redis + Docker API 接到请求后生成任务 ID，把状态写入 Redis，然后由后台逻辑继续执行任务。这个方案在早期足够轻量，开发速度也很快。 但随着需求继续演进，我开始更明确地追求几个能力： 1. 上游可以瞬间提交大量任务 2. API 必须快速返回 task_id 3. 真正执行的任务数量必须全局可控 4. 任务状态要可查询、可恢复、可追踪 5. worker 崩溃后任务不能永久卡死 6. 未来希望减少组件数量，尽量 all
Python
本文记录了一个 FastAPI 异步任务服务在并发架构上的思考和演进过程。这个服务的本质很简单：接收客户端请求，转发给下游 AI API，把结果存起来供客户端轮询。它不做复杂的业务计算，不做数据聚合，就是一个纯转发层——接活、派活、存结果。正因为场景足够简单，我们才有机会做一次化繁为简的架构妥协，把原本"看起来该用任务队列"的设计砍到只剩三行核心配置。 一、先说清楚场景：我们到底在干什么 这个服务做的事情可以用一句话概括： 客户端提交参数 → 服务转发给下游 AI API → 等结果 → 存 Redis → 客户端来取。 关键特征： * 纯 IO 转发：服务本身不做任何 CPU 密集计算，所有耗时都花在等下游 API 返回。一次调用几秒到几十秒不等，全是网络等待。 * 异步模式：客户端提交任务后立即拿到 task_id，
陕公网安备61011302002223号