redis数据持久化

    redis作为一种内存数据，我们知道数据保持在内存中很快就会消失，所以redis采取了两种措施对数据进行持久化，那就是RDB和AOF，两者的不一样之处在于，RDB是快照模式而AOF日志模式

快照模式---RDB:

    RDB是一种存储在硬盘中的二进制形式的文件，redis通过命令将redis内存中的数据完整的生成一个快照保存在硬盘当中形成一个RDB文件，每当redis进行重启时，redis就会将RDB文件载入内存中以对数据进行恢复，RDB还可以作为redis主从复制的复制媒介对数据进行传输，RDB有同步和异步两种形式的触发方式

同步（Save)：通过对redis执行save命令可以使用RDB同步的对内存中的数据进行一个快照的备份，由于RDB是一个单线程的同步命令，所以在数据量比较大时会造成redis的阻塞，当redis快照完毕后会把之前老的RDB文件替换掉，保证数据数据的更新

异步(bgsave): bgsave是RDB的一种异步生成RDB的模式，bgsave通过过fork一个子程序来进行一次全量快照，虽然这种模式也会阻塞redis但是也只是fork出子程序的那一下会阻塞，相对save阻塞时间很短，但是bgsave却需要消耗内存去提供给子进程

RDB有几种触发的方式：

1、配置redis.conf,定制RDB的生成规则，让RDB自动按照这个规则执行快照：

例如：

save 900 1

save 300 30

save 60 10000

将上面的配置加入到redis.conf中，意思是900秒内至少发生一次写操作、300秒内至少发生30次写操作、60秒内至少发生10000次写操作，上述条件只要满足一项即可触发一次快照

在redis安装目录的conf目录中的redis.conf文件

2、执行shutdown关闭服务器时，也会进行一次快照执行的，执行的是bgsave

3、主从复制：配置了主从复制的情况下，主从需要进行一次全量复制时会执行RDB快照，master会自动生存一个RDB文件

演示：

配置好RBD生成的文件名dump-6379.rdb,和rdb生成的目录 执行save

执行save命令时redis被阻塞，消耗了八秒多的时间，期间进程被阻塞无法进行其他操作,

配置好的文件位置生成了相应的rdb文件 执行bgsave 执行其他命令

执行save命令时redis几乎未被阻塞，马上就可以进行其他操作,并返回了结果

查看rdb日志文件 bgsave的子程序

发现bgsave的子程序正在运行中

RDB的特点：RDB是经过二进制压缩的文件，文件非常的小加上RDB文件是直接存储的内存数据并且一般为全量内存数据，非常适合备份使用，并且适用redis发生灾难性的数据恢复，不过RDB 也有自身的缺点，因为要进行全量的复制，所以快照时间比较长，不能进行实时性数据持久化，如果在RDB快照过程中redis宕机，就会发生部分数据丢失的情况。

日志模式---AOF:

    AOF是一种持续增量的备份日志，redis默认是将其关闭，它是记录了redis的写指令，redis的内存修改指令都会被记录到日志文件中，在redis进行AOF数据恢复时，会把日志记录的写指令进行重演，所以redis在启动时如果要优先加载AOF日志文件时，时间一般是非常漫长的

AOF重写：

我们知道redis进行AOF数据恢复时间一般是非常漫长的，原因就在于redis对执行AOF对数据的恢复是一个命令重演的过程，针对这种情况，redis提供了对AOF日志进行优化方式：定期对AOF进行重写，以减少不必要的命令执行，达到AOF瘦身的效果，AOF重写后会把旧的AOF文件替换

AOF重写：将命令进行了缩减简化

AOF重写三种策略：

AOF在写入日志的前会把命令更新到缓冲区中，三种会对缓冲区做不同方式的取数据操作：

1、always:缓冲区中每条写命令都会写入日志文件中，缺点：这个模式io开销会比较大

2、everysec：中每秒都会把记录一次缓冲区中的数据到日志中，这个是AOF的默认模式，缺点：会丢失一秒的数据

3、no:什么时候该刷缓冲区的命令到日志中是根据系统决定，缺点：不可控制

瘦身方式有两个：

1、执行bgrewriteaof，这命令一看就大概能猜到是什么情况了，bg和bgsave的bg一样是background的意思也就是异步嘛，rewriteaof可以这样表示re-write-aof大概意思不就是重写aof吗，合起来就是异步重写aof,这个命令也是和bgsave一样会对在redis中fork出一个子进程，让子进程进行aof重写

2、重写aof配置，制定aof自动重写规则：

通过排至aof的重写参数可以，自动触发aof的自动重写

auto_aof_rewrite_min_size:运行aof日志文件的最小体积，默认64mb

auto_aof_rewrite_percentage:aof日志文件的增长率

触发条件：

1、aof_current_size>auto_aof_rewrite_min_size

2、（aof_current_size - aof_base_size）/aof_base_size>auto_aof_rewrite_percentage

（aof_current_size当前aof文件大小，aof_base_size上一次重写的aof文件大小）

演示：

配置依然是在redis的安装目录的conf的redis.conf中

配置刷盘策略

选择每秒刷盘策略，默认就好

配置aof重写规则参数

配置AOF重写规则参数

增长率设置100，aof最小文件大小设置为64mb

aof默认关闭，aof文件名为appendonly.aof

appendonly为no 默认为aof为关闭状态，aof文件名默认为 appendonly.aof，修改为yes即可开启aof日志模式

通过命令开启

或者通过命令开启，如上图，设置好后重启即可开启aof模式

输入命令 输入命令后生成了aof文件

aof文件生成在我们之前配置rdb的生成位置/opt/redis/data中

aof文件的内容 执行重写命令 重新观察aof

执行bgrewriteaof aof重写，aof文件内容明显被缩减了

RDB和AOF的最优策略：

由于AOF是一个命令的重演，数据恢复的速度是很慢的，并且文件大小也是比较大，而RDB是一个内存数据的全量快照，直接进行内存数据的恢复速度是非常快的，文件是二进制的压缩文件，文件比较小，但是恢复时必定是会丢失数据的，所以两者可以互补以达到最优的策略---混合持久化：先使用RDB进行数据的恢复，而后使用AOF进行RDB快照数据缺失的补充，AOF只取RDB持久化结束这段时间的增量日志，而不是全量命令重演的策略,这样redis数据恢复的效率就会大幅度提升