商品详情页系统 -- day03 RDB和AOF配置及使用实验

一、配置RDB持久化机制

 

修改 /etc/redis/6379.conf 配置文件，配置redis的RDB持久化机制：

其中：

        save 60 1000 表示：每隔60s，如果超过1000个key的值发生变化，那么就会生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称为snapshotting（快照），也可以手动调用save或者bgsave命令，同步或者异步执行rdb快照生成。

        save可以设置多个值，就是多个snapshtting检查点，每到一个检查点，就会check一下，是否有指定的key的数量发生变更，如果有，就生成一个新的dump.rdb文件。

 

二、RDB持久化机制的工作流程

1. redis根据配置自己尝试去生成rdb快照文件

2. fork一个子进程出来

3. 子进程尝试将数据dump到临时的rdb快照文件中

4. 完成rdb快照文件的生成之后，就会替换之前的旧的快照文件

 

三、基础RDB持久化机制的数据恢复实验

 

1、启动redis服务以及客户端，存储数据

 

2、使用正常退出模式关闭redis服务

注意：使用redis-cli SHUTDOWN命令退出redis服务的时候，是一种安全退出模式，默认会在退出的时候，将redis中的数据立即持久化到rdb文件中（/var/redis/6379/dump.rdb），因此使用SHUTDOWN结束redis进程的时候，数据不会丢失。因此，我们在模拟系统故障异常退出造成的数据丢失时，需要使用kill命令强制杀死redis进程，并且删除pid进程文件的方式去实现。

 

3、在Redis中保存新数据，查看redis进程，使用kill命令结束redis进程

        存储新数据，退出客户端，使用 ps -ef | grep redis 命令查看redis进程并使用kill -9 端口号强制结束redis进程，之后删除对应的pid文件，再次启动redis客户服务以及进入客户端，查看数据，发现新添加的数据并没有被持久化到dump.rdb文件中。

 

4、停止redis服务，手动配置自定义的RDB持久化机制的check点

 

5、启动redis服务，添加新的数据，强制退出redis进行测试

注意：将RDB持久化机制check点添加每5秒有一条数据修改之后，发现数据已经被保存，演示成功。演示之后将该实验检查点删除即可。

 

四、AOF持久化配置以及数据恢复实验

 

1、打开AOF配置

redis中的AOF持久化配置默认是关闭的，redis默认是只打开RDB持久化，AOF持久化可以在配置文件中进行配置，配置如下：

        appendonly yes，可以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非是随便丢个几分钟的数据也无所谓。打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再fsync（将数据持久化到磁盘中）一下。而且即使AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的，因为aof数据比较完整。

可以配置AOF的fsync策略，有三种策略可以选择：

        appendfsync always：表示每次写入一条数据，都会把对应的写操作的日志fsync到磁盘上，性能非常差，吞吐量很低。

        appendfsync everysec：表示每秒将os cache中的数据fsync到磁盘中，生产环境中比较常用的一种策略，性能比较高。

        appendfsync no：示redis仅仅负责将数据写入到os cache中就不管了，os会根据自己的策略将数据写入到磁盘中，是不可控制的。

 

2、AOF持久化的数据恢复实验

 

（1）、redis中写入实验数据

 

（2）、查看/var/redis/6379下已经有AOF的持久化文件

        在appendonly.aof文件中，可以看到刚写的日志，它们其实就是先写入os cache的，然后1秒后才fsync到磁盘中，只有fsync到磁盘中了，才是安全的，要不然光是在os cache中，机器只要重启，就什么都没了。

 

（3）、使用kill命令强制停止redis进程，删除pid进程文件

重启redis服务，查看数据，发现数据还在，此时数据是从AOF文件中恢复回来的数据，redis进程启动时，就会从appendonly.aof中加载所有的日志，把内存中的数据恢复过来。

 

3、AOF的rewrite

        redis中的数据其实有限的，很多数据可能会自动过期，可能会被用户删除，可能会被redis用缓存清除的算法清理掉。redis中的数据会不断淘汰掉旧的，只有一部分常用的数据会被自动保留在redis内存中，所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，直到到很大很大。所以AOF会自动在后台每隔一定时间做rewrite操作。比如日志里已经存放了针对100w数据的写日志了，而redis内存只剩下10万，此时redis会自动基于内存中当前的10万数据构建一套最新的日志，到AOF文件中，覆盖之前的老日志; 确保AOF日志文件不会过大，保持跟redis内存数据量一致，这就是redis的rewrite操作。

redis.conf中可以配置redis的rewrite策略

auto-aof-rewrite-percentage 100 ：代表当前AOF文件大小膨胀到超过之前文件大小的100%时，也就是文件大小变为原来的2倍时，同时，满足文件大小大于min-size时，进行rewrite操作

auto-aof-rewrite-min-size 64mb：代表当前AOF文件即使膨胀之后，如果大小没有超过最小文件大小，即64mb（此处可自定义大小）时，也不会进行rewrite操作

aof文件进行rewrite的步骤：

（1）redis fork一个子进程
（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件
（4）子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中
（5）用新的日志文件替换掉旧的日志文件

 

4、AOF破损文件的修复

        将appendonly.aof文件备份到/usr/local下，删除appendonly.aof文件末位两行，使用redis-3.2.8/src路径下的redis-check-aof命令修复aof文件，其实是将有错误的aof中的内容删除

重启redis服务，发现k2已经消失

 

5、AOF和RDB同时工作时redis的工作原则

（1）如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting

（2）如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite

（3）同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整