uwsgi+Nginx多worker下Flask的FileSystemCache数分钟失效问题

FileSystemCache本身设计上是支持多worker进程跨进程共享缓存的，你遇到的每隔数分钟缓存丢失、强制重新登录的问题，本质是你使用的flask-caching 1.10.1版本中FileSystemCache的实现存在竞态bug，并非该缓存类型不适用于多进程场景。

异常核心成因 #

• 过期清理逻辑无跨进程锁保护：1.10.1版本的FileSystemCache在任意进程执行缓存get/set操作时，都会随机扫描缓存目录下的一批文件，判定为过期就直接删除，整个清理流程没有加跨进程互斥锁。你当前配置了2个uWSGI worker，并发请求下极易出现竞态：A进程刚写入认证token对应的缓存文件，B进程触发清理扫描时，因文件系统元数据同步延迟、时间戳判断冲突，把尚在有效期内的缓存文件误删，这和你日志中观测到的非预期key删除现象完全吻合。
• 缓存写入无原子性保障：该版本写入缓存时会先创建临时文件，再通过rename操作替换正式缓存文件，临时文件生成到完成替换的时间窗口内，其他进程的清理扫描逻辑会把临时文件判定为无效缓存直接删除，最终导致缓存写入失败。
• 开发环境的进程重载机制放大问题：本地开发环境通常开启代码热重载、worker自动回收，旧worker进程退出时如果触发缓存清理，会直接删除新启动worker写入的缓存文件，进一步提升缓存丢失概率。

可行解决方案 #

按改造成本从低到高排序，你可以根据团队依赖约束选择：

方案1：升级依赖到修复版本（推荐） #

不需要修改业务代码，也不需要额外部署缓存组件，直接升级依赖即可解决问题：

• 不要停留在1.10.1，也不要用存在cachelib集成异常的1.11.1，直接升级到flask-caching>=1.12.0，该版本已经修复了cachelib集成问题，底层依赖的cachelib也补全了FileSystemCache的跨进程文件锁、清理逻辑竞态问题，升级后重启uWSGI服务即可恢复正常。
• 如果受项目其他依赖限制无法升级高版本flask-caching，可以单独升级底层依赖的cachelib到>=0.9.0，旧版flask-caching可以兼容新版cachelib的FileSystemCache实现。

方案2：调整配置规避bug（无法升级依赖时的临时方案） #

如果暂时不能调整依赖版本，可以修改缓存配置关闭自动淘汰逻辑，从根源上避免误删：

# Flask缓存配置项
CACHE_TYPE = "FileSystemCache"
CACHE_DIR = "./dev_cache"  # 固定缓存目录，不要放在临时目录下
CACHE_DEFAULT_TIMEOUT = 86400  # 缓存超时时间和token实际有效期保持一致
CACHE_THRESHOLD = 0  # 关闭按缓存数量自动淘汰的逻辑
CACHE_OPTIONS = {"ignore_errors": True}

配置调整后，加一个简单的定时任务，每天低峰期手动删除缓存目录下修改时间超过7天的文件，避免缓存目录无限膨胀即可。如果想进一步降低竞态概率，可以把缓存目录挂载到/dev/shm内存文件系统下，减少磁盘文件系统的元数据同步延迟。

方案3：调整uWSGI开发环境配置（零改造成本） #

本地/团队开发环境没有高并发需求，直接修改uWSGI配置为单worker+多线程模式，从架构上消除跨进程竞态：

[uwsgi]
processes = 1
threads = 8
lazy-apps = false
# 开发环境如果不需要代码热重载可以直接关掉
py-autoreload = 0

单进程模式下不管是SimpleCache还是FileSystemCache都不会出现跨进程缓存不一致、误删的问题，完全可以满足开发调试需求，不需要改动任何业务代码或部署额外组件。

注意：该配置仅适用于开发环境，生产环境继续使用已有的Redis/Memcached方案即可。

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