Redis持久化
Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘中,那么一旦服务器进程退出,服务器中的数据库状态也会小时,所以Redis提供了持久化功能!
RDB(Redis DataBase)
什么是RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,在持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的搞笑。RDB的缺点就是最后一次持久化的数据可能丢失。
rdb保存的是dump.rdb文件,配置文件中快照位置进行配置rdb规则
触发机制
1、save的规则满足的情况下,会自动触发rdb规则。
2、执行flushall命令也会触发rdb规则!
3、退出Redis,也会产生rdb文件!
如何恢复rdb文件
1、只需要将rdb文件放在redis启动目录即可,redis启动时会自动检查dump.rdb,恢复其中的数据
2、查看需要存在的位置
config get dir
优点:
1.采用子线程创建RDB文件,不会对redis服务器性能造成大的影响;
2.快照生成的RDB文件是一种压缩的二进制文件,可以方便的在网络中传输和保存。通过RDB文件,可以方便的将redis数据恢复到某一历史时刻,可以提高数据安全性,避免宕机等意外对数据的影响。
缺点:
1.在redis文件在时间点A生成,之后产生了新数据,还未到达另一次生成RDB文件的条件,redis服务器崩溃了,那么在时间点A之后的数据会丢失掉,数据一致性不是完美的好,如果可以接受这部分丢失的数据,可以用生成RDB的方式;
2.快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时,创建子线程和生成RDB文件会占用大量的系统资源和处理时间,对 redis处理正常的客户端请求造成较大影响。
AOF(Append Only File)
将所有命令都记录下来,恢复的时候就把这个文件全部执行一遍
以日志的形式记录每个写操作,将Redis执行过的所有命令记录下来(读操作不记录),只许追加文件但不可以改写文件,Redis启动之初会读取该文件重新构建数据,换言之,Redis重启的话久耕具日志文件的内容将写指令重新执行一遍以完成数据的恢复工作。
AOF保存的时appendonly.aof文件
appendonly no # 默认是不开启的
如果这个aof文件有错位,这时候redis是启动不起来的
redis-check-aof # 修复aof文件
优点和缺点
优点:
1.提供了多种同步命令的方式,默认1秒同步一次写命令,最多丢失1秒内的数据;
2.如果AOF文件有错误,比如在写AOF文件时redis崩溃了,redis提供了多种恢复AOF文件的方式,例如使用redis-check-aof工具修正AOF文件(一般都是最后一条写命令有问题,可以手动取出最后一条写命令);
3.AOF文件可读性交强,也可手动操作写命令。
缺点:
1.AOF文件比RDB文件较大;
2.redis负载较高时,RDB文件比AOF文件具有更好的性能;
3.RDB使用快照的方式持久化整个redis数据,而aof只是追加写命令,因此从理论上来说,RDB比AOF方式更加健壮,另外,官方文档也指出,在某些情况下,AOF的确也存在一些bug,比如使用阻塞命令时,这些bug的场景RDB是不存在的。
重写
redis不断的将写命令保存到AOF文件中,导致AOF文件越来越大,当AOF文件体积过大时,数据恢复的时间也是非常长的,因此,redis提供了重写或者说压缩AOF文件的功能。比如对key1初始值是0,调用incr命,100次,key1的值变为100,那么其实直接一句set key1 100 就可以顶之前的100局调用,AOF重写功能就是干这个事情的。
重写时,可以调用BGREWRITEAOF命令重写AOF文件,与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。
auto-aof-rewrite-percentage 100 #当前AOF文件大小和上一次重写时AOF文件大小的比值
auto-aof-rewrite-min-size 64mb #文件的最小体积
重写步骤:
1.创建子进程进行AOF重写
2.将客户端的写命令追加到AOF重写缓冲区
3.子进程完成AOF重写工作后,会向父进程发送一个信号
4.父进程接收到信号后,将AOF重写缓冲区的所有内容写入到新AOF文件中
5.对新的AOF文件进行改名,原子的覆盖现有的AOF文件