Redis的持久化方式

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的优缺点。

优点：

1. RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
2. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
   缺点：
4. 快照持久化期间修改的数据不会被保存，可能丢失数据。数据完整性比较差。

这里发现我说了一个名词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) 恢复数据时时间要比快照模式慢很多。