Redis持久化（RDB、AOF）

        持久化，就是把存储在内存中的数据，以文件的形式存储到磁盘上。Redis数据库作为内存数据，肯定要考虑到数据持久化的问题。

        Redis提供了两种持久化的方案，一种是文件快照（RDB）方式；一种是过程日志（AOF）,将每一步执行的操作保存下来。

        下面将讲述RDB和AOF两种持久化方案的执行方法，以及各自的优缺点。

        在将持久化内容之前，需要说明下备份文件的目录选择，目录需要有写权限，备份文件的目录可以在redis.conf配置文件中修改

一、RDB

        RDB是以文件快照的方式存储数据，Redis提供了两个命令可以执行RDB方式的数据持久化，save命令和bgsave命令。

1.1 save命令

         使用save命令，就可以实现RDB的操作，在redis客户端执行。

        在指定的保存目录下，如上面截图，/home/redis/，会有备份的文件

 1.2 bgsave命令

        save命令有其致命的缺陷：由于redis是单线程的，save命令的执行会阻塞当前redis的服务器，如果save命令执行时间比较长，后面的命令都需要等待，所以线上环境不建议使用save命令。取而代之的是bgsave命令。

        bgsave命令，也是保存数据到磁盘的操作，但不是立即执行，而是另启动一个线程来执行。

        当执行bgsave命令后，Redis会生成一个子线程去执行保存操作，Redis内部的所有RDB操作都是使用bgsave命令。

        最后简单介绍下RDB操作在配置文件redis.conf中相关的配置参数 

dbfilename dump.rdb   文件名
dir ./                文件的保存路径,默认./
rdbcompression yes    存储至本地时是否压缩数据，默认开启
rdbchecksum yes       是否进行RDB文件格式校验，默认开启
save second changes   在second时间内发生了changes次变化就执行持久化 如：save 900 1,通常配置文件中会设置多个持久化规则

1.3 RDB的优缺点

        有点：

• RDB是紧凑压缩的二进制文件，存储效率高
• RDB存储的是某个时间点内的数据快照，适用于数据备份、全量复制等场景
• RDB数据恢复速度要快于AOF

        缺点：

• RDB无法做到实时的持久化
• bgsave运行需要启动一个子线程，损耗部分性能
• RDB可能会存在不同版本redis冲突的问题

二、AOF

        AOF方式持久化数据，是以保存过程操作日志的方式保存每次的命令操作，保证数据持久化的实时性。

         对于AOF何时将缓存中的命令操作放到硬盘文件，即上图第三步，AOF提供了三个策略：

• always（每次）：数据零误差，性能低
• everysec（每秒）：准确性高，性能较高
• no（系统控制）：不可控

2.1 开启AOF

        配置文件中appendonly属性修改为yes，默认为no

        配置文件中可以看到AOF默认的同步磁盘文件，使用的everysec，每秒写一次缓存到文件。

 

2.2 AOF重写 

        了解下概念就可以了，随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

        重写的两种方式，手动重写和自动重写

        手动重写

bgrewriteaof

        自动重写，在配置文件中配置触发重写的条件。

#当前的size和设定的size作比较，当前size大于设定size就执行重写
auto-aof-rewrite-min-size size
#按设定的百分比作比较，（当前的size-aof_base_size）/ aof_base_size的值大于百分比就执行重写
auto-aof-rewrite-percentage percent

2.3 AOF的优缺点

        优点：

• 每次修改都会同步，文件的完整性比较好
• 每秒同步一次，仅可能后丢失一秒数据

        缺点：

• aof的持久化的数据文件，相比较rdb方式来说，会大很多，修复的速度也会慢很多
• aof的运行效率也要比rdb慢

综述：redis默认的持久化方式是RDB方式。