启用allkeys-lru策略需在redis.conf中设置maxmemory-policy为allkeys-lru并显式配置maxmemory（如2gb），否则不生效；该策略对所有key按近似LRU淘汰，不区分是否设过期时间。
如何在redis.conf中启用allkeys-lru策略
直接把 maxmemory-policy 设为 allkeys-lru 就行，这是让Redis对所有key（无论有没有设置过期时间）都按最近最少使用原则淘汰的最简方式。
- 必须同时配置
maxmemory，否则maxmemory-policy不生效（Redis会无视它，相当于默认的noeviction） - 推荐用带单位的写法，比如
maxmemory 2gb，避免字节换算出错 - 修改后要
redis-cli config rewrite或重启，仅config set是临时的，持久化失败会导致策略丢失 - 注意：如果已有大量没设过期时间的key，切到
allkeys-lru后它们也会被纳入淘汰范围——这点常被误认为“只淘汰缓存”，其实不是
为什么不能只靠volatile-lru来“保底”未过期数据
volatile-lru 只管设置了 EXPIRE 的key，而 allkeys-lru 才真正实现“全局LRU”语义——它不区分是否过期，只要内存满就统一按访问时间淘汰。
- 业务里常有人给部分key设了TTL、另一部分完全不设，以为这样能“保护核心数据”，结果
volatile-lru在内存压力下根本碰不到那些没TTL的key，导致OOM或写入失败 -
allkeys-lru能拉平所有key的淘汰资格，更适合作为纯缓存场景的兜底策略 - 但代价是：哪怕某个永久key是高频热点，只要它“最近没被访问”，照样可能被淘汰——这不是bug，是策略本意
实际运行中LRU是“近似”的，别当真
Redis没用双向链表实现精确LRU，而是随机采样5个key，从中挑出lru字段值最小的那个淘汰——所以它叫“近似LRU”，不是教科书上的严格实现。
- 采样数固定为5，不可调；想更准？只能升级到LFU或改用
allkeys-lfu -
lru字段存的是秒级时间戳的低24位（约49.7天轮回一次），所以跨多天后可能出现“旧时间比新时间数值大”的绕回现象，影响排序 - 高并发下多个线程同时更新lru字段，存在微小竞争，但不影响整体倾向性
- 验证是否生效？用
redis-cli --hotkeys看热点，再手动塞一批冷数据触发淘汰，观察哪些key先消失
容易忽略的兼容性陷阱
Redis 4.0之前不支持LFU，但 allkeys-lru 从2.8起就稳定可用；不过不同版本对 maxmemory 的默认行为有差异，务必确认当前版本。
- Redis 6.2+ 默认
maxmemory是0（不限制），但生产环境必须显式设置，否则allkeys-lru形同虚设 - 集群模式下，每个分片独立执行淘汰，不存在跨节点协调——所以热点key如果集中在某分片，那个分片会更早触发淘汰
- 启用了RDB/AOF时，淘汰动作仍实时发生，但落盘文件不会记录“被删了什么”，恢复后这些key就真的没了
evicted_keys 指标，而不是凭感觉猜。 
