redis-6

redis学习第六章

持久化

因为redis数据存储在内存中，但是我们希望当redis服务器重启后还能保留这些数据，那就需要用到持久化。某些情况下我们需要redis重启后能够保证数据不丢失，例如：
1).将redis作为数据库使用时
2).将redis作为缓存服务器，但是缓存被击穿后会对性能造成较大影响，所有缓存同时失效会导致服务器雪崩，从而使服务器无法响应。
这时我们希望redis能将数据从内存中以某种形式同步到硬盘中，使得重启后可以根据硬盘中的记录回复数据，这一过程就是持久化。

1. RDB方式

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

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

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

redis允许用户自定义快照条件，当符合快照条件时，redis会自动执行快照操作。进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间窗口M和改动的键的个数N。每当时间M内被更改的键的个数大于N时，即符合自动快照条件。如redis安装目录中包含的额阳历配置文件中预置的3个条件：
save 900 1
save 300 10
save 60 10000
每条快照占一行，并且以save参数开头。同时可以存在多个条件，条件之间是“或”的关系。就这个例子而言，save 900 1 的意思是在15分钟内有一个或一个以上的键被更改则进行快照。同理，save 300 10 表示在300秒内至少有10个键被更改则进行快照。

1.2 用户执行save或bgsave

除了让redis自动进行快照外，当进行服务重启、手动迁移以及备份时我们也会需要手动执行快照。

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

1.2.2 bgsave
需要手动执行快照时推荐使用bgsave命令。bgsave命令可以在后台异步地执行快照操作，快照的同时服务器还可以继续响应来自客户端的请求。执行bgsave以后redis会立即返回OK表示开始执行快照操作，如果想知道快照是否执行完成，可以使用lastsave命令获得最后一个成功执行快照的时间戳。

注意 使用自动快照时，redis采用的就是策略就是异步快照

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

1.4 执行复制时
当设置了主从模式时，redis会在复制初始化时进行自动快照。即使没有定义自动快照条件，没有手动执行快照操作，也会生成RDB快照文件。

1.5 快照管理
redis默认将快照文件存储在redis当前进程的工作目录中的dump.rdb文件中，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。快照过程如下：
1).redis使用fork函数复制一份当前进程（父进程）的副本（子进程）
2).父进程继续结束并处理客户端发来的命令，而子进程开始讲内存中的数据写入硬盘中的临时文件
3).大部分子进程写完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

提示 在执行fork的时候操作系统（类unix）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。
写时策略保证了在fork的时刻虽然看上去生成了两份内存副本，但实际上内存的占用量并不会增加一倍。为了保证在执行fork后内存使用量超过最大内存时，我们要确保Linux系统允许应用程序申请超过可用内存（物理内存和交换分区）的空间，方法是在/etc/sysctl.conf文件加入vm.overcommit_memory = 1，然后重启系统或者执行sysctl vm.overcommit_memory = 1确保设置生效。
另外，当进行快照的过程中，如果写入操作较多，造成fork前后数据差异较大，是会使得内存使用量显著超过实际数据大小的，因为内存中不仅保存了当前数据库数据，而且还保存着fork时刻的内存数据。进行内存用量估算时很容易忽略这一问题，造成内存用量超限。

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

redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。一般讲一个记录1000万个字符串类型建、大小为1GB的快照文件载入到内存需要花费20~30秒。

通过RDB方式实现持久化，一旦redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据应用场合，用过组合设置自动快照条件的方式来将可能发生的数据损失控制在能接受的范围内。

2. AOF方式

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

2.1 开启AOF
默认情况下redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数启用：
appendonly yes
开启AOF持久化后每执行一条更改redis中的数据的命令，reids就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：
appendfilename appendonly.aof

2.2 AOF的实现

AOF以文本的方式记录了redis执行的写命令，例如在开启AOF持久化的情况下执行了如下4个命令：
set foo 1
set foo 2
set foo 3
get foo

redis会将前三条命令写入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文件，就上例而言，就是将前两条无用的记录删除，只保留第三条。实际上redis也正是这样做的，每当达到一定条件时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文件很小的情况下即使其中有很多冗余的命令我们也并不太关心。除了让redis自动执行重写外，我们还可以主动使用BGREWRITEAOF命令手动执行AOF重写。

上例中的AOF文件重写后的内容为：

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

可见冗余的命令已经被删除了。重写的过程只和内存中的数据有关，和之前的AOF文件无关，这与RDB很相似，只不过二者的文件格式完全不同。
在启动时redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较AOF要慢些。

2.3 同步硬盘数据

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

#appendfsync always
appendfsync everysec
#appendfsync no

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

redisd允许同时开启AOF和RDB，即保证了数据安全又使得进行备份等操作十分容易。此时重启redis后redis会使用AOF文件来恢复数据。