Flask搭配Gunicorn多worker时变量继承与密钥加载机制问题

• 部署环境：AWS平台部署Flask应用，使用Gunicorn作为WSGI服务器，配置4个worker进程
• 原密钥读取逻辑：从环境变量读取应用密钥，代码如下：

app = Flask(__name__)
app.secret_key = env.get("APP_SECRET_KEY")

• 当前状态：已切换为AWS Secrets Manager管理密钥，服务运行正常
• 拟修改代码：将密钥读取逻辑替换为自定义模块方法拉取，代码如下：

app = Flask(__name__)
app.secret_key = mymodule.get_3rd_party_keys()

• 核心疑问：修改后是所有worker都会单独查询AWS密钥服务，还是app.secret_key会被worker继承，不需要每次处理请求时重复调用查询？

直接给明确结论：

• 不管你用哪种Gunicorn配置，这段代码绝对不会在每次处理请求时重复调用AWS Secrets Manager查询密钥。app.secret_key在模块加载完成后就会常驻进程内存，后续所有请求直接读取内存值，不会重复执行拉取密钥的函数。
• 至于worker启动阶段总共会调用几次密钥接口，取决于你是否开启了Gunicorn的preload_app配置：
  1. 默认配置（preload_app=False，未加--preload启动参数）：Gunicorn主进程不会提前加载应用代码，fork出4个worker子进程后，每个子进程会独立导入app模块、执行全局作用域代码。这种场景下4个worker启动时会各自调用1次mymodule.get_3rd_party_keys()，总共4次调用，全部发生在worker启动阶段，服务启动完成后不会再因为请求处理触发调用。
  2. 开启preload_app=True（加--preload启动参数）：主进程会先完成app模块加载、执行完全局代码拿到密钥赋值给app.secret_key，再fork出4个worker子进程。子进程会通过写时复制机制直接继承主进程内存里的已加载变量，整个启动流程只会调用1次密钥接口。
• 额外说明：如果你配置了max_requests参数触发worker自动重启，或者worker异常崩溃被主进程拉起，那么重启后的worker会重新执行模块加载逻辑，此时会再次调用密钥接口，调用频率和worker重启频率一致，和请求量没有关系。
• 避坑提醒：只要你不把mymodule.get_3rd_party_keys()写到视图函数、before_request这类请求级别的逻辑里，就不会产生请求级别的重复密钥查询，你现在的写法本身是合理的。

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