Redis的持久化指的是将内存中redis数据库运行的数据,写到硬盘文件上。
Redis持久化的意义主要在于故障恢复,比如你部署一个Redis,作为缓存有可能里边有一些比较重要的数据,如果没有持久化的时候,redis遇到灾难性故障的时候就会丢失所有的数据。
Redis持久化的两种方式:
2.1 介绍
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式,这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
在redis.conf配置文件中默认有此下配置:
save 900 1 #在900秒(15分钟)之后,如果至少有1个key发生变化,Redis就会自动触发BGSAVE命令创建快照。 save 300 10 #在300秒(5分钟)之后,如果至少有10个key发生变化,Redis就会自动触发BGSAVE命令创建快照。 save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生变化,Redis就会自动触发BGSAVE命令创建快照。
当满足条件时,redis需要执行RDB的时候服务器会执行以下操作:
redis在进行快照的过程中不会对RDB文件进行修改,只有快照结束后才会将旧快照替换成新快照,也就是说任何时候RDB都是完整的
2.2 优缺点
# RDB优点: 1. RDB会生成多个数据文件,每个数据文件都代表了某一个时刻中redis的数据,这种多个数据文件的方式,非常适合做冷备。 2. RDB对redis对外提供读写服务的时候,影响非常小,因为redis 主进程只需要fork一个子进程出来,让子进程对磁盘io来进行rdb持久化 3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。 # RDB缺点 1. 如果redis要故障时要尽可能少的丢失数据,RDB没有AOF好,例如1:00进行的快照,在1:10又要进行快照的时候宕机了,这个时候就会丢失10分钟的数据。 2. RDB每次fork出子进程来执行RDB快照生成文件时,如果文件特别大,可能会导致客户端提供服务暂停数毫秒或者几秒
3.1 介绍
与快照持久化相比,AOF持久化 的实时性更好,因此已成为主流的持久化方案。默认情况下Redis没有开启 AOF(append only file)方式的持久化,可以在redis.conf配置文件通过appendonly参数开启:
appendonly yes
在Redis的配置文件中存在三种不同的 AOF 持久化方式,它们分别是:
appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度 appendfsync everysec #每秒钟同步一次,显示地将多个写命令同步到硬盘 appendfsync no #让操作系统决定何时进行同步
为了兼顾数据和写入性能,用户可以考虑 appendfsync everysec选项 ,让Redis每秒同步一次AOF文件,Redis性能 几乎没受到任何影响。而且这样即使出现系统崩溃,用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操 作的时候,Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
redis中的数据是有一定限量的,不可能说redis中的数据无限增长,进而导致AOF文件无限增长。内存大小是一定的,等到了一定大小, redis 会采用淘汰策略自动将内存中的数据清除掉。 AOF是存放每条写命令的,所以会不断的增大,当大到一定程度时,AOF会做rewrite操作,rewrite操作就是基于当时redis的数据重新构造一个小的AOF文件,然后将大的AOF文件删除。
3.2 优缺点
# AOF的优点: 1. AOF可以更好的保护数据不丢失,一般AOF会以每隔1秒,通过后台的一个线程去执行一次fsync操作,如果redis进程挂掉,最多丢失1秒的数据。 2. AOF以appen-only的模式写入,所以没有任何磁盘寻址的开销,写入性能非常高。 3. AOF日志文件的命令通过非常可读的方式进行记录,这个非常适合做灾难性的误删除紧急恢复,如果某人不小心用flushall命令清空了所有数据,只要这个时候还没有执行rewrite,那么就可以将日志文件中的flushall删除,进行恢复。 # AOF的缺点 1. 对于同一份文件AOF文件比RDB数据快照要大。 2. AOF开启后支持写的QPS会比RDB支持的写的QPS低,因为AOF一般会配置成每秒fsync操作,每秒的fsync操作还是很高的 3. 数据恢复比较慢,不适合做冷备。
4.1 RDB和AOF选择
4.2 AOF 重写机制
4.2.1 介绍
本文系作者在时代Java发表,未经许可,不得转载。
如有侵权,请联系nowjava@qq.com删除。