Redis的持久化方案与内存淘汰机制

Redis的持久化方案与内存淘汰机制

持久化方案

一.RDB

对redis中的数据执行周期性的持久化，通过配置文件中设置检查间隔时间与备份触发条件来对数据进行周期性的持久化（默认开启）
优点：
1.RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备份。
2.RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可
3.相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速

缺点：
1.如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多
2.RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的
配置方法
redis.conf文件，去配置持久化
save 60 1000
每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting（快照）
也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成。（save在生成dump.rdb文件的时候redis主线程将会被阻塞，bgsave则不会阻塞redis主线程）
save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有，就生成一个新的dump.rdb文件

二.AOF

AOF机制对每条写入命令作为日志记录，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。（默认关闭）
优点：
1.AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作（fsync的功能是确保所有已修改的内容已经正确同步到硬盘上，该调用会阻塞等待直到设备报告IO完成。），最多丢失1秒钟的数据每隔1秒，就执行一次fsync操作，保证oscache中的数据写入磁盘中redis进程挂了，最多丢掉1秒钟的数据。
2.AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
3.AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewritelog的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
4.AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
缺点：
1.对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
2.AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件。尽管每秒一次fsync，性能也还是很高的，如果你要保证一条数据都不丢，也是可以的，AOF的fsync设置成没写入一条数据，fsync一次，那就完蛋了，redis的QPS将会更低。
3.以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
4.唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适。RDB恢复日志，就是一份数据文件，恢复的时候，直接加载到内存中即可。而AOF则不同，做数据恢复的时候，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据的。
如何配置redis的AOF持久化
AOF持久化，默认是关闭的，默认是打开RDB持久化
appendonly yes，可以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非你说随便丢个几分钟的数据也无所谓。打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再fsync一下。
如果AOF和RDB都开启了，redis重启的时候，优先通过AOF进行数据恢复的，因为aof数据比较完整
可以配置AOF的fsync策略，有以下三种策略可以选择：
always: 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，那就只能这样了
everysec: 每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的
no: 仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了

redis的内存淘汰机制

定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

Redis中同时使用了惰性过期和定期过期两种过期策略。

内存淘汰机制

volatile-lru：使用LRU算法移除key，只对设置了过期时间的key；
从已设置过期时间的数据集中挑选最近最少使用的数据淘汰

allkeys-lru：使用LRU算法移除key，作用对象所有key；
从数据集中挑选最近最少使用的数据淘汰

volatile-random：在过期集合key中随机移除key，只对设置了过期时间的key;
从已设置过期时间的数据集中任意选择数据淘汰

allkeys-random：随机移除key，作用对象为所有key；
从数据集中任意选择数据淘汰

volarile-ttl：移除哪些ttl值最小即最近要过期的key；
从已设置过期时间的数据集中任意选择数据淘汰

no-eviction（放逐）：永不过期，针对写操作，会返回错误信息。
禁止驱逐数据，新写入操作会报错