Redis持久化方式RDB、AOF详解

Redis持久化方式RDB、AOF详解
         之前已经写过一篇博客大概介绍了什么是RDB、AOF持久化，今天自己在本地搭建redis环境并实践了两种持久化方式。
持久化文件保存的路径在配置文件中的dir进行配置，默认为./ 当前路径下

1.RDB持久化
          RDB快照方式(默认的持久化方式)：通过设定指定时间段内的key值变化数量来触发redis的快照存储，一次性将内存中的所有数据保存在磁盘上(替换原来的rdb文件)，配置文件可设置存储文件名称，RDB持久化方式的快照策略在配置文件中如下：

为了实现测试效果，修改快照策略为120秒内至少有两个键发生改变，在redis客户端执行两个写命令，120秒后查看日志执行了RDB存储

如日志打印所示，120秒发生了两个key的变化，redis fork一个1538的子进程完成RDB存储把数据保存在磁盘上，之后redis启动时会从磁盘中加载数据到内存。
RDB持久化方式的缺点：当Redis出现宕机后，将损失从最近一次快照到宕机时的数据
关闭持久化方式：注释掉save策略即可

2.AOF追加方式(将每一次的写命令记录到文件中，重启的时候从前到后执行这些命令)
配置文件中开启AOF持久化方式：appendonly yes；设置持久化文件名称：appendfilename appendonly.aof
写入策略：appendfsync 默认为每秒，每秒往aof文件中追加写入一次(该一秒内有写命令发生)，如下，当客户端有写命令发生时，aof文件有更新

当redis长时间运行时，会有大量的写命令追加到文件，将导致aof文件过大，所以redis提供了一种重写机制
重写机制：简单来说，AOF文件重写是将内存的数据用一个写命令代替，举例说明，对key string进行赋值，第一次set string ‘1’,第二次 set string ‘2’,第三次 set string ‘3’， 这些命令都会被写入aof文件，当AOF文件重写时，内存中的string 值为 ‘3’，AOF就生成一条命令 set string ‘3’，并将此命令写入文件，这就是AOF文件的重写机制，可以有效缩小aof文件的大小
当然，实际的处理过程并没有这么简单，当AOF重写开始时，redis会fork出一个子进程，由子进程完成重写过程，子进程重写期间，主进程正常接收写命令并， 将写命令写入现有的AOF文件(旧的)，重写开始时，子进程拥有了主进程的数据副本，将对这些数据进行重写，但是问题来了，子进程重写期间，主进程接收到的新的写命令怎么处理呢。子进程重写期间，主进程正常接收写命令并将写命令追加到现有的AOF文件和重写缓存中，重写缓存是在fork出子进程后启动的，重写完成后，重写缓存中的命令加入新的AOF文件，新的AOF文件替换旧的AOF文件，完成重写。
那redis重写机制是如何触发的呢，redis.conf中有如下配置

auto-aof-rewrite-percentage 100 ：之后当前AOF文件的大小与上次重写时大小的比值达到100%时，触发重写
auto-aof-rewrite-min-size 100kb ：当第一次AOF文件大小达到指定大小时，触发重写
为了达到测试效果，将两个配置的值都调小了，测试过程如下：
设置 auto-aof-rewrite-min-size=100kb,启动redis后，自动创建AOF文件，大小为0KB，当redis数据大小达到100kb时触发了重写，AOF文件大小变成4kb，继续增加数据到redis,当AOF文件大小达到100kb时，又触发了重写，100/100=1，两个重写配置是生效的

redis的持久化就介绍到这里，之后还会有很多redis的干货哦！