Redis内存爆满主因是业务接口批量生成无TTL垃圾Key，需在防火墙层限流新建连接并绑定127.0.0.1监听，禁用公网暴露与弱密码。
Redis 内存爆满真因常不在 Redis 本身
内存突然打满，90% 的情况不是攻击者直接往 Redis 写数据，而是通过业务接口（比如注册、登录、搜索）批量生成垃圾 Key——这些 Key 没设 TTL、没做校验、甚至带随机后缀，最终堆积成百万级无用数据。Redis 自身没有 IP 访问控制能力，redis.conf 里也找不到 allow-ip 或 rate-limit 这类配置项。真正该拦的地方，是网络层。
firewalld 限制单 IP 连接数防 CC 式灌入
攻击者常用脚本高频调用你的 API 接口，背后就是大量 TCP 连接打到 Redis 所在服务器的 6379 端口（或你自定义的端口）。这时靠 Redis 的 maxmemory 和淘汰策略完全来不及响应——Key 已经写进去了，内存已涨了。
必须在连接建立前就卡住。用 firewall-cmd 配合 rich rule + limit 实现：
-
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.100' port port='6379' protocol='tcp' limit value='5/minute' accept"—— 允许该 IP 每分钟最多建 5 个新连接 -
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.100' port port='6379' protocol='tcp' reject"—— 超限后直接拒绝（比drop更利于排查） - 务必加
--permanent，否则重启失效；执行完别忘了firewall-cmd --reload - 注意：该规则只限制「新建连接」，不阻断已有长连接；若业务本身用连接池，建议把
limit值设为连接池最大连接数 × 1.5 倍，留出余量
为什么 volatile-lru / volatile-ttl 在这种场景下基本失效
很多团队看到内存涨，第一反应是把淘汰策略改成 volatile-lru 或 volatile-ttl，结果发现毫无改善——因为灌入的垃圾 Key 大多没设置过期时间。
此时 volatile-* 类策略退化为 noeviction，Redis 直接拒绝后续写入，服务开始报 (error) OOM command not allowed when used memory > 'maxmemory'。
真正有效的组合是：
- 强制所有业务写入 Key 必须带 TTL（后端代码层兜底，非可选）
- Redis 配置改用
maxmemory-policy allkeys-lfu（Redis 4.0+），它对所有 Key 生效，且 LFU 比 LRU 更难被随机写入绕过 - 配合定时扫描：
redis-cli --bigkeys --memtier 1024查出单 Key >1MB 的异常项，再人工确认是否为攻击产物
别忽略防火墙与 Redis 的端口暴露面
生产环境 Redis 绝对不能监听 0.0.0.0:6379 并开放给公网。哪怕加了密码，也挡不住暴力破解和协议层探测。
检查当前暴露面：
- 运行
ss -tlnp | grep :6379，确认Local Address:Port是127.0.0.1:6379还是*:6379 - 若为后者，立刻改
redis.conf中的bind行：改为bind 127.0.0.1 ::1（禁 IPv6 外网也可加::1） - 再用
firewall-cmd --list-all确认 6379 端口是否在ports列表里——如果出现，说明防火墙正在放行，必须删掉：firewall-cmd --permanent --remove-port=6379/tcp - Redis 只应被同机部署的应用访问；跨机器访问必须走内网代理或 Service Mesh，而非直接开防火墙端口
最危险的配置，是 bind 写了 0.0.0.0，又没配防火墙规则，还用了弱密码——等于把钥匙挂在门把手上。
