Redis持久化

什么是持久化？

       将数据（如内存中的对象）保存到可永久保存的存储设备中。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、 XML 数据文件中等等。

 

从应用层与系统层理解持久化

应用层：如果关闭( Close )你的应用然后重新启动则先前的数据依然存在。

系统层：如果关闭( Shutdown )你的系统（电脑）然后重新启动则先前的数据依然存在。

 

Redis 为什么要持久化？

Redis 中的数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis 支持各种不同方式的排序。与 Memcached 一样，为了保证效率，数据都是缓存在内存中。

当你重启系统或者关闭系统后，缓存在内存中的数据都会消失殆尽，再也找不回来了。所以，为了让数据能够长期保存，就要将 Redis 放在缓存中的数据做持久化存储。

redis加载流程图：

Redis 怎么实现持久化？

在设计之初，Redis 就已经考虑到了这个问题。官方提供了多种不同级别的数据持久化的方式：

1、RDB持久化方式

1.1 RDB持久化是什么？

　　RDB持久化是把当前内存中的数据集快照（napshot 快照）写入磁盘，恢复时是将快照文件直接读到内存里。

能够在指定的时间间隔能对你的数据进行快照存储。

1.2 触发方式： 自动触发和手动触发。

1.2.1 自动触发

　　在 redis.conf 配置文件中的 SNAPSHOTTING 下

 

 

save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。

比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（这个命令下面会介绍，手动触发RDB持久化的命令）

配置文件默认策略如下，他们之间的关系是或：

save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存 
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存 
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

只用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save ""

 

stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

dbfilename ：设置快照的文件名，默认是 dump.rdb

dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。

　　也就是说通过在配置文件中配置的 save 方式，当实际操作满足该配置形式时就会进行 RDB 持久化，将当前的内存快照保存在 dir 配置的目录中，文件名由配置的 dbfilename 决定。

 

1.2.2手动触发

手动触发Redis进行RDB持久化的命令有两种：

1、save

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。

2、bgsave

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

　　基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

　　ps:执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的，无意义

1.2.3 恢复数据

　　将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

　　获取 redis 的安装目录可以使用 config get dir 命令

 

1.2.4 停止 RDB 持久化

　　有些情况下，我们只想利用Redis的缓存功能，并不像使用 Redis 的持久化功能，那么这时候我们最好停掉 RDB 持久化。可以通过上面讲的在配置文件 redis.conf 中，可以注释掉所有的 save 行来停用保存功能或者直接一个空字符串来实现停用：save ""

　　也可以通过命令：

redis-cli config set save " "

 

1.2.5 RDB 的优势和劣势

　　①、优势

　　1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

　　2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

　　3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

　　②、劣势

　　1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)

　　2、RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)

　　3、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

 

1.2.6 RDB 自动保存的原理

Redis有个服务器状态结构：

struct redisService{
     //1、记录保存save条件的数组
     struct saveparam *saveparams;
     //2、修改计数器
     long long dirty;
     //3、上一次执行保存的时间
     time_t lastsave;
}

 

1、首先看记录保存save条件的数组 saveparam，里面每个元素都是一个 saveparams 结构：

struct saveparam{
     //秒数
     time_t seconds;
     //修改数
     int changes;
};

前面我们在 redis.conf 配置文件中进行了关于save 的配置：

save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

 

那么服务器状态中的saveparam 数组将会是如下的样子：

 

2、dirty 计数器和lastsave 属性

　　dirty 计数器记录距离上一次成功执行 save 命令或者 bgsave 命令之后，Redis服务器进行了多少次修改（包括写入、删除、更新等操作）。

　　lastsave 属性是一个时间戳，记录上一次成功执行 save 命令或者 bgsave 命令的时间。

　　通过这两个命令，当服务器成功执行一次修改操作，那么dirty 计数器就会加 1，而lastsave 属性记录上一次执行save或bgsave的时间，Redis 服务器还有一个周期性操作函数 severCron ,默认每隔 100 毫秒就会执行一次，该函数会遍历并检查 saveparams 数组中的所有保存条件，只要有一个条件被满足，那么就会执行 bgsave 命令。

　　执行完成之后，dirty 计数器更新为 0 ，lastsave 也更新为执行命令的完成时间。

 

 

 

2、AOF持久化方式 aof(--fix) ls -l --block-size=M

2.1 是什么？

AOF命令以redis协议将Redis的操作日志以追加（有序）的方式写入文件（读操作是不记录的）

当服务器重启的时候会重新执行这些命令来恢复原始的数据。

Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。

2.2 持久化文件在哪？

记录到 appendonly.aof 文件

配置文件中的appendonly修改为yes。开启AOF持久化后，你所执行的每一条指令，都会被记录到appendonly.aof文件中。但事实上，并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存，在接下来的策略中，配置多久来从硬盘缓存写入到硬盘文件。所以在一定程度一定条件下，还是会有数据丢失，不过你可以大大减少数据损失。

 

2.3 触发机制（根据配置文件配置项）

appendfsync no: 表示等操作系统进行数据缓存同步到磁盘，不主动进行同步操作，是默认30s一次（快，持久化没保证）

appendfsync always: 同步持久化，每次发生数据变更时，立即记录到磁盘（慢，安全）

appendfsync everysec: 表示每秒同步一次（默认值，很快，但可能会丢失一秒以内的数据，总体 数据安全性能又高）

2.4 aof重写机制

1. bgrewiriteaof :

当AOF文件增长到一定大小的时候Redis能够调用 bgrewiriteaof 对日志文件进行重写。

bgrewriteaof命令是手动重写命令，会fork子进程，在临时文件中重建数据库状态，对原aof无任何影响，当重建旧的状态后，也会把fork 发生后的一段时间内的数据一并追加到临时文件，最后替换原有aof文件，新的命令继续向新的aof文件中追加。

redis重写流程图：

 

2. auto-aof-rewrite-percentage 100

当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。

3. auto-aof-rewrite-min-size 64mb

当AOF文件大小大于该配置项时自动开启重写

4. 优化策略

AOF有序的记录了redis的命令操作。意外情况下数据丢失甚少。他不断地对aof文件添加操作日志记录，文件会越发变得庞大

但redis会有优化的策略，比如：

1. 对一个key1键的操作，set key1 1 ,  set key1 2, set key1 3。那优化的结果就是将前两条去掉，记录 set key1 3。

2. 给key1、key2、key3 赋值：set key1 1 , set key2 2 , set key3 3。那优化的结果就是 mset key1 1 key2 2 key3 3。

（Redis Mset 命令用于同时设置一个或多个 key-value 对）

 

2.5、redis4.0后混合持久化机制

你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,

因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

redis加载流程图：