allkeys-random 会无差别随机删除任意 key，不区分冷热或业务重要性，只快速腾出空间但无法预测被删对象；它作用于全量 key（含无 ttl 的），与 volatile-random 有本质区别；不记录被删 key，触发时仅删一个 key，释放内存呈“滴漏式”；对医疗、金融等强一致性场景，应选用 noeviction 策略。
allkeys-random 会无差别删除任意 key，不区分冷热或业务重要性
这个策略在内存满时直接随机挑一个 key 删除，完全不看访问时间、使用频次或是否带过期时间。它只做一件事：快速腾出空间。但代价是——你无法预测哪个 key 会被删掉。allkeys-random 不会跳过 set 类型的计数器、hash 存的用户配置、甚至正在被下游服务轮询的实时状态 key。只要 Redis 认为“该删了”，就可能一击命中关键数据。
和 volatile-* 策略混用时容易误判淘汰范围
很多人以为 allkeys-random 和 volatile-random 行为类似，只是范围不同，实际不是。前者真·全量池子（包括没设 EXPIRE 的 key），后者只在带 TTL 的 key 里抽签。如果你的应用里大部分 key 都没设过期时间（比如用 Redis 做持久化 session 或配置中心），那 allkeys-random 实际上等效于“随机删生产数据”，而 volatile-random 可能根本删不到几个 key —— 因为压根没多少带 TTL 的。
触发时机不可控，且不反馈被删 key 的信息
Redis 在执行 allkeys-random 时不会告诉你删了谁，也不会记录日志（除非开启 slowlog 或 MONITOR）。这意味着：
- 你无法事后追溯某条业务数据为何突然消失
- 没法做针对性监控（比如“某类 key 被删频率异常”）
- 故障排查只能靠猜：是客户端写错？还是刚好被随机抽中？
更麻烦的是，它只在每次写入触发淘汰时才删一个 key，不是批量清理，所以内存释放是“滴漏式”的，压力持续存在但难以感知。
noeviction 才是数据强一致性场景的底线选择
医疗、金融、订单状态等场景下，宁可写失败，也不能让关键 key 被随机抹掉。这时候必须把 maxmemory-policy 显式设为 noeviction，配合 maxmemory 限容。哪怕应用层收到 (error) OOM command not allowed when used memory > 'maxmemory'.，也比静默丢数据安全得多。很多团队踩过坑：把 allkeys-random 当成“兜底方案”，结果发现缓存穿透+随机淘汰一起发生，最终压垮数据库。
