不能。maxmemory与allkeys-lru是内存耗尽后的兜底机制，非防刷第一道防线；恶意刷接口会快速写入大量新key，导致lru近似算法失效、cpu飙升、oom或雪崩，需结合前置限流、强制ttl、节点隔离与监控告警分层防护。
Redis单节点上配置maxmemory和allkeys-lru就能防刷？
不能。maxmemory 和 maxmemory-policy allkeys-lru 是内存耗尽后的兜底机制，不是防刷的第一道防线。恶意刷接口会快速写入大量键（比如用随机key塞缓存），即使开了 allkeys-lru，Redis 仍需先接收、解析、存储、再淘汰——这个过程本身就会吃 CPU、带宽和内存碎片，可能在淘汰生效前就触发 OOM Killer 或连接雪崩。
为什么必须为每个集群节点单独设maxmemory？
Redis 集群中每个 master 节点是独立的 Redis 实例，不共享内存或淘汰逻辑。你看到的 redis-cli -c 是客户端分片代理，它不会帮你统一设置内存策略。
-
CONFIG SET maxmemory只作用于当前连接的节点，对其他节点完全无效 - 集群节点间不会同步
maxmemory值，哪怕你只漏配一个节点，它就可能成为内存黑洞 -
INFO memory返回的used_memory是单节点指标，全局内存用量 = 所有 master 节点之和
allkeys-lru 在刷量场景下容易失效的三个事实
allkeys-lru 看似“全量淘汰”，但在高频写入无 TTL 的恶意请求下，实际效果远不如预期：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Redis 的 LRU 是近似算法（采样 5 个 key 比较 idle 时间），不是精确排序，高并发写入时容易漏掉真正冷数据
- 如果刷的全是新 key（如
cache:uuid4()），所有 key 的 idle 时间都极短，LRU 会随机淘汰，命中率骤降 - 淘汰动作发生在写入路径上，每写一个新 key 都可能触发一次淘汰检查，CPU 使用率飙升，反而加剧服务延迟
真正有效的组合防护措施
仅靠 maxmemory + allkeys-lru 不足以应对恶意刷量。你需要分层控制：
- 前置限流：在 API 网关（如 Nginx、Kong）或应用层用令牌桶/滑动窗口限制单 IP / 用户的写请求频次
- 强制 TTL：业务代码写入时必须带
EX或PX，避免无过期时间的 key 沉淀；配合volatile-lru更可控 - 节点级硬隔离：给不同业务分配不同集群或不同 Redis 实例，防止一个接口刷爆影响全局
- 监控响应：用
INFO memory中的mem_fragmentation_ratio和evicted_keys做告警阈值，evicted_keys突增就是刷量信号
最常被忽略的一点：maxmemory 限制的是 used_memory，但实际 RSS 内存可能高出 30%~50%（因 jemalloc 分配器碎片）。线上配置时，务必预留 buffer，比如物理内存 16GB，单节点 maxmemory 最多设 10GB。
