前言

  Redis的强劲性能很大程度上是由于其将所有数据都存储在了内存中，然而当Redis重启后，所有存储在内存中的数据就会丢失。在一些情况下，我们会希望Redis在重启后能保证数据不丢失，例如：

  1. 将Redis作为数据库使用时；
  2. 将Reids作为缓存服务器。

这时我们希望Reids能将数据从内存中以某种形式同步到硬盘中，使得重启后可以根据硬盘中的记录恢复数据，这一过程就是持久化。

  Redis支持两种方式的持久化，一种 RDB 方式，另一种是 AOF 方式。前者会根据指定的规则“定时”将内存中的数据存储到硬盘中，而后者在每次执行命令后将命令本身记录下来。两种持久化方式可以单独使用其中一种，但更多情况下是将二者结合使用。

RDB方式

  RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的所有数据生成一份副本并存储在硬盘中，这个过程即为“快照”。

Redis会在以下几种情况对数据进行快照：

  • 根据配置规则进行自动快照
  • 用户执行 SAVE 或 BGSAVE 命令
  • 执行 FLUSHALL 命令
  • 执行复制（replication）时

1、根据配置规则进行自动快照

  Redis允许用户自定义快照条件，当符合快照条件时，Redis会自动执行快照操作。进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间窗口 M 和改动的键的个数 N 。每当时间M内被更改的键的个数大于N时，即符合自动快照条件。

在我服务器配置文件目录（/etc/redis/6379.conf）的样例配置文件中包含预置的3个条件：

# save 3600 1
# save 300 100
# save 60 10000

  每条快照占一行，并且以 save 参数开头。同时可以存在多个条件，条件之间是“或”的关系。就这个例子而言， save 3600 1 的意思是在1小时（3600秒）内有一个或一个以上的键被更改则进行快照。同理，save 300 100 表示在300秒内至少有100个键被修改则进行快照。

2、用户执行 SAVE 或 BGSAVE 命令

  除了让Redis自动执行快照外，当进行服务重启、手动迁移以及备份时，我们也会需要手动执行快照操作。Redis提供了两个命令来完成这一任务。

2.1、 SAVE命令

  当执行SAVE命令时，Redis同步地进行快照操作，在快照执行的过程中会阻塞所有来自客户端的请求。当数据库中的数据比较多时，这一过程会导致Redis较长时间不响应，所以要尽量避免在生产环境中使用这一命令。

使用save命令如下：

127.0.0.1:6379> save
OK

快照已保存

[root@VM-0-17-centos ~]# cd /var/lib/redis/6379
[root@VM-0-17-centos 6379]# ll
total 4
-rw-r--r-- 1 root root 3421 Jun 30 23:06 dump.rdb

2.2、 BGSAVE命令

  需要手动执行快照时推荐使用BGSAVE命令。BGSAVE命令可以在后台异步地进行快照操作，快照的同时服务器还可以继续响应来自客户端的请求。执行BGSAVE后Redis会立即返回 Background saving started 表示开始执行快照操作，如果想知道快照是否完成，可以通过LASTSAVE命令获取最近一次成功执行快照的时间，返回结果是一个Unix时间戳，如：

127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> LASTSAVE
(integer) 1625065899

快照文件已生成：

[root@VM-0-17-centos 6379]# ll
total 4
-rw-r--r-- 1 root root 3421 Jun 30 23:11 dump.rdb

3、执行 FLUSHALL 命令

  当执行 FLUSHALL 命令时，Redis会清楚数据库中的所有数据。需要注意的是，不论清空数据库的过程是否触发了自动快照条件，只要自动快照条件不为空，Redis就会执行一次快照操作。例如当定义的快照条件为当1秒内修改10000个键时进行自动快照，而当数据库里只有一个键时，执行FLUSHALL 命令也会触发快照，即使这一过程实际上只有一个键被修改了。

  当没有定义自动快照条件时，执行FLUSHALL 则不会进行快照。

127.0.0.1:6379> FLUSHALL
OK

快照文件已生成：

[root@VM-0-17-centos 6379]# ll
total 4
-rw-r--r-- 1 root root 92 Jun 30 23:17 dump.rdb

4、执行复制时

  当设置了主从模式时，Redis会在复制初始化时记性自动快照。主从模式和复制将在之后介绍，请等待…

5、快照原理

  理清Redis实现快照的过程对我们了解快照文件的特性有很大的帮助。Reids默认会将快照文件存储在Redis当前进程的工作目录中 dump.rdb 文件中，可以通过配置 dir 和 dbdilename 两个参数分别制定快照文件的存储路径和文件名。如：

redis和cloud那个 redis和rds_Redis


