FastAPI多Worker下跨函数共享数据避免重复加载问题咨询

以下方案按投入产出比从高到低排序，优先落地靠前的方案即可解决绝大多数场景的性能问题。

1. 启动阶段预加载全局数据，彻底消除请求内加载开销 #

利用FastAPI的lifespan生命周期钩子，在应用启动完成、正式接收流量前就把所有公共数据集一次性加载到全局只读变量中，所有路由直接引用该变量，完全跳过请求阶段的数据加载逻辑。
参考实现：

from contextlib import asynccontextmanager
from fastapi import FastAPI
import pandas as pd

# 全局变量存储公共数据集，启动完成后仅做只读使用
common_datasets = {}

@asynccontextmanager
async def lifespan(app: FastAPI):
    # 启动阶段仅执行一次数据加载
    common_datasets["user_df"] = pd.read_parquet("data/user_base.parquet")
    common_datasets["order_df"] = pd.read_parquet("data/order_history.parquet")
    common_datasets["product_df"] = pd.read_parquet("data/product_info.parquet")
    yield
    # 应用关闭时按需执行资源清理
    common_datasets.clear()

app = FastAPI(lifespan=lifespan)

# 动态业务路由直接使用预加载数据
@app.post("/dynamic_invoke")
async def dynamic_invoke(func_name: str, params: dict):
    target_func = BUSINESS_FUNC_REGISTRY[func_name]
    result = target_func(datasets=common_datasets, **params)
    return {"code": 0, "data": result}

注意：全局存储的公共数据集必须保持只读，不要在请求处理逻辑中直接修改全局DataFrame，否则会触发线程安全问题。如果业务逻辑必须修改数据，请先对用到的子集做深拷贝后再操作。

单worker进程部署场景下，该方案落地后所有请求都不会触发重复数据加载，性能问题可以直接解决。

2. 多worker部署场景：用共享内存替代独立加载/Redis缓存 #

你之前遇到的多Uvicorn worker各自加载数据、Redis序列化DataFrame开销过高的问题，核心原因是进程内存隔离+大对象序列化成本高，不需要用Redis做缓存，直接用零拷贝共享内存方案即可：

• 轻量方案：如果服务器内存可以容纳全量公共数据集，直接把Uvicorn的worker数设置为1，用单进程+异步协程模型承载流量。FastAPI+Uvicorn单异步进程的QPS可以达到数千级别，足够覆盖绝大多数中小规模业务场景，从根源上规避多进程重复加载问题。
• 多worker刚需方案：使用Python内置的multiprocessing.shared_memory模块，由主进程在fork worker前加载全量数据到共享内存块，所有worker进程直接映射同一块物理内存读取DataFrame，没有序列化/反序列化开销，也不需要每个进程单独加载数据。
• 超大规模数据集方案：部署独立的Apache Arrow Flight服务托管公共数据集，所有worker通过Arrow协议零拷贝拉取需要的数据字段，性能是Redis缓存方案的10~100倍。

3. 聚合调用场景优化：新增批量调用端点 #

聚合路由连续8次调用单函数端点的逻辑本身就存在不必要的HTTP开销，直接新增批量调用路由，一次请求接收所有待执行的任务列表，服务端内部执行完成后一次性返回结果，把请求数从8降到1，进一步摊薄剩余开销。
参考实现：

@app.post("/batch_dynamic_invoke")
async def batch_dynamic_invoke(task_list: list[dict]):
    result_list = []
    for task in task_list:
        target_func = BUSINESS_FUNC_REGISTRY[task["func_name"]]
        task_result = target_func(datasets=common_datasets, **task["params"])
        result_list.append(task_result)
    return {"code": 0, "data": result_list}

聚合侧直接调用该批量接口即可，不需要循环发8次单次请求。

之前方案的问题说明 #

• 进程内字典缓存的思路本身没有问题，问题在于你把加载逻辑放在了请求处理阶段，才会导致每个worker第一次收到请求时才触发加载，把加载逻辑移到启动阶段就不会有冷请求卡顿、重复加载的问题。
• Redis不适合缓存大体量Pandas DataFrame：Redis的优势是存储小体积、高频访问的结构化数据，大体积DataFrame的pickle序列化、网络传输、反序列化的总开销远高于本地加载/共享内存读取的开销，无法解决性能问题。

内容的提问来源于stack exchange，提问作者rayad