第五课作业——持久化
第五课时作业
静哥
by 2016.3.14~2016.3.20
【作业描述】
1.配置aof，并且形成rewrite之前和之后的对比
2.配置rdb，手动命令和后台触发，截图对比持久化之前和之后的数据文件的差异
【作业一：配置aof，并且形成rewrite之前和之后的对比】
【测试-1：没有配置持久化方式的情况下，手动执行bgrewriteaof命令】
当前redis数据库有13个key，string类型，手动执行bgrewriteaof命令：
注意：调用bgrewriteaof命令:
1) 如果当前正在进行aof rewrite，则会返回客户端Background append only file rewriting already in progress
2) 如果当前正在进行rbd dump,则会等待rbd dump进行完再开启:Background append only file rewriting scheduled
3) 如果当前没有进行aof rewrite和rdb dump，则进行aof rewrite：
Background append only file rewriting started
在dir参数指定的目录下，生成一个appendonly.aof文件，文件内容如下：
【测试-2：没有配置持久化方式的情况下，多次set操作，aof方式手动保存】
因为没有在配置文件设置自动保存，在手动保存前，日志无变化
手动执行bgrewriteaof命令，也就是aof持久化方式，可以看到新生成aof存储文件，（dump.rdb文件是rdb持久化方式的存储文件，因此dump.rdb文件大小无变化）
日志Background append only file rewriting started by pid 18486表示，bgrewriteaof命令，会fork一个子进程（进程号18486）来执行保存；
日志AOF rewrite child asks to stop sending diffs.和Parent agreed to stop sending diffs. Finalizing AOF...表示：
日志Concatenating 0.00 MB of AOF diff received from parent表示：
日志SYNC append only file rewrite performed表示：fsync将数据落地到磁盘，最后close文件，将临时文件重命名，确保生成的aof文件完全ok,避免出现aof不完整情况，最后输出这条日志；
日志AOF rewrite: 6 MB of memory used by copy-on-write表示：fork子进程做AOF重写，将会耗用6mb内存作copy on write
【作业二：配置rdb，手动命令和后台触发，截图对比持久化之前和之后的数据文件的差异】
【测试1——rdb快照模式】
Rdb文件是二进制的，不存在回车行来分隔
1、 手动方式save命令保存数据到磁盘：
初，redis库里无数据，dump.rdb文件内容如下：
执行set命令设置键值，此时没执行save命令，dump.rdb文件大小依旧为18M，redis日志没有记录；
【总结】
只有执行save命令OK，才将redis数据写入磁盘
【测试2——rdb模式，手动bgsave】
紧接着如上测试
初，
只执行set命令设置键值，没有保存，数据存放在缓存，没写入磁盘，因此此时dump.rdb文件大小不变
执行bgsave命令和save命令的返回值不同，save命令是在当前线程下执行，会阻塞客户端其他请求的执行；bgsave返回：Background saving started，是fork一个子进程来执行数据保存，不会阻塞客户端其他请求的执行；
Dump.rdb文件大小增长，说明执行bgsave后，将数据保存到磁盘
对比save命令和bgsave命令所产生的日志文件也可以看出：bgsave命令作为后台执行的命令，fork一个子进程（进程号为30543）将数据保存到磁盘；
日志RDB: 6 MB of memory used by copy-on-write表示：redis借助fork命令的copy on write机制（私有内存非共享内存），在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。这个过程消耗6MB内存。
【测试3——rdb模式，配置文件设置保存触发条件】
紧接着上面测试
即，120秒内变化1次，就自动执行bgsave
初：
等候120秒后，查看dump.rdb文件大小和日志
配置文件配置的自动保存和bgsave命令区别在于，会根据配置的触发条件，本次测试的是120秒内改变1次就保存，当满足触发条件，就fork一个子进程执行bgsave命令；
在紧接着上面测试，测试2个以及2个以上触发条件如何处理？当满足第一个条件后，第二个save条件是否会重新计时？？
初，
120s内change 1次的日志：
60s内change 2次的日志：
60s内change 1次，61s到120内再change 1次的日志：
60s内change 2次，61s到120内再change 1次的日志：
【总结】
对于
这个配置下，redis里的周期函数serverCron每隔0.1s执行一次，当在60秒内检测到数据改变次数达到两次了，就会执行一次bgsave。每次写盘后，记录写盘时间，以及保存数据库发生多少次操作。重新计时（因此我在60秒的前20秒内执行完第二次change，数据就被刷到磁盘了）
在61s到120s直接change一次，因为周期检测，没在60s内检测到数据改变2次（以上），不满足save 60 2条件，转而检测是否满足save 120 1，因此在我change后，满足1次修改，就直接刷入磁盘。
总结计时，save参数设置后，redis的周期函数serverCron会周期性检测，从时间范围短、操作频繁的save条件开始检测，一旦检测到满足就立刻执行bgsave;不满足，则转而检测时间次长、操作次频繁的save条件。。。。
