allkeys-random策略在内存超限时随机删除任意key，适合一致性要求低的缓存场景；需先配置maxmemory，且不区分key是否设过期时间。
用 allkeys-random 策略让 Redis 自动随机删 key
Redis 本身不提供“手动随机删一批 key”的命令，但当你需要快速腾内存、又不想干预数据冷热逻辑时，allkeys-random 是最直接的解法——它会在内存超限时，从所有 key 中无差别随机挑选并删除。
这个策略不看访问时间、不看 TTL、也不管有没有过期时间，纯靠概率释放空间，适合缓存层对数据一致性要求不高、或写多读少且 key 生命周期难预测的场景（比如临时 token、会话快照、埋点中间态）。
-
CONFIG SET maxmemory-policy allkeys-random即刻生效，无需重启 - 必须先设置
maxmemory，否则该策略永不触发；例如：CONFIG SET maxmemory 2gb - 注意：如果业务依赖某些 key 的长期存在（比如配置项、开关标识），千万别混在同一个实例里用这个策略，容易误删
- 它和
volatile-random的关键区别是：后者只在带EXPIRE的 key 里随机删，前者连你SET没加过期时间的 key 都可能被干掉
想手动随机删？用 SCAN + DEL 组合更可控
如果你只是阶段性清理、或者想避开核心 key，不能全交给淘汰策略，就得自己动手。Redis 没有 RANDOMKEYS n 这种批量随机命令，但可以用 SCAN 游标分批拉 key，再用客户端逻辑随机采样后删。
例如在 redis-cli 中执行一次小范围随机清理（慎用于生产）：
redis-cli --scan --pattern '*' | shuf -n 100 | xargs -r redis-cli DEL
说明：
-
--scan比KEYS *安全，不阻塞主线程 -
shuf -n 100是 Linux 工具，随机取 100 个 key；Windows 可改用 PowerShell 的Get-Random - 务必先用
MEMORY USAGE查几个样本 key 的大小，避免一次删掉几个大 hash 导致内存抖动 - 别在高峰期间跑，
DEL是同步操作，大量 key 会短暂卡住请求
UNLINK 比 DEL 更适合批量清理
当你真要删几百上千个 key，尤其是其中包含 bigkey（如大 list、大 hash），用 DEL 会造成明显延迟——因为它得在主线程里把整个对象内存真正释放掉。而 UNLINK 会把释放动作丢给后台线程异步处理，主线程只做“逻辑删除”。
实操建议：
- 把上面的
xargs ... DEL改成xargs -r redis-cli UNLINK - 确认 Redis 版本 ≥ 4.0（
UNLINK是 4.0 引入的） - 注意：
UNLINK不影响淘汰策略行为，它只是优化了“手动删”的性能；淘汰策略触发的删除仍走原生逻辑 - 删完立刻看
INFO memory的mem_fragmentation_ratio，若飙升（>1.5），说明后台释放还没跟上，稍等片刻再观察
为什么不用定时任务定期 FLUSHDB？
有人图省事，写个脚本每小时跑一次 FLUSHDB，看似“随机清空”，实则风险极高。
问题不在随机性，而在破坏性：
-
FLUSHDB是原子性全删，期间所有对该库的读写都会排队等待，QPS 瞬间归零 - 它不区分 key 类型，连你用
HSET存的用户配置、ZADD做的排行榜都会消失 - 如果开了 AOF，还会刷出巨量
DEL日志，重放慢、体积大、恢复久 - 除非你在做完全隔离的测试库或临时计算库，否则这不是清理，是自毁
真正需要“定期清库”的场景，应该用命名空间（比如统一加 tmp: 前缀）+ SCAN 过滤 + UNLINK，而不是赌运气式地全盘端掉。
