预加载WSGI应用时工作进程更新父数据结构并重载worker的实现方法

基于 gunicorn 预加载 + prefork 的现有机制，配合跨进程队列即可实现需求，具体逻辑如下：

1. 父进程初始化步骤 #

在 gunicorn 完成 WSGI 应用预加载之后、派生工作进程之前做两个操作：

• 初始化一个 multiprocessing.Queue 实例，该实例会被后续派生的所有工作进程继承，用作修改请求的通信通道
• 将预加载的复杂只读数据结构挂载到父进程的全局属性上，此时所有刚派生的工作进程都能通过 Linux 读时共享（Copy-on-Write）机制直接访问这份数据，无需额外复制内存

2. 工作进程侧修改请求提交逻辑 #

当工作进程触发数据修改需求时：

• 仅需将修改操作所需的参数（无需传递完整数据结构）写入继承到的队列即可
• 可根据业务需求选择直接返回修改已受理的响应，或是阻塞等待父进程完成数据更新后再返回结果

3. 父进程侧更新与重启逻辑 #

父进程完成所有工作进程的初始派生后，启动一个独立的轻量线程循环监听队列：

• 收到修改请求后，先向所有现有工作进程发送 SIGTERM 优雅停止信号，等待存量请求处理完成后回收进程
• 在父进程内存空间直接完成复杂数据结构的修改，无需处理多进程同步、序列化等问题，支持任意复杂度的内存分配操作
• 按原配置的工作进程数量重新派生子进程，新进程会直接继承修改后的最新数据结构，无需重新执行高成本的预加载流程

场景适配说明 #

完全匹配你列出的所有适用场景：

• 预加载全程仅执行1次，修改数据时也无需重复预加载，资源消耗极低
• 读操作直接访问进程本地内存，没有任何同步锁、IPC 通信开销，性能和原生预加载模式完全一致
• 仅在写操作发生时触发一次工作进程重启，写操作极少的前提下可用性影响可以忽略
• 数据结构修改完全在父进程的原生 Python 内存空间执行，不受 multiprocess 共享内存预分配、序列化的限制，支持任意复杂的内存分配逻辑

可选优化 #

• 父进程可批量消费队列中一段时间内的多个修改请求，批量更新数据后再统一重启工作进程，减少不必要的重启次数
• 可给数据结构加版本号标记，避免重复处理相同的修改请求

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