Redis持久化方案

Posted 2020-11-25 ddqy

1    Redis持久化方案

Redis是一个内存数据库，为了保证数据的持久性，它提供了两种持久化方案:

l  RDB方式（默认）

l  AOF方式

1.1   RDB方式

1.1.1介绍

l  RDB是Redis默认采用的持久化方式。

l  RDB方式是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

l  Redis会在指定的情况下触发快照

1.     符合自定义配置的快照规则

2.     执行save或者bgsave命令

3.     执行flushall命令

4.     执行主从复制操作

l  在redis.conf中设置自定义快照规则

1.     RDB持久化条件

       格式：save <seconds> <changes>

      

       示例：

       save 900 1  ： 表示15分钟（900秒钟）内至少1个键被更改则进行快照。

       save 300 10 ： 表示5分钟（300秒）内至少10个键被更改则进行快照。

    save 60 10000 ：表示1分钟内至少10000个键被更改则进行快照。

      

       可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系。

 

save 900 1 save 300 10 save 60 10000

 

2.     配置dir指定rdb快照文件的位置

# Note that you must specify a directory here, not a file name. dir ./

 

 

3.     配置dbfilename指定rdb快照文件的名称

# The filename where to dump the DB dbfilename dump.rdb

 

l  特别说明：

       * Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。

       * 根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。

 

 

1.1.2快照的实现原理

l  快照过程

1.    redis使用fork函数复制一份当前进程的副本(子进程)

2.    父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。

3.    当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。  

 

l  注意事项

1.     redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。 

2.     这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份， RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

1.1.3RDB优缺点

l  缺点：使用RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化

l  优点： RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无序执行任何磁盘I/O操作。同时这个也是一个缺点，如果数据集比较大的时候，fork可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求；

1.2   AOF方式

1.2.1介绍

l  默认情况下Redis没有开启AOF（append only file）方式的持久化

l  开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。

l  可以通过修改redis.conf配置文件中的appendonly参数开启

appendonly yes

l  AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。

dir ./

l  默认的文件名是appendonly.aof，可以通过appendfilename参数修改：

appendfilename appendonly.aof

 

1.2.2AOF重写原理（优化AOF文件）

l  Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写

l  重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。

l  整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

l  AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松

 

l  参数说明

# auto-aof-rewrite-percentage 100  表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准

# auto-aof-rewrite-min-size 64mb   限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化

 

1.2.3同步磁盘数据

Redis每次更改数据的时候， aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存。再通过硬盘缓存机制去刷新到保存到文件

 

l  参数说明：

* appendfsync always  每次执行写入都会进行同步  ， 这个是最安全但是是效率比较低的方式

* appendfsync everysec   每一秒执行

* appendfsync no  不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式

1.2.4AOF文件损坏以后如何修复

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。

当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

1.     为现有的 AOF 文件创建一个备份。

2.     使用 Redis 附带的 redis-check-aof程序，对原来的 AOF 文件进行修复。

redis-check-aof --fix readonly.aof

3.     重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

1.3   如何选择RDB和AOF

l  一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。

l  如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。

l  有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。

 

l  两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么Redis重启时，会优先使用AOF文件来还原数据

1    Redis持久化方案

Redis是一个内存数据库，为了保证数据的持久性，它提供了两种持久化方案:

l  RDB方式（默认）

l  AOF方式

1.1   RDB方式

1.1.1介绍

l  RDB是Redis默认采用的持久化方式。

l  RDB方式是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

l  Redis会在指定的情况下触发快照

1.     符合自定义配置的快照规则

2.     执行save或者bgsave命令

3.     执行flushall命令

4.     执行主从复制操作

l  在redis.conf中设置自定义快照规则

1.     RDB持久化条件

       格式：save <seconds> <changes>

      

       示例：

       save 900 1  ： 表示15分钟（900秒钟）内至少1个键被更改则进行快照。

       save 300 10 ： 表示5分钟（300秒）内至少10个键被更改则进行快照。

    save 60 10000 ：表示1分钟内至少10000个键被更改则进行快照。

      

       可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系。

 

save 900 1 save 300 10 save 60 10000

 

2.     配置dir指定rdb快照文件的位置

# Note that you must specify a directory here, not a file name. dir ./

 

 

3.     配置dbfilename指定rdb快照文件的名称

# The filename where to dump the DB dbfilename dump.rdb

 

l  特别说明：

       * Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。

       * 根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。

 

 

1.1.2快照的实现原理

l  快照过程

1.    redis使用fork函数复制一份当前进程的副本(子进程)

2.    父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。

3.    当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。  

 

l  注意事项

1.     redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。 

2.     这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份， RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

1.1.3RDB优缺点

l  缺点：使用RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化

l  优点： RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无序执行任何磁盘I/O操作。同时这个也是一个缺点，如果数据集比较大的时候，fork可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求；

1.2   AOF方式

1.2.1介绍

l  默认情况下Redis没有开启AOF（append only file）方式的持久化

l  开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。

l  可以通过修改redis.conf配置文件中的appendonly参数开启

appendonly yes

l  AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。

dir ./

l  默认的文件名是appendonly.aof，可以通过appendfilename参数修改：

appendfilename appendonly.aof

 

1.2.2AOF重写原理（优化AOF文件）

l  Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写

l  重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。

l  整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

l  AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松

 

l  参数说明

# auto-aof-rewrite-percentage 100  表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准

# auto-aof-rewrite-min-size 64mb   限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化

 

1.2.3同步磁盘数据

Redis每次更改数据的时候， aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存。再通过硬盘缓存机制去刷新到保存到文件

 

l  参数说明：

* appendfsync always  每次执行写入都会进行同步  ， 这个是最安全但是是效率比较低的方式

* appendfsync everysec   每一秒执行

* appendfsync no  不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式

1.2.4AOF文件损坏以后如何修复

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。

当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

1.     为现有的 AOF 文件创建一个备份。

2.     使用 Redis 附带的 redis-check-aof程序，对原来的 AOF 文件进行修复。

redis-check-aof --fix readonly.aof

3.     重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

1.3   如何选择RDB和AOF

l  一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。

l  如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。

l  有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。

l  两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么Redis重启时，会优先使用AOF文件来还原数据