allkeys-lru 是突增场景下的默认安全选择，因其对所有 key 统一按访问时间淘汰，不依赖 TTL，适配新 key 涌入、冷数据待清的特征，避免 OOM 和缓存击穿。
流量突增时，Redis 不会自动“聪明地”保留热点数据——它只按你配置的 maxmemory-policy 执行淘汰，策略选错，突增流量反而会加速缓存击穿。
为什么 allkeys-lru 是突增场景下的默认安全选择
突增流量往往带来大量新 key（比如临时 session、活动页商品 ID、短时效 token），同时老的冷 key 仍占内存。如果用 volatile-lru，而这些新 key 没设过期时间，就完全不会被纳入淘汰候选集，内存持续打满，写操作开始报 OOM command not allowed 错误。
-
allkeys-lru对所有 key 统一按最近访问时间排序，能快速腾出空间给新请求，天然适配“热数据集中、冷数据待清”的突增特征 - 它不依赖 TTL 设置，避免因业务漏设过期时间导致淘汰失效
- Redis 的近似 LRU 实现（抽样
maxmemory-samples默认 5）在高并发下响应快，不会因遍历全量 key 阻塞主线程
allkeys-lfu 在长期突增中可能更稳，但要注意频率统计延迟
如果突增不是秒级脉冲，而是持续数小时的“高热+长尾”模式（如直播开播后前 2 小时），allkeys-lfu 比 LRU 更擅长识别真正高频访问的 key。但它有个硬伤：LFU 计数器衰减机制默认每分钟一次，且访问频次更新有概率丢失（尤其在极高峰值下），刚涌入的 key 可能因计数未累积就被误删。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 若要用
allkeys-lfu，建议调大lfu-log-factor（比如设为 10）降低计数敏感度，避免毛刺干扰 - 必须配合
maxmemory-samples调高（如 10），否则抽样偏差会导致淘汰偏离真实热度 - 注意：LFU 在 Redis 4.0+ 才支持，低版本直接忽略该策略
绝对不能在突增期间用 volatile-ttl 或 noeviction
volatile-ttl 看似“清理快过期的”，但在突增时，大量新 key 若没设 TTL 或设了长 TTL（如 24h），就会卡住淘汰逻辑——Redis 只在带过期时间的 key 里找，结果一个都找不到，最终退化成 noeviction 行为，写操作全部失败。
-
noeviction在突增时等于主动拒绝服务，除非你业务层已做好降级兜底（比如直连 DB），否则就是雪崩起点 - 哪怕只有一部分 key 设了 TTL，
volatile-random和volatile-lru也面临同样风险：候选集太小，淘汰效率低下 - 线上已出现过案例：促销页大量商品 key 未设 TTL，搭配
volatile-lru，突增 3 分钟后内存 100%，写入成功率跌至 12%
maxmemory 必须显式设置，且预留缓冲空间
没设 maxmemory 的 Redis 会一直吃内存，直到被系统 OOM Killer 杀掉——这比淘汰还致命，进程直接消失。
- 建议值 = 当前稳定内存占用 × 1.3～1.5，例如日常用 3GB，就设
maxmemory 4gb - 别用字节单位硬编码（如
maxmemory 4294967296），易读性差且容易算错 - 配合
maxmemory-policy allkeys-lru一起写进redis.conf，不要靠 CONFIG SET 临时改——重启后策略丢失
淘汰策略本身不解决突增，它只是让 Redis 在内存压线时“怎么丢数据”这件事变得可控。真正关键的是：策略必须匹配你的 key 生命周期特征，而不能只看文档里的推荐排名。
