查看redis缓存大小_一个 bug 引发了服务器崩溃，对应 redis 的 key 回收原理你清楚了吗？...

1 背景

项目中使用了 redis 做旁路缓存。读请求到来时，有以下操作：1.检查缓存，有则返回2.没有则读取数据库，将结果回写到缓存中。

写请求到来时，有以下操作：1.更新数据库 2.更新缓存(实际上删缓存更合适，具体参见高并发场景下，到底先更新缓存还是先更新数据库)。

使用该方案 redis 正常运行，一段时间后，服务器宕机，提示 aborted core dumped 错误。

2 问题排查

问题定位

错误提示明显的定位了错误位置，根据提示找到相关代码

 await  client.setAsync(key,JSON.stringfy(value));

原来是在 redis 写入时引发的，那就先查看下内存占用情况。

检查内存

 info memory

输出结果很长，就不一一展开了。这里面有几个关键指标：

used_memory :当前 redis 使用内存大小。这部分内存包含 redis 内部开销和数据占用的内存。单位是字节(byte)，由 redis 分配器分配
used_memory_rss :向操作系统申请的内存大小，即 redis 使用的物理内存大小。这个值和 top 、ps 命令得到的结果一致。
mem_fragmentation_ratio :内存碎片率，ratio = used_memory_rss/used_memory。通常 used_memory_rss 会稍高于 used_memory。ratio 指数>1表明有内存碎片，越大表明越多，ratio 指数<1表明正在使用虚拟内存，虚拟内存其实就是硬盘，性能比内存低得多，这是应该增强机器的内存以提高性能。一般来说，ratio 的数值在1 ~ 1.5之间是比较健康的。

查看 key 回收策略

首先了解 redis 控制 key 回收策略的配置项：maxmemory-policy。它的作用是：当内存占用到达最大限制时，redis 会根据设定的回收策略移除 keys。命令行查看memory-policy:

  config get maxmemory-policy

得到结果是 "noeviction"，noeviction 是默认值，表示禁止淘汰数据。

当内存到达上限后，如果调用了 set、lpush 等需要占用内存的命令，noeviction 策略则会返回 error。

noeviction 策略一般使用情况如下：

使用 redis 作为 LRU 或者 LFU 缓存
对一个实例设置了严格的内存限制

3 解决方法

查看了内存占用情况和 key 回收策略，可以判断，这是由于 redis 中 key 占用内存过大，并且没进行回收，导致内存占满崩溃。

因此解决方案从这两个角度入手：

增大 redis 内存上限

maxmemory 默认是0，不限制最大内存。64位系统是不限制内存的，32位系统最多使用3GB内存。一般推荐 redis 内存设置为最大物理内存的一半

命令行设置：(当前实例无需重启，立即生效)
```
 config set maxmemory 1024
```
更改 redis.config (实例重启后生效)
```
 maxmemory 1024
```
设置 key 回收策略

redis 有以下回收策略：
- volatile-lru -> 使用 LRU 算法删除(范围：设置了生存时间的键)
- allkeys-lru -> 使用 LRU 算法删除键(范围：所有键)
- volatile-lfu -> 使用 LFU 算法删除(范围：设置了生存时间的键)
- allkeys-lfu -> 使用 LFU 算法删除键(范围：所有键)
- volatile-random -> 随机删除一个键(范围：设置了生存时间的键)
- allkeys-random -> 随机删除一个键(范围：所有键)
- volatile-ttl -> 删除生存时间最近的一个键
- noeviction -> 不删除，直接在写操作时返回错误(默认)

一般使用 volatile-lru 和 allkeys-lru 算法居多，LRU 是最近最久未使用算法。但它不是精准的 LRU 算法。

实际上，redis 为了节省内存，使用了 合适的LRU 算法。具体实现是：采样5个 key，通过 LRU 算法获得最近最久未使用的 key 并回收。采样大小可通过 maxmemory-samples 调整，默认是5.

注意：设置了 key 回收策略，不代表不会报错。当没有合适的 key 回收时，redis 同样会返回错误。

4 写在最后

服务器出现了崩溃，定位错误为 redis 的 set 操作。解决方案则是：增大 redis 内存上限或者设置 key 回收策略。

实际上，错误背后反应的是 redis 的内存管理机制。而除了 key 回收，redis 内存管理还有过期删除机制。其内部实现使用的是惰性删除和定期删除。(不在本文讨论范围内，有时间会另写一篇文章~)

随着 redis 使用的深入，其背后的原理面纱也一层层揭开。Daemon 的心得是：结合实际遇到的问题，再针对性的查看原理性知识，成长会更快~

大家如果有什么疑问或者其他任何事情，欢迎添加 Daemon 的个人微信号交流~