Django无数据库时，Strava用户活动数据跨请求存储方案咨询

嘿，这个场景我之前也碰到过类似的，咱们来捋捋各个方案的利弊，再看看更优的选择～

先聊聊你提到的两个方案的问题 #

1. 把数据存在Session里 #

这个思路听起来简单，但实际有几个坑：

• 存储容量限制：如果你的框架用的是基于Cookie的Session（比如Flask默认的session），那Cookie的大小上限一般是4KB左右，800项活动的JSON绝对远超这个，直接行不通。就算是服务器端存储的Session（比如存在内存里），多用户同时使用的话，服务器内存压力会骤增，而且Session过期后数据直接丢失，用户重新登录得重新下载，体验不太好。
• 查询效率低：每次前端请求API端点，你都得从Session里取出所有活动数据再过滤，数据量大的话遍历、过滤的开销会很高，响应速度会变慢。

2. 临时数据库存储后删除 #

这个方案其实没你想的那么“小题大做”，但确实可以优化：

• 好处是能结构化存储，查询过滤更高效（比如用SQLite存JSON字段，或者用PostgreSQL的JSONB类型），但手动管理数据生命周期（会话结束后删除）有点麻烦，得监听会话过期事件或者写定时任务，反而不如用自带过期机制的存储工具省心。

更优的处理方案推荐 #

1. 带TTL的键值存储（首推！） #

用Redis这类支持过期时间（TTL）的键值存储是最适合的：

• 以用户的Strava唯一ID作为键，把下载好的活动JSON数据作为值存在Redis里，设置一个合理的TTL（比如24小时，或者和用户会话时长一致）。这样用户在会话期间可以快速读取数据，过期后Redis会自动删除，完全不用你手动清理。
• 要是想提升查询效率，还可以把常用的过滤字段（比如活动类型、起始日期）单独存成索引键，比如strava:{user_id}:activity_types，这样前端请求过滤时不用全量遍历JSON，直接查索引就能快速定位。
• 而且这种方式支持多进程/多服务器部署，数据是共享的，比内存Session灵活多了。

2. 单进程场景下的内存缓存+TTL #

如果你的应用是单进程部署（比如开发阶段或者小流量个人应用），可以用一个全局字典存储用户数据，再配合定时器定期清理过期数据：

import time
from collections import defaultdict

# 存储用户活动数据，格式：{strava_id: {"data": activities, "expire_at": timestamp}}
user_activity_cache = defaultdict(dict)

def add_to_cache(strava_id, activities, expire_hours=24):
    expire_at = time.time() + expire_hours * 3600
    user_activity_cache[strava_id] = {"data": activities, "expire_at": expire_at}

def get_from_cache(strava_id):
    entry = user_activity_cache.get(strava_id)
    if not entry:
        return None
    if time.time() > entry["expire_at"]:
        del user_activity_cache[strava_id]
        return None
    return entry["data"]

# 定时清理过期数据的函数，比如每分钟跑一次
def clean_expired_cache():
    now = time.time()
    expired_ids = [sid for sid, entry in user_activity_cache.items() if entry["expire_at"] < now]
    for sid in expired_ids:
        del user_activity_cache[sid]

不过这个方案的缺点是服务器重启后数据全丢，而且不支持多进程部署，适合小体量场景。

3. 本地临时文件存储 #

给每个用户生成一个唯一的文件名（比如用Strava ID的哈希值），把JSON数据存在服务器的临时目录里，然后用系统工具（比如Linux的tmpwatch）或者定时任务定期清理过期文件。这种方式实现简单，但查询时需要读取文件并解析JSON，性能不如Redis，适合流量极小的个人应用。

总结 #

如果是生产环境或者需要支持多用户，Redis带TTL的键值存储是最优解，既解决了数据存储和过期问题，又能提升查询效率；如果是开发阶段或者小流量场景，可以试试内存缓存方案。

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