redis 实战操做RDB和AOF快照持久化

前言：redis是咱们经常使用的缓存方式，今天就来介绍下两种持久化的方式吧，先科普概念，再实战操做

 

1、RDB

Redis将某一时刻的快照（备份的数据库数据）保存成一种称为RDB格式的文件中，这种格式是通过压缩的二进制文件。redis保存和恢复文件，如图1和图2所示。

保存RDB数据的命令：有两种，一个是save，一个是bgsave，通常用的都是bgsave命令。
    
        一、save命令：save命令会阻塞redis服务器的进程，直到RDB文件建立完，在该期间，redis不能处理任何的命令请求，这就是save命令最大的缺陷。

        二、bgsave命令：与save命令不一样的是，bgsave在生成RDB文件时，会派生出一个子进程，子进程负责建立RDB文件，在此期间，主进程和子进程是同时存在的，所以不会阻塞redis服务器进程。

说明：（可用lastsave命令查看生成RDB文件是否成功）

RDB快照持久化数据的优缺点：
　　　　一、优势：
　　　　　　（1）、采用子线程建立RDB文件，不会对redis服务器性能形成大的影响；
　　　　　　（2）、快照生成的RDB文件是一种压缩的二进制文件，能够方便的在网络中传输和保存。经过RDB文件，能够方便的将redis数据恢复到某一历史时刻，能够提升数据安全性，避免宕机等意外对数据的影响。
　　　　　　（3）、适合大规模的数据恢复。
　　　　　　（4）、若是业务对数据完整性和一致性要求不高，RDB是很好的选择。
　　　　
　　　　二、缺点：
　　　　　　（1）、在redis文件在时间点A生成，以后产生了新数据，还未到达另外一次生成RDB文件的条件，redis服务器崩溃了，那么在时间点A以后的数据会丢失掉，数据一致性不是完美的好，
　　　　　　　　　　若是能够接受这部分丢失的数据，能够用生成RDB的方式；
　　　　　　（2）、快照持久化方法经过调用fork()方法建立子线程。当redis内存的数据量比较大时，建立子线程和生成RDB文件会占用大量的系统资源和处理时间，对 redis处理正常的客户端请求形成较大影响。
　　　　　　（3）、数据的完整性和一致性不高，由于RDB可能在最后一次备份时宕机了。
　　　　　　（4）、备份时占用内存，由于Redis 在备份时会独立建立一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换以前的备份文件。
　　　　　　　　　　因此Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

触发RDB快照：
　　　　一、在指定的时间间隔内，执行指定次数的写操做
　　　　二、执行save（阻塞， 只管保存快照，其余的等待） 或者是bgsave （异步）命令
　　　　三、执行flushall 命令，清空数据库全部数据，意义不大
　　　　四、执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义...也不大。

经过RDB文件恢复数据：
　　　　将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务便可。在实际开发中，通常会考虑到物理机硬盘损坏状况，选择备份dump.rdb 。

 

2、AOF

AOF是redis对将全部的写命令保存到一个aof文件中，根据这些写命令，实现数据的持久化和数据恢复。

AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），因此它采用日志的形式来记录每一个写操做，并追加到文件中。
　　　 Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工做。

AOF文件生成机制：
        一、生成过程包括三个步骤：命令追加、文件写入、文件同步。
　　　　　　 redis打开AOF持久化功能以后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录尚未写到appendonly.aof文件中。
　　　　　　而后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操做系统来讲，调用write函数并不会马上将数据写入到硬盘，为了将数据真正写入硬盘，还须要调用fsync函数，
　　　　　　调用fsync函数便是文件同步的过程，只有通过了文件的同步过程，写命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的频率的选项。

AOF重写：
        一、redis不断的将写命令保存到AOF文件中，致使AOF文件愈来愈大，当AOF文件体积过大时，数据恢复的时间也是很是长的，所以，redis提供了重写或者说压缩AOF文件的功能。
　　　　　　 好比对key1初始值是0，调用incr命,100次，key1的值变为100，那么其实直接一句set key1 100 就能够顶以前的100局调用，AOF重写功能就是干这个事情的。
　　　　　　 重写时，能够调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工做原理类似。也能够经过配置文件配置什么条件下对AOF文件重写。
　　　　　
　　　　 二、重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并从新写到一个临时文件中。并无读取旧文件（太大了）。最后替换旧的aof文件
　　　　
　　　　 三、重写触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 能够经过配置文件修改。

