Redis容量满了咋整，数据爆满到底是啥情况该怎么办

（信息来源：Redis官方文档、运维社区常见问题讨论、技术博客经验分享）

Redis容量满了，简单说就是你这个“内存数据库”的内存被数据装满了，再也塞不进新东西了，这时候，任何试图写入新数据或更新现有数据的操作都会失败，并返回一个错误，这就像你的手机存储空间满了，没法再拍照或下载新应用一样，会直接导致依赖Redis的应用程序功能异常，比如用户无法登录、购物车加不了商品、热点数据无法缓存导致网站变慢等。

数据爆满到底是啥情况？

Redis把所有数据都放在服务器的物理内存里，当内存使用量达到你在配置文件里设置的 maxmemory 上限时，就“爆满”了，这时候，Redis会根据你预设的 maxmemory-policy（内存淘汰策略）来决定接下来怎么办，如果你压根没设置过这个策略，Redis的默认行为是拒绝所有可能导致内存增加的写命令,但读操作和删除操作通常还能继续。

爆满的根本原因是什么？

1. 数据自然增长：业务在发展，用户量、订单量、缓存的数据量都在稳步上升，日积月累，内存终究会被填满,这是最常见也最正常的原因。
2. 存在内存泄漏或无效数据：应用程序设置了大量的Key，但忘记了设置过期时间（TTL），导致这些Key成了“永久居民”，只进不出，或者，业务逻辑有问题，产生了大量不再使用的“僵尸Key”。
3. 不恰当的数据结构或大Key：用一个巨大的List或Hash来存储海量数据，这个Key本身就可能占几个GB，这种“大Key”不仅消耗内存，还会在操作时阻塞Redis进程，或者，用String类型存储一个复杂的对象,可能不如用Hash来得节省空间。
4. 瞬时流量冲击：比如一场大促活动，瞬间涌入了远超平时的数据和请求,短时间内把内存撑爆。

该怎么办？分几步走

第一步：紧急处理，先让服务恢复

当报警响起，发现Redis写不进去了,首先要做的是快速止血。

• 清理过期数据：立刻检查并手动删除一些非核心的、可丢弃的大Key，可以使用Redis自带的命令行工具，SCAN 命令配合 DEL 命令来查找和删除，但要注意,删除大Key可能会引起Redis短暂阻塞。
• 临时调整淘汰策略：如果当前策略是 noeviction（不淘汰，直接报错），可以临时通过命令行将其修改为更激进的策略，allkeys-lru（尝试淘汰最近最少使用的任何Key，包括没有设置过期时间的），命令是：CONFIG SET maxmemory-policy allkeys-lru，这能暂时允许新数据写入，但会牺牲掉一部分旧数据。注意：这只是临时方案，重启后会失效。
• 扩容：如果条件允许，最快最直接的办法就是给服务器加内存，或者在一个分布式环境中，将数据迁移到更大内存的节点上（例如在Redis Cluster中增加分片），这是“用钱换时间”的解决方案。

第二步：深入分析，找到根源并优化

紧急情况缓解后，必须找出根本原因,避免问题重复发生。

• 分析内存使用情况：使用 INFO memory 命令查看详细的内存信息，更关键的是，使用 redis-cli --bigkeys 命令（来自Redis官网工具）来扫描找出占用空间最大的那些Key,看看是不是存在设计不合理的大Key。
• 检查Key的过期时间：通过采样或脚本，检查有多少Key没有设置TTL，如果比例过高，说明你的应用程序在数据生命周期管理上存在问题，需要优化代码,确保缓存数据在不用后能自动过期。
• 优化数据结构：针对发现的大Key进行拆分，比如一个存了百万个字段的Hash，可以按一定规则拆分成多个小的Hash，对于String类型的大对象，考虑是否能用更节省空间的Hash、ZSet等结构来存储。
• 调整淘汰策略：根据业务特点，在配置文件中永久地设置一个合适的 maxmemory-policy，常见选择有：
  • volatile-lru：只从设置了过期时间的Key中淘汰最近最少使用的。
  • allkeys-lru：从所有Key中淘汰最近最少使用的（最常用）。
  • volatile-ttl：淘汰即将过期的Key。
  • 选择哪种策略，取决于你的数据中，哪些可以丢（如缓存），哪些绝对不能丢（如持久化会话）。

第三步：建立长效机制

• 设置监控告警：不要等内存100%了才行动，在内存使用率达到80%或90%时就应该收到告警,留出充足的时间去处理。
• 定期巡检：定期运行分析脚本，检查大Key、无过期时间Key的数量趋势,做到防患于未然。
• 代码规范：在开发层面制定规范，要求对缓存数据必须设置合理的过期时间,并避免产生大Key。

总结一下，Redis满了是个严重但可处理的问题，核心思路是：紧急时先扩容或清数据保服务，治标后必须分析内存使用、优化数据和设置，最后通过监控和规范来预防，Redis是一个缓存系统（即使你把它当数据库用），设计上就应该假设里面的任何数据都是可能丢失的,良好的数据生命周期管理是使用Redis的关键。