Q：Redis过期策略

A：设置过期时间

expire key time(以秒为单位)--这是最常用的方式

setex(String key, int seconds, String value)--字符串独有的方式

如果设置了过期时间，之后又想让缓存永不过期，使用persist key

三种过期策略

定时删除

含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除

优点：保证内存被尽快释放

缺点：

若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key

定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重

没人用

惰性删除

含义：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。

优点：删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了）

缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）

定期删除

含义：每隔一段时间执行一次删除过期key操作

优点：

通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用--处理"定时删除"的缺点

定期删除过期key--处理"惰性删除"的缺点

缺点

在内存友好方面，不如"定时删除"

在CPU时间友好方面，不如"惰性删除"

Redis采用的过期策略：惰性删除+定期删除

惰性删除流程

在进行get或setnx等操作时，先检查key是否过期，

若过期，删除key，然后执行相应操作；

若没过期，直接执行相应操作

定期删除流程（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期key）

遍历每个数据库（就是redis.conf中配置的"database"数量，默认为16）

检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述）

如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历

随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key

判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。

Q：内存淘汰策略(如何保证redis中的数据都是热点数据)?

A：达到最大内存限制时(maxmemory), Redis 根据 maxmemory-policy 配置的策略, 来决定具体的行为

当前版本,Redis 3.0 支持的策略包括:

noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。 大多数写命令都会导致占用更多的内存(有极少数会例外, 如 DEL )。

allkeys-lru: 所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。

volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。

allkeys-random: 所有key通用; 随机删除一部分 key。

volatile-random: 只限于设置了 expire 的部分; 随机删除一部分 key。

volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。

noeviction ： 禁止驱逐数据,永不过期，返回错误

如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

Q：持久化机制

A：RDB/AOF

如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。

写时复制（copy-on-write）策略：在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令 ），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork那一刻的内存数据。

RDB：当符合一定条件时Redis会自动将内存中的所有数据进行快照，并且存储到硬盘上，当在指定时间内被更改的键的个数大于执行数值时，就会进行快照。RDB是Redis的默认持久化方式。

RDB配置：

redis.conf 

save 900 1 900秒至少有1个键被更改则进行快照

save 300 10 300秒至少有10个键被更改则进行快照

save 60 10000 60秒至少有1W个键被更改则进行快照

多个save之前是或的关系

stop-writes-on-bgsave-error(默认yes)：当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据

rdbcompression(默认yes)：存储到磁盘中的快照，是否压缩存储，是的话，redis会采用LZF算法进行压缩。会消耗CPU资源

rdbchecksum(默认yes)：在存储快照后，redis是否用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

dir：rdb文件存放路径(默认是当前目录)

dbfilename：文件名(默认dump.rdb)

关闭RDB配置：

注释掉所有的 save 行或设置一个空字符串来实现停用：save ""

手动触发RDB持久化的命令：

　　1、save：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

　　2、bgsave：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

　　基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

　　ps:执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的.

恢复数据：

将备份文件 (dump.rdb) 移动到 redis 安装目录(获取 redis 的安装目录可以使用 config get dir 命令)并启动服务，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

RDB对过期key的处理：

过期key对RDB没有任何影响

从内存数据库持久化数据到RDB文件

持久化key之前，会检查是否过期，过期的key不进入RDB文件

从RDB文件恢复数据到内存数据库

数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）

AOF(appendOnly file)：将所有的写命令按照一定频率写入到日志文件中，当Redis停机重启后恢复数据库

开启AOF配置：

表示是否开启AOF持久化：

　　appendonly yes(默认no,关闭)

AOF持久化配置文件的名称：

　　appendfilename “appendonly.aof”

AOF持久化策略(默认每秒)：

　　appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)

　　appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)

　　appendfsync no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）

AOF的Rewrite(重写) ：

　　定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制

　　当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

　　　　　auto-aof-rewrite-percentage 100 （一倍）

　　　　 auto-aof-rewrite-min-size 64mb

AOF配置文件损坏修复方法：

　　进入redis安装路径 执行 redis-check-aof –fix AOF配置文件名称

配置 Redis 将数据 fsync 到磁盘频次:

每次有新命令追加到 AOF 文件时就执行一次 fsync(非常慢，也非常安全)。

每秒 fsync 一次；足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。

从不 fsync ；将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

如果 AOF 文件出错了，怎么办：

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。

当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

为现有的 AOF 文件创建一个备份。

使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。

$ redis-check-aof --fix

（可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。

重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

aof文件占用过大(重写):

随着AOF文件越来越大，里面会有大部分是重复命令或者可以合并的命令（100次incr = set key 100）

Redis Bgrewriteaof 命令用于异步执行一个 AOF（AppendOnly File） 文件重写操作。重写会创建一个当前 AOF 文件的体积优化版本。

即使 Bgrewriteaof 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改。

注意：从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作。

Redis Bgrewriteaof 命令基本语法如下：

# redis-cli -p 6379 -h 127.0.0.1

127.0.0.1:6379> BGREWRITEAOF

redis 127.0.0.1:6379> Background append only file rewriting started

AOF 重写的执行步骤：Redis 执行 fork() ，现在同时拥有父进程和子进程。

子进程开始将新 AOF 文件的内容写入到临时文件。对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

AOF对过期key的处理：

过期key对AOF没有任何影响

从内存数据库持久化数据到AOF文件：

当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入aof文件的，因为没有发生修改命令）

当key过期后，在发生删除操作时，程序会向aof文件追加一条del命令（在将来的以aof文件恢复数据的时候该过期的键就会被删掉）

AOF重写

重写时，会先判断key是否过期，已过期的key不会重写到aof文件