[2026-07-04] [运维] [Redis 攻击流量识别与统计重置] - 清除攻击数据污染，恢复真实业务指标

IsaacZ

[2026-07-04] [运维] [Redis 攻击流量识别与统计重置] - 清除攻击数据污染，恢复真实业务指标

标签：Redis 统计重置 攻击流量 CC攻击 性能诊断 数据恢复

---

1、问题缘起与现象

在排查论坛性能时，发现 Redis 统计数据出现异常：

指标	异常值	说明
keyspace_misses	46.4 亿次	远超正常业务量级
keyspace_hits	2.7 亿次	被海量攻击请求稀释
hit（命中率）	5.5%	远低于正常水平（70%-90%）
mem_fragmentation_ratio	4.29	偏高

同时，雷池 WAF 日志显示近 24 小时总请求量高达 298.5k，拦截量 209.2k，拦截率超过 70%（此前一度达到一天200万的CC攻击流量）。大量被拦截的攻击请求仍在 Redis 层留下了统计痕迹——它们请求的 Key 不存在，导致 keyspace_misses 被疯狂累加，掩盖了真实的缓存命中率。

2、解决方案

（1）简要技术分析：

Redis 的 INFO 统计数据（keyspace_hits、keyspace_misses、total_commands_processed 等）是服务启动以来的累计计数器，无法通过常规命令“清空”。但 CONFIG RESETSTAT 命令可以重置所有运行时统计计数器，同时不影响 Redis 中存储的业务数据。

（2）操作命令：

1. redis-cli CONFIG RESETSTAT
   

复制代码

3、最终实现效果

指标	重置前（攻击污染）	重置后立即	几分钟后稳定	结论
keyspace_misses	46.4 亿	45	2,232	✅ 恢复正常业务水平
keyspace_hits	2.7 亿	168	15,745	✅ 真实业务命中
hit（命中率）	5.5%	78.87%	87.58%	✅ 健康且持续改善
mem_fragmentation_ratio	4.29	4.50	3.37	⬇️ 缓慢下降中
total_commands_processed	48.8 亿	195	13,676	✅ 反映当前真实流量

数据解读：

时间点	命中率	说明
重置前	5.5%	攻击流量掩盖，数据失真
重置后立即	78.87%	真实业务数据显现
几分钟后	87.58%	命中率持续回升，趋于稳定

misses 从 46.4 亿降至 2,232，hit 从 5.5% 升至 87.58%，两者结合印证了之前的低命中率完全是攻击流量造成的“数据污染”，而非缓存策略本身的问题。

4、重要技术沉淀

踩坑点：

踩坑	正确做法
攻击流量会“污染”Redis 统计数据	攻击停止后，执行 CONFIG RESETSTAT 恢复真实数据
用低命中率判断缓存策略失效	先排除攻击流量干扰，再评估缓存策略
CONFIG RESETSTAT 不清除业务数据	该命令仅重置统计，不影响 Redis 中的 Key，适合生产环境执行

关键结论：

• 攻击流量会产生大量无效 Redis 查询，即使被雷池拦截，misses 计数仍会被累加。
• 命中率恢复正常（87.58%）说明缓存策略本身是健康的，无需调整缓存配置。
• 内存碎片率（3.37）仍偏高，但较之前（4.50）有所下降，是攻击流量的遗留影响，待系统自然回收。
  

5、进一步优化可能性

• 如果攻击再次出现，可重复执行 CONFIG RESETSTAT 恢复统计数据
• 考虑在雷池 WAF 中优化 CC 防护策略，从源头减少无效请求
• 内存碎片率如果长期偏高，可在低峰期执行 MEMORY PURGE（需 Redis 4.0+）