修改完配置文件后，需要重启redis服务后，再进行生成快照文件。

快照文件名称已改变：

[root@VM-0-17-centos 6379]# ll
total 8
-rw-r--r-- 1 root root 104 Jun 30 23:22 dump.rdb
-rw-r--r-- 1 root root 104 Jun 30 23:23 myfile.rdb

快照的过程如下：

  1. Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
  2. 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
  3. 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

提示
  在执行fork的时候操作系统会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。
  写时复制策略也保证了在fork的时刻虽然看上去生成了两份内存副本，但实际上内存的占用量并不会增加一倍。这就意味着当系统内存只有2GB，而Redis数据库的内存有1.5GB时，执行fork后内存使用量并不会增加到3GB（超出物理内存）。
  需要注意的是，当进行快照的过程中，如果写入操作较多，造成fork前后数据差异较大，是会使得内存使用量显著超过实际数据大小的，因为内存中不仅保存了当前的数据库数据，而且还保存着fork时刻的内存数据。进行内存用量估算时很容易忽略这一问题，造成内存用量超限。

  通过上述过程可以发现Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实现Redis数据库备份。RDB文件是经过压缩的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

  Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录1000万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20~30秒。

  通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。例如，使用Redis存储缓存数据时，丢失最近几秒的数据或者丢失最近更新的几十个键并不会有很大的影响。如果数据相对重要，希望将损失降到最小，则可以使用AOF方式进行持久化。

AOF方式

  当使用Redis存储非临时数据时，一般需要打开AOF持久化来降低进程中止导致的数据丢失。AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程显然会降低Redis的性能，但是大部分情况下这个影响是可以接受的，另外使用较快的硬盘可以提高AOF的性能。

1、开启AOF

  默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数启用：

appendonly yes

redis和cloud那个 redis和rds_redis和cloud那个_02

  开启AOF持久化后没执行一条会更改Redis中数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改。

[root@VM-0-17-centos 6379]# ll
total 8
-rw-r--r-- 1 root root 104 Jun 30 23:22 dump.rdb
-rw-r--r-- 1 root root   0 Jul  1 12:27 myappendonly.aof
-rw-r--r-- 1 root root 104 Jul  1 12:27 myfile.rdb

2、AOF的实现

  AOF文件以纯文本的形式记录了Redis执行的写命令，例如在开启AOF持久化的情况下，执行以下4个命令：

set foo 1
set foo 2
set foo 3
get foo

  Redis会将前3条命令写入AOF文件中，此时AOF文件中的内容如下：

*2
$6
SELECT
$1
0
*3
$3
set
$3
foo
$1
1
*3
$3
set
$3
foo
$1
2
*3
$3
set
$3
foo
$1
3

  可见AOF文件的内容正是Redis客户端向Redis发送的原始通信协议的内容，从中可见Redis确实只记录了3条命令。然而这时有一个问题是前2条命令其实都是冗余的，因为这两条的执行结果会被第三条命令覆盖。随着执行的命令越来越多，AOF文件的大小也会越来越大，即使内存中实际的数据可能并没有多少。很自然地，我们希望Redis可以自动优化AOF文件，就上例而言，就是讲前两条无用的记录删除，只保留第三条。实际上Reids也正是这样做的，每当达到一定条件时Redis就会自动重写AOF文件，这个条件可以在配置文件中设置：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

  auto-aof-rewrite-percentage 参数的意义是当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则已启动时的AOF文件大小为依据。
  auto-aof-rewrite-min-size参数限制了允许重写的最小AOF文件大小，通常在AOF文件很小的情况下即使其中有很多荣誉的命令我们也并不太关心。除了让Reids自动执行重写外，我们还可以主动使用BGREWRITEAOF命令手动执行AOF重写。
重写后文件内容如下：

*2
$6
SELECT
$1
0
*3
$3
set
$3
foo
$1
3

  可见冗余的命令已经被删除了。
  文件中的 *2 代表以下有两个命令为一组； $6 表示下面一个命令的长度

3、同步硬盘数据

  虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正地写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来讲启用AOF持久化的应用无法容忍这样的损失，这就需要Redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。在Redis中可以通过appendsync参数设置同步的时机，如下：

# appendfsync always
appendfsync everysec
# appendfsync no

  默认情况下Redis采用everysec规则，即每秒执行一次同步操作。always表示每次执行写入都会执行同步，这是最安全也是最慢的方式。no表示不主动进行同步操作，而是完全交由系统来做（即每30秒一次），这是最快但最不安全的方式。一般情况下使用默认值everysec就足够了，既兼顾了性能又保证了安全。

  Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重启Reids后Reids会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少。

author：su1573
鄙人记录生活点滴，学习并分享，请多指教！！！