一、redis的三种删除策略：
1、被动删除：在上一章中已经提到过，dbsize中获得key个数包含过期的key，只有在key再次被操作的时候，redis才会去检测该key是否已经过期，如果过期则将它删除，这对于cpu来说，能节约出删除该key的时间来；但是对于内存来说，假如该key一直甚至永远不被调用的话，它将一直占着内存，当这种key越来越多的时候，内存会被这种可以称得上是垃圾key占满，对于吃内存的redis而言，无疑是一场噩梦。
2、主动删除：主要由redis.c/serverCron来实现，作为时间事件来进行，每隔一段时间就会自动运行一次，serverCron 会一直定期执行，直到服务器关闭为止。配置文件中的hz就是用来配置这个的频率的，默认是10，表示serverCron每秒执行10次。
主要作用：（参考别人的）
- 更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等
- 清理数据库中的过期键值对
- 对不合理的数据库进行大小调整
- 关闭和清理连接失效的客户端
- 尝试进行 AOF 或 RDB 持久化操作（下面会讲）
- 如果服务器是主节点的话，对附属节点进行定期同步
- 如果处于集群模式的话，对集群进行定期同步和连接测试
注意：hz调大将会提高Redis主动淘汰的频率，如果Redis存储中包含很多冷数据占用内存过大的话，可以考虑将这个值调大，但Redis作者建议这个值不要超过100。我们实际线上将这个值调大到100，观察到CPU会增加2%左右，但对冷数据的内存释放速度确实有明显的提高。
3、maxmemory 删除：当前已用内存超过maxmemory限定时，将会触发。有6策略：
- volatile-lru：只对设置了过期时间的key进行lru算法的出来的key（默认值）
- allkeys-lru ： 删除lru算法的key
- volatile-random：随机删除即将过期key
- allkeys-random：随机删除key
- volatile-ttl ： 删除即将过期的key（离过期时间最少的那个）
- noeviction ： 永不过期，返回错误
注意：配置文件中 maxmemory-samples配置的是随机抽取数，默认值是5。
总结：随机从所有key中抽取maxmemory-sample中配置的值个数，然后进行以上6中删除策略中的一种进行删除某个key。
二、redis的二种持久化策略：
1、rdb：redis database 或者叫快照（snapshotting）
什么是rdb：
在指定的时间间隔内，将内存中的数据集快照写入磁盘中，也就是行话讲的snapshot快照，它恢复时是将快照文件直接读到内存里。
redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何io操作的，这就确保了极高的性能。
fork的作用：
复制一个与当前进程一样的进程，新进程的所有数据（变量，环境变量，程序计数器等）数组都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
rdb保存文件：dump.rdb
rdbcompression：
默认是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储，如果是的话，redis会采用lzf算法进行压缩。如果不想消耗cpu来进行压缩的话，可以设置为no来关闭此功能。
rdbchecksum ：
默认是yes。在存储快照后。还可以让redis使用crc64算法来进行数据校验，但是这样会增加大约10%的性能消耗，如果希望获得最大的性能提升，可以关闭此功能。
stop-writes-on-bgsave-error：
默认是yes，即备份出现错误的时候，禁止存储；也可配成no，表示你不在乎数据不一致或者有其他手段发现和控制。
三种快照配置：
- after 900 sec (15 min) if at least 1 key changed—–900秒内只要有一个key改变就自动存储一个rdb
- after 300 sec (5 min) if at least 10 keys changed—–300秒内，只要有10个key被改动（除了查询的操作）就自动给你存
- after 60 sec if at least 10000 keys changed—60秒改动10000次key就回存储一个rdb
注意：
1、save “”—表示禁用。
2、如果不想等那么久（15分钟），想立即生效的话，可以使用save和bgsave。
save：只管保存，其他不管，全部阻塞，即保存完了才能做其他操作—我在保存的时候别打扰我
bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间。
3、flushall、flushdb、shoutdown会清空缓存，并直接生成dump文件。
rdb的优势 ：
1、适合大规模的数据恢复，且对于数据恢复的完整性不是非常敏感
2、效率比aof高
3、如果要恢复的话，我只要恢复最后一个rdb即可，文件比较紧凑
4、rdb在保存rdb文件时，父进程唯一需要做的只有fork一个子进程。其他事情都由子进程来做，父进程不需要再做其他io操作，所以rdb持久化可以最大化redis的性能
rdb的劣势 ：
1、在一定间隔时间做一次备份，假如刚好在备份那个时间点，除了故障，则会丢失最后一次持久化数据
2、fork的时候，北村中的数据被克隆了一份，大致2倍的膨胀性需要考虑
2、aof：append only file 或者叫文件追加
什么是aof：
以日志的形式来记录每个写操作，将redis执行过程所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取改文件重新构建数据，换言之，redis重启的话，就根据日志文件的内容，将写指令从前到后执行一次，以完成数据的恢复工作。
用一句话概括就是：走一步记录一步（除了读操作），当redis重启的时候就重新根据记录演绎一遍。
appendonly：这个参数默认是no，即默认是不打开aof的，设置为yes即可。
appendfilename：aof文件名字设置，默认的是：appendonly.aof
aof的持久化策略：
- always：同步持久化，每次发生数据变化会被立即记录到磁盘，性能较差，但是数据完成性比较好.
- everysec：出厂默认设置，异步操作，每秒记录，如果一秒内关机，有数据丢失
- no：表示不持久化
aof的持久化恢复测试：
开始的时候没有aof文件
向redis存一个值，然后关闭redis
然后我们再看redis目录，多了一个.aof文件
打开aof文件，记录了redis刚才存储的a这个key的记录。
为了证明aof文件能恢复数据，我们先把.rdb文件删除
然后我们在打开redis，获取刚才设定的a这个key
思考：如果rdb和aof文件同时存在，那么按照那个优先来恢复数据呢？
首先证明这两个是可以同时存在的
我们再次关闭服务器
然后将aof文件乱写一通，然后保存，然后重启服务器，如果redis能重新启动，则首先找的是dump，如果redis不能启动，那首先找的就是aof
发现aof是损坏的文件，redis无法启动
结论：aof的优先级比rdb高，还有就是如果数据库被flushall之后，只要打开aof文件，删除最后的那个flushall操作即可恢复所有数据
修复aof文件：redis-check-aof.exe - - fix aof文件名字
问题：为啥没有redis-check-dump.exe这个exe？？？
aof的rewrite（重写）：
rewrite是什么：aof采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当aof文件的大小超过所设定的阈值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof（redis2.4之后引入的）
rewrite的触发机制：redis会记录上次重写的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍（100%）且文件大于64M（这个值一般生产环境中配5G以上）
rewrite的原理：aof文件持续增长而过大时，会fork出一条新进程，将文件重写（也就是先写临时文件最后再rename），遍历新进程的内存中的数据，每条记录有一条的set语句，重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写一个新的aof文件，这点和快照有点类似
no-appendfsync-on-rewrite：重写时，是否可以运用appendfsync（记录每步操作），用默认no即可，保证数据安全性
aof的优势：
- 数据完整性比rdb要好
- aof文件变大时，redis会自动对aof文件进行重写，也就是rewrite
- aof文件有序的保存了对数据库执行的所有写入操作，这些写入的操作一redis协议的格式保存，这种格式容易被人看懂分析
aof的劣势：
- 相同数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb