volatile-ttl 不适合用作 session 存储的淘汰策略，因其仅按剩余 ttl 大小机械淘汰，无视访问活跃性，导致刚刷新的 session 因微小 ttl 差被误删，引发频繁掉线；应改用 volatile-lru。
直接说结论：volatile-ttl 不适合用作 Session 存储的淘汰策略，强行使用会导致会话提前失效、用户频繁掉线，尤其在高并发或 TTL 设置不均的场景下问题更明显。
为什么 volatile-ttl 会误删活跃 Session
volatile-ttl 的逻辑非常机械：只看 TTL 剩余值大小，谁小谁先删，完全不关心这个 key 是否刚被访问过、是否正在被使用。而 Session 的典型模式是——写入时设固定 TTL（比如 30 分钟），之后每次请求都会 EXPIRE 延长 TTL，但 Redis 淘汰器看不到“延长”动作，它只读取当前瞬间的 TTL 值。
这意味着：两个 Session 同时写入，A 设了 1800 秒，B 设了 1799 秒；5 秒后 B 被刷新到 1800 秒，A 却因网络延迟没刷成功，此时 A 的 TTL 剩 1795，B 剩 1795 —— 看似一样；但只要其中任意一个因客户端抖动漏刷一次，它的 TTL 就会比别人小几秒，成为 volatile-ttl 的首选目标。
常见错误现象包括：
- 用户刚登录就弹回登录页
- 后台定时刷新 Session 失败后，对应用户立刻被登出
- 压测时并发写 Session 导致大量 TTL 微差，淘汰集中在某一批连接上
Session 场景真正需要的是 volatile-lru
Session 的核心特征是“访问即活跃”，而不是“到期即废弃”。用户操作越频繁，Session 越该保留；哪怕它离过期只剩 10 秒，只要刚被读取过，就不该被淘汰。
volatile-lru 正好匹配这一逻辑：它只作用于设置了 EXPIRE 的 key（保障最终清理），同时基于最近访问时间做淘汰，天然适配 Session 的心跳式更新模式。
实操建议：
- 所有 Session key 必须统一调用
SETEX或SET ... EX写入，确保带 TTL - 每次请求验证 Session 时，必须紧跟一次
EXPIRE key ttl（不能只靠写入时的初始 TTL） - 配置项应为：
maxmemory-policy volatile-lru，而非volatile-ttl - 如果业务允许部分 Session 永不过期（如长期 token），需单独建库或命名空间隔离，避免污染 volatile-lru 统计
allkeys-lru 为什么也不推荐用于纯 Session 库
看起来 allkeys-lru 更“彻底”，连没设 TTL 的 key 都能淘汰。但它破坏了 Redis 的语义契约：Session 必须有明确生命周期，这是安全审计和合规的基本要求。一旦混入无 TTL 的 key（比如误存的调试数据、临时计数器），allkeys-lru 可能长期保留它们，反而挤占真正 Session 的内存。
更关键的是，allkeys-lru 无法保证“过期即清理”——那些本该自然消失的僵尸 Session（如用户关浏览器后未主动登出），会一直留在内存里，直到被 LRU 淘汰，这既浪费内存，又带来安全隐患。
所以正确做法是：
- Session 全部走
volatile-*策略（强制 TTL） - 用
volatile-lru平衡活跃性与自动清理 - 配合业务层定期扫描
KEYS session:*+TTL做兜底巡检（仅限低峰期）
真正容易被忽略的一点是：volatile-ttl 的“优先级”不是按业务意义排的，而是按 Redis 内部时钟精度排的——它的 TTL 读取发生在淘汰采样瞬间，而采样本身是随机键抽查，不是全量排序。所以你永远无法预测哪个 Session 会被删，只能祈祷别删到正在付款的那个。
