volatile-lru 不适合社交关系链，因其仅淘汰带过期时间的 key，而关系数据作为主数据映射不应设 ttl；强行加 expire 会引发雪崩与 cpu 升高；allkeys-lfu 更匹配二八流量特征，配合调大 maxmemory-samples 和合理配置 lfu 衰减可提升淘汰精准度。
社交关系链（如关注、粉丝、共同好友）对缓存的“热度分布极不均匀”——少量头部用户（明星、大V）被高频查询，大量长尾用户访问稀疏；同时关系数据本身生命周期明确（例如临时互关、活动期间涨粉）。直接套用默认 noeviction 或通用 allkeys-lru 会导致热点键被误踢、冷数据长期占内存、或写入失败频发。必须按数据特征分层配置淘汰策略。
为什么 volatile-lru 不适合社交关系链
社交关系链中，多数 key（如 follow:1001、fans:2002）本就不该设过期时间——它们是业务主数据的缓存映射，删除后需回源重建，代价高；强行加 EXPIRE 反而引入 TTL 维护开销和雪崩风险。而 volatile-lru 只作用于带过期时间的 key，等于主动放弃对核心关系数据的淘汰控制，实际失效。
- 现象：配置
volatile-lru后内存持续上涨，INFO memory显示evicted_keys为 0 - 原因：你没给关系 key 设过期时间，策略压根不触发
- 更糟的是：若为保策略生效而给所有关系 key 加
EXPIRE 86400，会引发定时删除线程（serverCron）密集扫描，CPU 升高，且过期时间统一导致批量失效（雪崩）
allkeys-lfu 是更匹配的起点
关系链天然存在强“二八效应”：TOP 0.1% 用户贡献超 70% 的读请求。allkeys-lfu 淘汰访问频次最低的 key，能自动沉淀出高频关系数据，比只看时间的 LRU 更抗突发流量干扰（比如某大V突然上热搜，其粉丝列表被集中拉取，lfu 不会因“刚加载进来”就淘汰它）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须调大
maxmemory-samples：默认值 5 太小，采样不准；生产建议设为 10–20，提升 LFU 计数器采样代表性 - 注意 LFU 衰减：Redis 默认每分钟对计数器衰减一次（
lfu-log-factor控制衰减粒度），避免历史热度长期绑架淘汰决策；若业务有明显日周期（如夜间低峰），可微调lfu-decay-time为 30（单位：分钟） - 验证方式：
OBJECT FREQ follow:1001查看当前频率计数，对比冷 key（如follow:999999）确认差距是否显著
混合策略：对长尾关系用 allkeys-random + 客户端兜底
对于新注册用户、沉默用户的关系数据，访问极少但又不能删（需保证数据一致性），allkeys-lfu 可能长期无法淘汰它们。此时可结合客户端逻辑做轻量分级：
- 写入时判断用户等级：新用户（注册 tail:（如
tail:follow:888888） - 用
redis-cli --scan --pattern "tail:*" | xargs redis-cli DEL每日凌晨清理一次（低成本，不影响在线服务） - 若仍需运行时淘汰，可单独起一个 Redis 实例配
allkeys-random存放长尾关系，与主实例隔离；随机淘汰对这类无访问规律的数据反而更公平，且无计算开销 - 切忌在主实例混用
allkeys-random：它不区分冷热，可能把刚查过的明星粉丝列表随机踢掉
真正关键的不是选哪个策略，而是承认关系链数据不能“一策管全量”。lfu 管热区，random 或定时脚本管冷区，而所有策略生效的前提，是 maxmemory 必须设为硬上限——否则内存无限增长，淘汰机制根本不会启动。
