redis_3_删除和持久化策略

骑猪看日落 2021-05-12 11:55 540阅读 0赞

一、redis的三种删除策略：

1、被动删除：在上一章中已经提到过，dbsize中获得key个数包含过期的key，只有在key再次被操作的时候，redis才会去检测该key是否已经过期，如果过期则将它删除，这对于cpu来说，能节约出删除该key的时间来；但是对于内存来说，假如该key一直甚至永远不被调用的话，它将一直占着内存，当这种key越来越多的时候，内存会被这种可以称得上是垃圾key占满，对于吃内存的redis而言，无疑是一场噩梦。

2、主动删除：主要由redis.c/serverCron来实现，作为时间事件来进行，每隔一段时间就会自动运行一次，serverCron 会一直定期执行，直到服务器关闭为止。配置文件中的hz就是用来配置这个的频率的，默认是10，表示serverCron每秒执行10次。

![这里写图片描述][SouthEast]

主要作用：（参考别人的）

*  更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等
 *  清理数据库中的过期键值对
 *  对不合理的数据库进行大小调整
 *  关闭和清理连接失效的客户端
 *  尝试进行 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。

![这里写图片描述][SouthEast 1]

总结：随机从所有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，表示你不在乎数据不一致或者有其他手段发现和控制。

三种快照配置：

![这里写图片描述][SouthEast 2]

*  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倍的膨胀性需要考虑

![这里写图片描述][SouthEast 3]

2、aof：append only file 或者叫文件追加

什么是aof：

以日志的形式来记录每个写操作，将redis执行过程所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取改文件重新构建数据，换言之，redis重启的话，就根据日志文件的内容，将写指令从前到后执行一次，以完成数据的恢复工作。  
用一句话概括就是：走一步记录一步（除了读操作），当redis重启的时候就重新根据记录演绎一遍。

appendonly：这个参数默认是no，即默认是不打开aof的，设置为yes即可。

appendfilename：aof文件名字设置，默认的是：appendonly.aof

![这里写图片描述][SouthEast 4]

aof的持久化策略：

*  always：同步持久化，每次发生数据变化会被立即记录到磁盘，性能较差，但是数据完成性比较好.
 *  everysec：出厂默认设置，异步操作，每秒记录，如果一秒内关机，有数据丢失
 *  no：表示不持久化

![这里写图片描述][SouthEast 5]

aof的持久化恢复测试：

开始的时候没有aof文件

![这里写图片描述][SouthEast 6]

向redis存一个值，然后关闭redis

![这里写图片描述][SouthEast 7]

![这里写图片描述][SouthEast 8]

然后我们再看redis目录，多了一个.aof文件

![这里写图片描述][SouthEast 9]

打开aof文件，记录了redis刚才存储的a这个key的记录。

![这里写图片描述][SouthEast 10]

为了证明aof文件能恢复数据，我们先把.rdb文件删除

![这里写图片描述][SouthEast 11]

然后我们在打开redis，获取刚才设定的a这个key

![这里写图片描述][SouthEast 12]

思考：如果rdb和aof文件同时存在，那么按照那个优先来恢复数据呢？

首先证明这两个是可以同时存在的

![这里写图片描述][SouthEast 13]

我们再次关闭服务器

![这里写图片描述][SouthEast 14]

然后将aof文件乱写一通，然后保存，然后重启服务器，如果redis能重新启动，则首先找的是dump，如果redis不能启动，那首先找的就是aof

![这里写图片描述][SouthEast 15]

发现aof是损坏的文件，redis无法启动

![这里写图片描述][SouthEast 16]

![这里写图片描述][SouthEast 17]

结论：aof的优先级比rdb高，还有就是如果数据库被flushall之后，只要打开aof文件，删除最后的那个flushall操作即可恢复所有数据

修复aof文件：redis-check-aof.exe - - fix aof文件名字

![这里写图片描述][SouthEast 18]

![这里写图片描述][SouthEast 19]

问题：为啥没有redis-check-dump.exe这个exe？？？

aof的rewrite（重写）：

**rewrite是什么**：aof采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当aof文件的大小超过所设定的阈值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof（redis2.4之后引入的）

**rewrite的触发机制**：redis会记录上次重写的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍（100%）且文件大于64M（这个值一般生产环境中配5G以上）

![这里写图片描述][SouthEast 20]

**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

[SouthEast]: /images/20210511/e8aca5adc04f4272942468e9c522796e.png
[SouthEast 1]: /images/20210511/55b83157c61a4b07b830f8a1d16d56d5.png
[SouthEast 2]: /images/20210511/8fc61ec1f123463dabf3bd64bbb9ce04.png
[SouthEast 3]: /images/20210511/de759ac823014f62a8db556b6b8ee9f0.png
[SouthEast 4]: /images/20210511/d8fe9a87ae0c4e6db7968a482a3a2235.png
[SouthEast 5]: /images/20210511/e48564f6c3ba4f8ea43710983405b961.png
[SouthEast 6]: /images/20210511/83770b6f3063482ba0375cde0a86f24d.png
[SouthEast 7]: /images/20210511/984f7cdb62cd433a90e47f6745aad0bc.png
[SouthEast 8]: /images/20210511/ebde2c3e7a1b45ddb3463b8b1bcafeed.png
[SouthEast 9]: /images/20210511/c5b615c24992480995e708f96cddee2e.png
[SouthEast 10]: /images/20210511/4e2db49aaecd43ab9683f77081dbb748.png
[SouthEast 11]: /images/20210511/0b8cbab94f25417480d1967f13058ff1.png
[SouthEast 12]: /images/20210511/f1675adca314498d9ea9622a218de27d.png
[SouthEast 13]: /images/20210511/e20c9205e208450991576e6a0b33fb24.png
[SouthEast 14]: /images/20210511/a1ee7d57bd51476e8b77c376f9059b51.png
[SouthEast 15]: /images/20210511/1aabb1bbba25476fa08ffa4e195d1efb.png
[SouthEast 16]: /images/20210511/a4692b30c2b343f2a36cf2a35b43267e.png
[SouthEast 17]: /images/20210511/18dc69896dd1412690379fc055060508.png
[SouthEast 18]: /images/20210511/6340ddd904a643a58b7206e0e0d334a7.png
[SouthEast 19]: /images/20210511/67b87bce3d2c497e85b86a6ace8cdbe6.png
[SouthEast 20]: /images/20210511/18ea566c8fe845e8a205cbf3d24398da.png