Redis数据的持久化

Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)或者把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。

Redis提供两种方式进行持久化:

1. RDB持久化:将redis在内存中的数据记录定时dump到磁盘
2. AOF持久化:将redis的操作日志以追加的方式写入文件

一、 RDB

在制定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入历史文件,写入成功后,再替换之前的文件,用位二进制压缩存储.

1.1 定义RDB文件名

vim  /etc/redis/6379.conf
254	  dbfilename   dump.rdb   # dump.rdb为文件名 

1.2 数据备份

将rdb文件拷贝到备份目录
]# cp /var/lib/redis/6379/dump.rdb /备份路径​

1.3 恢复数据

先停止服务器的Redis服务,删除备份服务器的数据库目录下的dump.rdb,将备份文件拷贝到数据库目录下,重新开启Redis服务

]#  redis-cli -h 192.168.4.51 6351 shutdown
]# cp /备份目录/备份文件   /var​​/lib/redis/6379/
]# /etc/init.d/redis_6379   start​

1.4 优化设置

1.41 数据从内存保存到硬盘的频率

]# vim /etc/redis/6379.conf 
​219    save 900 1              //900秒且有1个变量改变时保存到硬盘
220    save 300 10           //300秒且有10个变量发生改变时保存到硬盘
221    save 60 10000       //60秒且有10000个变量发生改变时保存到硬盘

1.4.2 手动存盘

//命令行操作
​192.168.4.52:6352> save  //阻塞写存盘,存期间数据库不能进行工作
OK
192.168.4.52:6352> bgsave     //不阻塞写存盘.存盘时新建子进程进行存盘操作,父进程依旧执行命令请求
Background saving started

1.5 RDB的优缺点

• 优点

1. 使用rdb保存数据,整个redis数据库只包含一个文件,方便数据的备份,迁移和灾备
2. 性能最大化,持久化的时候,redis会fork出一个子进程来执行持久化操作,这样不会占用redis服务本身的的IO操作
3. 如果数据集很大,RDB的启动效率会高

• 缺点

1. 数据的高可用性能较差.当系统在数据持久化的时候发生宕机现象,那么没来得及写入磁盘的数据都将会丢失.
2. RDB采用子进程进行数据的持久化,当数据集较大的时候,服务器可能会停止服务几百毫秒甚至是1秒

二、AOF

以日志的形式记录服务器所处理的每一个写/删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录

2.1 开启AOF

同时开启AOF和RDB,AOF的优先级比较高,会优先使用AOF进行数据的持久化

2.1.1 配置文件开启AOF

]# /etc/init.d/redis_6379 stop       //或者使用下面的命令
]# redis-cli -h 192.168.4.55 -p 6355 shutdown   // ​先停止Redis服务
修改配置文件
]# vim +673 /etc/redis/​6379.conf                //如图所示

注意:直接在配置文件中修改是有问题的
在下次开启Redis服务时,Redis直接读取 appendonly.aof​​ 文件,会丢失原先存储在dump.rdb文件中的数据​

2.1.2 命令行开启AOF

192.168.4.52:6352> CONFIG get appendonly          //查看是否开启AOF
1) "appendonly"
2) "no"
192.168.4.52:6352> CONFIG set appendonly yes        //开启AOF
OK
192.168.4.52:6352> CONFIG get appendonly             //查看是否开启成功
1) "appendonly"
2) "yes"
192.168.4.52:6352> CONFIG REWRITE                      //写进配置文件​​
OK

2.2 数据恢复

备份数据:备份appendonly.aof文件到其他位置
]# cp /目录/appendonly.aof              /备份目录​​
恢复数据:先关闭备份服务器的Redis服务,删除数据库目录下的appendonly.aof,将备份文件拷贝到数据库目录下,重启备份服务器的Redis服务
]# cp 备份目录/appendonly.aof    /数据库目录下
]# /etc/init.d/redis_6379 start​​​​

2.3 优化配置

2.3.1 定义文件名

appendonly yes           //开启AOF
​appendfilename "appendonly.aof"​          //设置AOF文件名

2.3.2 AOF文件记录写操作方式

appendfsync        always       //实时记录,并完成磁盘同步
appendfsync        everysec    //每秒记录一次,并完成同步(默认)
appendfsync         no        //写入aof,不执行磁盘同步,满足存盘要求时再保存数据​​

2.3.3 日志重写

auto-aof-rewrite-percentage 100         //再次重写,增长百分比
auto-aof-rewrite-min-size 64mb          //首次重写触发值

2.3.4 恢复AOF文件

]# redis-check-aof --fix appendonly.aof
把aof文件恢复到最后一次正确操作​

2.4 AOF的优缺点

• 优点

1. 数据的安全性高,提供了三种同步策略
   1.1 每秒同步:也是一种异步同步.系统宕机时,会丢失最后一秒的数据
   1.2 每修改同步:灭次发生的数据变化都会被记录到磁盘中.工作效率最低
   1.3 无同步:那就是不同步数据
2. 该机制对日志文件的写操作采用的时追加模式,因此及时发生宕机现象,也不会破坏日志文件中已经存在的内容.如果本次操作写了一半数据,系统宕机了,下次redis启动之前,我们可以通过redis-check-aof工具来解决数据一致性的问题.
3. 如果日志文件过大,redis可以自动启用rewrite机制.在redis以追加的形式将修改数据写入到旧的磁盘文件中,同时redis还会创建一个新的文件用于记录此期间,有哪些修改命令被执行.因此rewrite切换时可以保证数据的安全性.
4. AOF包含一个格式清晰,易于理解的日志文件用于记录所有的修改操作

• 缺点

5. AOF文件通常大于RDB文件.RDB文件在恢复大数据集时的速度比AOF的恢复速度快.
6. 根据同步策略的不同,AOF在运行效率上往往会慢于RDB.美妙同步策略的效率比较高,同步禁用的效率和RDB一样高效.

三、选择

如果希望高效的缓存一致性呢,势必会牺牲点性能那么选用AOF;
如果希望写操作频繁的高性能,那么建议RDB

参考资料
https://www.cnblogs.com/AndyAo/p/8135980.html