Redis内存不够用怎么办？这几个办法帮你缓解压力别慌

别慌，这几乎是每个用Redis的人都会遇到的问题，服务器报警内存快满了，应用开始报错，这时候千万别手忙脚乱，我们先冷静下来，看看手里有哪些牌可以打，这些办法从简单到复杂，从“治标”到“治本”,你可以根据实际情况来选择。

第一招：先看看是谁吃掉了内存（知己知彼）

在动手之前，得先搞清楚内存到底被什么数据占用了，Redis自带了一个强大的命令叫 redis-cli --bigkeys（来源：Redis官方文档），这个命令会扫描整个数据库，帮你找出哪种数据类型的哪个key最大，你会发现，原来是一个存储了上百万成员的集合（Set）或者一个超级大的哈希（Hash）占了几百兆内存，知道了“罪魁祸首”,我们才能对症下药。

第二招：给数据设置“保质期”（TTL）

这是最简单也最有效的方法之一，很多数据并不是需要永久保存的，比如用户的登录会话（session）、手机验证码、临时的缓存数据等，在往Redis里存数据的时候，就给它设置一个过期时间（TTL），时间一到，Redis会自动把这些数据清理掉，释放内存，这就像给食物贴上保质期标签，避免它们一直放在冰箱里占地方，养成给缓存数据设TTL的好习惯，能从源头上避免大量内存浪费。（来源：普遍的最佳实践）

第三招：把大胖子数据拆成几个小瘦子（分而治之）

我们确实需要一个很大的数据结构，要存储全平台用户的在线状态，如果你把几千万用户的ID都塞进一个叫 online_users 的集合里，这个集合肯定会巨大无比，这时候，我们可以考虑把它拆开，按用户ID的最后一位数字，拆成10个集合：online_users:0, online_users:1 ... online_users:9，这样，每个集合的大小就变成了原来的十分之一，操作起来可能更快，也更容易管理，这种方法叫做分片（Sharding），只不过这是在业务层面自己手动分的。（来源：分布式系统常见设计模式）

第四招：换一种更节省空间的“打包方式”（优化存储）

Redis为了追求速度，在存储数据时并不是用最省空间的方式，但你可以通过一些配置来优化，在Redis的配置文件里，有一些叫做 hash-max-ziplist-entries、list-max-ziplist-entries 之类的配置项（来源：Redis官方文档关于内存优化的章节），当你的哈希表、列表等内部的元素数量小于某个值时，Redis会使用一种更紧凑的、类似压缩的格式来存储它们，虽然读取时会稍微多花一点点CPU时间，但能节省非常可观的内存，这就像你用真空压缩袋来装羽绒服，虽然打包时费点劲，但衣柜里能省出很多空间，如果你的业务场景中有很多小型的哈希或列表结构,调整这些参数效果会非常明显。

第五招：升级硬件，或者启用“淘汰策略”（终极手段）

如果上面的方法都用了，内存还是不够,那就得考虑更根本的办法了。

1. 升级硬件（简单粗暴）：最直接的办法就是给服务器加内存，虽然要花钱，但如果能快速解决问题,在业务初期也不失为一个好选择。
2. 配置淘汰策略（LRU/LFU）：这是Redis的一个重要功能，当内存达到你设置的上限时，Redis不会直接报错，而是会根据你设定的策略自动删除一些旧数据，常用的策略有：
   • allkeys-lru：尝试淘汰最近最少使用的键（LRU）,所有key都可能被删。
   • volatile-lru：只从设置了过期时间的key中淘汰最近最少使用的。
   • allkeys-lfu：淘汰最不经常使用的键（LFU，Redis 4.0以上支持）。
   • volatile-lfu：只从设置了过期时间的key中淘汰最不经常使用的。

你可以根据业务的容忍度来选，如果是纯缓存场景，数据丢了可以从数据库再读，那就用 allkeys-lru，如果有些关键数据绝对不能丢，那就用 volatile-lru 并确保这些关键数据不设过期时间，这个策略在Redis配置文件里用 maxmemory-policy 来设置。（来源：Redis官方文档关于maxmemory的配置）

第六招：搭建Redis集群（分布式解决方案）

当单个Redis实例的内存再怎么优化也撑不住时，就必须上分布式方案了，也就是Redis Cluster（Redis集群）（来源：Redis官方集群教程），集群的意思就是把你的数据分散到多个Redis服务器（节点）上，你可以用三台主服务器，每台负责存储整个数据集的其中一部分，这样，原本需要60G内存的单个实例，现在可以拆成三个20G的实例，横向扩展了总容量，搭建集群需要更多的机器和更复杂的管理,但这是应对海量数据的终极武器。

面对Redis内存压力，我们的武器库很丰富：从排查大Key、设置过期时间这类日常好习惯，到拆分数据结构、调整存储配置这些优化技巧，再到配置淘汰策略和最终的搭建集群，根据你的业务阶段和成本考量，选择最适合的组合拳,就能从容应对内存压力。