AOF优缺点：
　　优势：
　　　　一、提供了多种同步命令的方式，默认1秒同步一次写命令，作多会丢失1秒内的数据；
　　　　二、若是AOF文件有错误，好比在写AOF文件时redis崩溃了，redis提供了多种恢复AOF文件的方式，
　　　　　　例如使用redis-check-aof工具修正AOF文件（通常都是最后一条写命令有问题，能够手动取出最后一条写命令）；
　　　　三、AOF文件可读性交强，也可手动操做写命令。
　　　　四、数据的完整性和一致性更高
　　
　　缺点：
　　　　一、AOF文件比RDB文件较大；
　　　　二、redis负载较高时，RDB文件比AOF文件具备更好的性能；
　　　　三、RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，所以从理论上来讲，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些状况下，AOF的确也存在一些bug，
　　　　　　好比使用阻塞命令时，这些bug的场景RDB是不存在的。
　　　　四、由于AOF记录的内容多，文件会愈来愈大，数据恢复也会愈来愈慢。

触发AOF快照：
　　根据配置文件触发，能够是每次执行触发，能够是每秒触发，能够不一样步。

根据AOF文件恢复数据：
　　正常状况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务便可。但在实际开发中，可能由于某些缘由致使appendonly.aof 文件格式异常，
　　从而致使数据还原失败，能够经过命令redis-check-aof --fix appendonly.aof 进行修复 。

以上简单罗列了下两种快照的基本信息，更多详细信息能够参考：https://www.jianshu.com/p/cbe1238f592a，下面开始实战

 

3、实战RDB操做

打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容
　　（1）、RDB核心规则配置（重点）
　　　　　　save <seconds> <changes>

　　　　　　save 900 1 
　　　　　　save 300 10 
　　　　　　save 60 10000

　　　　　　说明：save <指定时间间隔> <执行指定次数更新操做>，知足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，
　　　　　　　　　则将内存中的数据快照写入磁盘。若不想用RDB方案，能够把 save "" 的注释打开，下面三个注释。

　　（2）、指定本地数据库文件名，通常采用默认的 dump.rdb
　　　　　　　配置：dbfilename dump.rdb

　　（3）、指定本地数据库存放目录，通常也用默认配置
　　　　　　　配置：dir ./

　　（4）、默认开启数据压缩
　　　　　　　配置：rdbcompression yes
　　　　　　　说明：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会致使数据库文件变的巨大。建议开启。

　　一、配置save：设置了120S，修改3次，则持久化一次（shutdown和FLUSHALL也有生成快照的功能）

 

　　二、开始测试

　　　　

　　三、经过RDB文件恢复数据　

流程：
        一、先备份一份dump.rdb为dump_bak.rdb（模拟线上）
        二、flushall清空数据（模拟数据丢失........注意flushall也会触发rbd持久化）
        三、将dump_bak.rdb替换为dump.rdb
        四、重启redis服务，恢复数据

　　

 

4、实战AOF操做 

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容
　　　　一、redis 默认关闭，开启须要手动把no改成yes
　　　　　　配置：appendonly yes

　　　　二、指定本地数据库文件名，默认值为 appendonly.aof
　　　　　　配置：appendfilename "appendonly.aof"

　　　　三、指定更新日志条件
　　　　　　配置：# appendfsync always 
　　　　　　　　　　appendfsync everysec 
　　　　　　　　　# appendfsync no

　　　　　　配置说明：always：同步持久化，每次发生数据变化会马上写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
　　　　　　　　　　　everysec：出厂默认推荐，每秒异步记录一次（默认值）
　　　　　　　　　　　no：不一样步

　　　　四、配置重写触发机制
　　　　　　配置：auto-aof-rewrite-percentage 100
　　　　　　　　　auto-aof-rewrite-min-size 64mb

　　　　　　配置说明：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。通常都设置为3G，64M过小了。　

　　

　　一、修改配置appendonly为yes（须要重启redis）

　　

　　二、开始测试

　　

　　三、经过AOF文件恢复数据

流程：   
        一、执行flushall，模拟数据丢失
        二、重启redis服务，恢复数据
        三、修改appendonly.aof，模拟文件异常
        四、重启 Redis 服务失败。这同时也说明了，RDB和AOF能够同时存在，且优先加载AOF文件。
        五、使用redis-check-aof 校验appendonly.aof 文件。重启Redis 服务后正常。

　　　注意：当你使用flushall清空数据的时候，重启redis服务发现数据没恢复，是由于FLUSHALL 命令也被写入AOF文件中，致使数据恢复失败。
　　　　　　只须要删除aof文件中的flushall就好了

　　

　　

　　

 　　

5、总结

一、Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操做，则将内存中的数据写入到磁盘中。

二、RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。

三、Redis 须要手动开启AOF持久化方式，默认是每秒将写操做日志追加到AOF文件中。

四、AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

五、Redis 针对 AOF文件大的问题，提供重写的瘦身机制。

六、若只打算用Redis 作缓存，能够关闭持久化。（RDB关闭：注释掉全部save，AOF关闭：appendonly为no）

七、若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合作数据的备份，留一后手。AOF出问题了，还有RDB。

 

以上就是文章的所有内容了，实战部分为本人亲测。

概念参考连接：http://www.javashuo.com/article/p-kbfkhfzd-mh.html