Redis内存使用和管理

Redis内存使用和管理

一家深圳做门禁的上市公司，它的REDIS数据库内存OMM了！招了个低薪的运维工程导致的。只是会搭起来就说精通REDIS数据库！

不知道配maxmemory参数和maxmemory-policy参数。

一切都是默认值。。。

maxmemory-policy 参数表示内存使用策略！当到达最大内存时候该怎么办？

Redis支持6种策略，如下所示：

1）noeviction：默认策略，数据永不过期，不会删除任何数据，当内存不足以容纳新写入数据时，新写入操作会报错，一般不推荐使用。

2）volatile-lru：根据LRU算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。

3）allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。一般推荐使用该策略

4）allkeys-random：内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。

5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。

6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。如果没有，回退到noeviction策略。

内存溢出控制策略可以采用config set maxmemory-policy{policy}动态配置。

Redis默认是无限使用内存的，所以防止系统内存被耗尽，需要对Redis的内存上限进行设置，Redis使用maxmemory参数限制最大可用内存。maxmemory配置的是Redis实际使用的内存量，也就是used_memory统计项对应的内存。由于内存碎片率的存在，实际消耗的内存可能会比maxmemory设置的更大，实际使用时要小心这部分内存溢出。根据惯例一般会预留出20%的服务器空闲内存防止内存溢出通过。Redis的内存上限可以通过config set maxmemory进行动态修改。

Redis提供查看内存的指令为info memory。

要重点关注的指标有：used_memory_rss和used_memory以及它们的比值mem_fragmentation_ratio。

当mem_fragmentation_ratio>1 时，说明used_memory_rss-used_memory多出的部分内存并没有用于数据存储，而是被内存碎片所消耗，这个值越大，表明内存碎片越多。

当mem_fragmentation_ratio<1 时，这种情况说明正在使用虚拟内存，也就是在使用主机的硬盘，由于硬盘性能是远远低于内存的，所以要小心因为性能问题导致整体Redis故障。根据日常使用的情况mem_fragmentation_ratio的数值在1 ~ 1.5之间是比较健康的。

在出现内存碎片过多的问题怎么处理呢？在Redis5.0版本之后支持在运行期进行自动内存碎片清理，主要通过设置config set activedefrag yes来进行实现，同时也提供了memory purge命令来手动进行内存碎片清理。

Redis采用惰性删除和定时任务删除机制实现过期键的内存回收。

惰性删除：惰性删除用于当客户端读取带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空。

定时任务删除：Redis内部维护一个定时任务，默认每秒运行10次，Redis会周期性的随机测试一批设置了过期时间的key并进行处理。

有用户通过定期执行info命令监视redis的状态，这会在一定程度上导致CPU占用偏高。频繁执行info时通过perf分析发现

getClientsMaxBuffer,

getClientOutputBufferMemoryUsage

getMemoryOverheadData

这几个函数占用CPU比较高。

所以在很多链接下不要频繁执行INFO命令

有用户发现在使用pipeline做只读操作时，redis-server的内存容量偶尔也会出现明显的上涨, 这是对pipeline的使不当造成的

redis-server端从接收到的内容依次解析出命令、执行命令、将执行结果缓存到replyBuffer中，并将用户端标记为有内容需要写出。等到下次事件调度时再将replyBuffer中的内容通过socket发送到client，所以并不是处理完一条命令就将结果返回用户端。

使用pipeline时，要及时接收请求处理结果，且pipeline不宜一次打包太多请求。

尽量不要使用短连接；使用链接池解决问题