Redis的持久化方式
记录一下持久化的使用方式吧,主要是RDB和AOF两种。
1、RDB快照持久化方式
1、1 如何处罚RDB持久化
- 手动save命令
- 手动bgsave命令
- 通过配置文件自动触发
1、1、2save和bgsave的区别
save命令
该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止。具体流程如下:
执行流程:
1、开启服务。
redis-server redis.conf
redis-cli
2、添加一条数据
set k1 v1
3、执行save持久化命令
save
此时再次查看文件夹内容,发现多了一个dump.rdb文件,这个就是执行了save命令后保存的数据文件。
注意:如果执行了save,也看见ok了,但是没有看见.rdb文件,那么就执行下面的命令,看看在哪个路径下。
find / -name dump.rdb
如果所在目录在其他地方,先进入文件所在目录,执行mv移动命令。
mv dump.rdb /这是你想要放的目录,从根目录开始输入
但是这样不行,每次生成文件都需要移动,很不方便,进入redis.conf配置文件。
4、确认redis服务是否关闭
ps -ef | grep redis
5、再次启动redis服务,会自动读取文件。
redis-server redis.conf
redis-cli
6、查看所有,看看是否读取到了内容,读到了就说明成功了。
7、执行完成时候如果存在老的RDB文件,就把新的替代掉旧的。但是我们的客户端可能都是几万或者是几十万,这种方式显然不可取。
bgsave命令
执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体流程如下:
具体流程:
1、修改redis.conf配置文件。
这里的save 30 1:指的是每30秒内,如果发生一次修改就进行bgsave。
这里可以任意修改数值。
2、添加数据,测试是否会自动生成**.rdb**文件。
添加一条数据后,再次查看所有文件,发现已经生成.rdb文件,测试成功。
小总结一下rdb的优缺点。
优点:
- RDB文件紧凑,全量备份,非常适合用于进行备份和灾难恢复。
- 生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点: - 快照持久化期间修改的数据不会被保存,可能丢失数据。数据完整性比较差。
这里发现我说了一个名词AOF,下面就要说一种更加高效的方式AOF。
AOF:AOF的工作机制很简单,redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。具体流程如下:
具体流程:
1、先修改redis.conf配置文件
将appendonly no修改成yes,下面
开启第一个,把第二个注释掉。
总结一下:
优点:
(1)AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync操作,最多丢失1秒钟的数据。
(2)AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易破损。
(3)AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。
缺点:
(1)对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大.
(2) 恢复数据时时间要比快照模式慢很多。