过期

Redis 过期机制回答的是一个键什么时候应当停止可见，而不是整个服务最多使用多少内存。截止时间属于键，后续命令可能保留、替换或者移除它。因此，可靠地使用 TTL，既要检查首次写入，也要覆盖更新路径。看到写命令成功，不能证明之前设置的截止时间仍然存在，更不能直接推断数据最终会按原计划消失。 部分更新保留键期限，普通 SET 则清除期限。原文实验属于历史记录；可见性、清理和 RSS 必须分开。 截止时间不是自动滑动计时器 EXPIRE 使用秒，PEXPIRE 使用毫秒。Redis 将过期信息保存为绝对 Unix 时间戳，所以服务器停止运行期间，时间仍然继续流逝。系统时钟必须稳定，跨机器恢复数据时尤其需要注意时钟差异。它不是独立于系统时间变化的单调时长承诺。下面的实验只使用正常流逝的时间，不调整本机系统时钟。 GET 不会刷新过期时间。INCR 这类原地修改保留键已有的超时；普通成功的 SET 则替换值，并清除原来的超时。SET KEEPTTL 可以保留原期限，再次显式设置过期命令则会改变截止时间。需要滑动会话的应用必须主动实现续期策略，不能以为用户每次读取数据都会自然延长访问窗口。 当值和初始寿命属于同一次操作时，应使用 SET EX 或 SET PX 一起写入。分成 SET、EXPIRE 两条命令，会留下一个值已经存在、期限却尚未写入的失败窗口。客户端如果恰好在两条命令之间崩溃，就可能留下持久条目。这是写入协议缺陷，不是后台过期周期执行得太慢，调整清理频率也修复不了它。 ...