FastAPI多租户大负载应用扩容与高并发优化咨询

一、多Gunicorn worker的实际并发表现 #

直接给结论：实际并发承载能力一定会低于单worker的4-6倍理论值，核心损耗来自三个方面：

• 资源开销损耗：每个Gunicorn worker是独立操作系统进程，会独立加载代码、ML模型、维持数据库连接，再叠加单请求10MB的响应内存占用，worker数量一旦超过服务器物理内存/CPU核心的承载阈值，会触发内存swap、CPU核心争抢，单请求耗时会明显上涨，极端情况下开4个worker的性能甚至不如单worker。
• 共享资源争抢：多个worker会同时抢占数据库连接、网络带宽、磁盘IO资源。比如开6个worker就会同时向PostgreSQL发起6个查询，一旦数据库CPU/IO打满，所有worker都会阻塞在查询等待阶段，并发能力直接卡在数据库侧，和worker数量没有关系。单请求10MB响应的场景下，6并发就需要至少60MB/s的出网带宽，带宽跑满后请求排队延迟会飙升。
• 进程调度损耗：操作系统对多进程的调度本身有固定开销，worker数量越多，调度开销占比越高。

如果要在不改动代码的前提下提升多worker的利用率，不要用Gunicorn默认的sync worker类，换成gthread worker并给每个worker配2-4个工作线程，单个worker在等待数据库返回的IO间隙就能切换线程处理其他请求，同等硬件资源下并发能力比纯sync worker高30%以上，不需要额外堆进程数。

二、async改造的数据库瓶颈问题 #

你担心的数据库瓶颈是客观存在的，但和是否用async没有直接关系：

async模式的本质是把进程同步等待IO的空闲CPU时间利用起来，提升单进程的请求处理密度，不会减少单请求对数据库的查询压力。同步模式下4个worker最多同时给数据库发4个查询，async模式下单进程可能同时发起几十上百个查询，确实会更快触达数据库的吞吐上限。
但这不是async方案的缺陷，反而是帮你更早定位架构短板——数据库瓶颈本来就存在，只是同步模式下应用层的处理能力太弱，没把瓶颈打出来而已。

要注意的是：你的接口里包含ML模型推理这类CPU密集型逻辑，绝对不能直接放在async路由函数里运行，会阻塞整个事件循环，此时async模式的性能甚至不如同步多worker，必须把CPU密集逻辑扔到独立的进程池/线程池里执行，或者拆成独立服务。

三、支撑1000峰值并发的落地路径 #

按改造成本从低到高分阶段推进，不需要一开始就大改代码：

阶段1：零代码改造的垂直优化（可支撑100-200并发/单机） #

• 按实际资源配worker：1个CPU核心配1-2个gthread worker，每个worker配2-4线程，worker总内存预留按「单进程基础内存占用 + 单请求10MB负载 * 线程数 * 1.5倍冗余」计算，别盲目照搬CPU核数*2+1的默认公式。
• 前置Nginx做反向代理：开启gzip/brotli压缩，10MB的响应通常能压到1-2MB，直接省80%带宽开销；对2-3分钟粒度的重复查询结果开边缘缓存，挡住同租户短时间的重复请求；配置合理的请求排队策略，避免突发流量直接打满Gunicorn worker。
• 数据库基础优化：给高频查询加索引，把2-3分钟的热数据留在PG共享缓存里，把单查询耗时压到最低；把PG的max_connections配置成应用侧总连接数的1.2倍，不要开太大避免过多连接导致的上下文切换开销。

阶段2：架构解耦+横向扩容（可稳定支撑1000+并发） #

• 服务拆分：把ML推理逻辑从API服务里拆成独立的推理服务，API层只负责参数校验、查库、组装响应，变成纯IO密集型服务，单机并发能力能直接翻2-3倍；推理服务可以独立按CPU/GPU资源扩容，不和API层抢资源。
• 无状态改造+横向扩容：把API服务做成无状态，前面挂四层/七层负载均衡，按单机承载100-150并发的基准，加对应数量的应用节点即可。这一步必须前置部署PgBouncer做数据库连接池，用事务级连接复用，不然多节点的连接数会直接把PostgreSQL撑爆，PgBouncer通常能把PG的连接承载能力提升10倍以上。
• 加缓存层：把查询的最近2-3分钟热数据按租户+查询维度存入Redis，TTL设30-60秒，通常能挡住80%以上的重复查库请求，数据库压力直接降一个数量级，就算后续上async模式也不会轻易打满数据库。

阶段3：性能深度优化（可选，用于降低硬件成本） #

• 完成前面两步的优化后，再考虑把同步代码改造成async模式，换用asyncpg异步驱动，此时缓存、连接池、服务拆分都已经到位，async带来的吞吐提升可以直接转化为硬件成本的下降，不会出现一上async就打崩数据库的问题。
• 对10MB的大响应做分页/分片传输，降低单请求的内存拷贝开销和带宽占用。

四、扩容必须重点考量的核心因素 #

• 永远先找短板：系统并发上限是CPU、内存、数据库吞吐、网络带宽四个值的最小值，哪块先到瓶颈先补哪块，不要上来就盲目改代码架构。
• 不要迷信async：async只对纯IO密集型场景有收益，有CPU密集逻辑的场景不做拆分直接上async，只会适得其反。
• 多租户场景必须配置租户级限流，避免单个租户的大查询占满全部资源，影响其他租户正常使用。
• 数据库是绝大多数Web服务的第一个瓶颈，早做连接池、缓存、查询优化，收益远高于在应用层堆技术方案。

内容的提问来源于stack exchange，提问作者Obi wan kenobi