Flask使用multiprocessing.managers存储数据的留存规则与清理方法

你用multiprocessing.Manager实现的跨请求存储不会自动丢弃用户断连后遗留的数据。
原因很简单：Manager启动的是独立于Flask请求处理逻辑的后台服务进程，生命周期和你的Flask主应用绑定，它本身没有会话感知能力，既不知道用户什么时候断开连接，也不知道哪些数据是过期无用的，只要你不主动删除、应用不重启，存入的数据会一直驻留内存，长期运行必然会堆积大量无效数据挤占资源。

你可以根据自己的业务场景选下面几种方案组合使用，基本能解决内存无效堆积问题：

• 给数据打时间戳+定时清理线程
  存数据的时候不要直接存原始值，统一封装成带存储时间戳的结构，比如{"data": 你的业务数据, "store_at": time.time()}。在Flask应用启动时启动一个守护后台线程，每隔固定周期（比如10~30分钟）遍历一次Manager中的所有存储键，把存储时间距当前时间超过你设定的会话有效期（比如2小时、24小时，按你业务需求定）的键直接删除即可。注意遍历清理时不要长时间持有Manager的锁，避免阻塞正常业务请求。
• 懒清理+主动删除配合
  每次用户发起新请求、命中对应会话存储时，先当场检查该条数据的时间戳是否已经过期，过期就直接删除后再处理新请求，不用等定时任务触发。如果你的前端支持页面关闭、用户主动退出时发送异步注销请求，可以直接在对应的接口逻辑里删除该用户关联的存储键，这是最及时、开销最小的清理方式。
• 大存量场景直接替换成自带过期能力的存储
  如果你预计单用户存储的数据量大、总用户量多，不建议继续自己维护Manager内存存储，直接换成Redis这类缓存服务即可，原生支持键级别的TTL过期配置，到点自动删除无效数据，不需要自己写清理逻辑，稳定性比手写的内存管理高很多，也支持多worker部署场景下的数据共享。

• 不要依赖Flask客户端Session的过期机制清理服务端数据：Flask默认的Session是存在用户浏览器Cookie里的，用户清Cookie、关浏览器导致Cookie失效时，你的服务端完全收不到对应的事件，这部分关联的存储数据会直接变成无主的垃圾数据。
• 多进程部署Flask时（比如用Gunicorn、uWSGI开多个worker），不要让每个worker单独初始化Manager实例，要单独启动一个独立的Manager进程让所有worker连同一个实例，不然不仅数据无法跨请求共享，清理逻辑也会出现混乱。

内容的提问来源于stack exchange，提问作者Peter Poláček