关于redis数据持久化

关于redis数据持久化

背景

众所周知redis是一种缓存数据库,数据被储存在内存中,但是当遇到一些不可抗力因素导致电脑突然关机时,内存中的数据荡然无存,例如,突然断电,硬盘损坏等.如何解决此问题,我们是否可以通过持久化将数据写入磁盘中.

持久化方式

redis为了保证在系统挂掉的情况下,为了更快的进行数据恢复,提供了两种持久化方案,分别是RDB和AOF.

配置工作

第一步:在redis官网找到合适的版本的redis.conf文件,下载地址

https://redis.io/topics/config/

第二步:停止redis并删除挂在目录下的redis.conf文件

第三步:将下载好的redis.conf拖拽到redis挂在目录

第四步:基于vim打开redis.conf文件,并注释bind 127.0.0.1这一行,并修改protected-mode的值修改为no.(java连接redis需要改这两项目)

第五步:重启redis

RDB配置

# 这里表示每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting(快照)。

save 60 1000

# 持久化 rdb文件遇到问题时，主进程是否接受写入，yes 表示停止写入，如果是no 表示redis继续提供服务。
stop-writes-on-bgsave-error yes
    
# 在进行快照镜像时,是否进行压缩。yes:压缩，但是需要一些cpu的消耗。no:不压缩，需要更多的磁盘空间。
rdbcompression yes
# 一个CRC64的校验就被放在了文件末尾，当存储或者加载rbd文件的时候会有一个10%左右的性能下降，为了达到性能的最大化，你可以关掉这个配置项。
rdbchecksum yes

# 快照的文件名
dbfilename dump.rdb

# 存放快照的目录
dir /var/lib/redis

FAQ

触发redis中RDB方式持久化的时机:

1)基于配置文件中save的设置时间周期执行持久化

2)手动执行shutdown操作会自动执行RDB方式持久化

3)手动调用save或者bgsave指令执行数据持久化

4)在Master/Slave架构下,当有新的Slave连接Master时,Master会对数据进行RDB持久化

redis中的save和bgsave有什么不同:

1)save命令执行一个同步保存操作,将当前redis实例的所有数据快照,以RDB的形式保存到硬盘

2)bgsave命令执行之后立即返回ok,然后redis fork出一个新的子进程,原来的redis父进程继续处理客户端请求,子进程将数据保存到磁盘,然后退出

RDB持久化的优点是:

1)RDB文件是经过压缩的二进制文件,占用空间很小,它保存了redis某个时间点的数据集,适合做冷备

2)RDB非常适合用于灾难恢复,它只有一个文件,并且内容比较紧凑,可以将它传送到别的数据中心.

3)RDB方式持久化性能较好,执行持久化时可以fork一个子进程,由子进程处理保存工作,父进程无需执行任何磁盘I/O操作

RDB持久化的缺点是:

1)RDB方式在服务器故障时容易造成数据的丢失,实际项目中可以通过配置控制持久化的频率,但是如果频率太频繁会对redis性能产生影响,所以通常设置5分钟保存一次,这时如果redis出现宕机则最多丢失5分钟的数据

2)RDB方式通过fork子进程进行数据持久化,子进程的内存是在fork操作时父进程数据快照的大小,如果数据快照比较大,fork时开辟内存会比较耗时,同时这个fork时同步操作,所以这个过程导致父进程无法对外提供服务

3)RDB的持久化过程中的fork操作,可能会导致内存占用加倍,Linux系统fork采用的是copy-on-write(写时复制,修改前复制),在redis执行RDB持久化期间客户端频繁写入数据,那么将增加redis占用内存,最坏情况下,可以达到原先两倍

AOF方式数据持久化

AOF方式是通过记录操作日志的方式,实现redis数据持久化的一种机制,这个机制默认是关闭的

AOF方式配置

# 是否开启AOF，默认关闭
appendonly yes
# 指定 AOF 文件名
appendfilename appendonly.aof
# Redis支持三种刷写模式：
# appendfsync always #每次收到写命令就立即强制写入磁盘，类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
# appendfsync no     #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。
    
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
no-appendfsync-on-rewrite yes
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

FAQ

如何理解AOF方式中的rewrite操作

redis中可以储存的数据时有限的,很多数据会自动过期,包括也可能会被用户删除,redis用缓存清理算法清理等,也就是说redis中的数据会不断迭代,只有一部分常用的数据会被自动保留在redis中,所以被清理掉的数据也可能被写到日志中,是的文件越来越大.所以AOF会每隔一定的时间会做rewrite操作.

AOF持久化机制有哪些优点

AOF比RDB更加可靠,可以设置不同的fsync策略(no,everysec,always),默认是everysec.这种策略redis任然可以保持良好的性能,并且就算发生故障停机,也最多丢失1秒的数据

AOF 问价是一个纯文本追加模式的日志文件,即使日志包含不完整的命令也可以通过redis-check-aof工具进行数据恢复

AOF问价太大时,redis会在后台自动重写,重写后的日志是最小的集合,重写的过程是绝对安全,因为重写是一个新的文件进行,redis同时会在旧文件中写入,当新文件重写完必,将旧数据追加到新文件中

AOF文件有序的保存了对数据库所有的写入操作,即便一不小心flushall了,进入找到aof日志中删掉flshall命令,重启redis,数据就会恢复.

AOF持久化方式的缺点

对于相同的数据集,AOF文件比RDB问价大 ,根据fsync策略,AOF比RDB速度回稍慢

如何选择redis的持久化方式

1:不要只是用RDB,这样数据可能不安全

2:也不要只使用AOF,AOF数据恢复的比较慢

3:应该综合使用两种方式,用AOF做数据的保存,用RDB用来冷备数据