Redis 持久化

1：RDB (快照)

save <seconds> <changes> N 秒内数据集至少有 M 个改动

同时满足2个条件 比如每900s至少有1个key发生变化，触发一次快照

 

 

redis会创建(fork)一个子进程来做持久化的工作，会先将数据写入一个临时文件中，等到持久化结束后，再将这个临时文件替换上次持久化好的文件。这个过程当中只有子进程来负责IO操作，主进程仍然处理客户端的请求，这么干确保了极高的性能。

默认情况下 redis将数据库快照保存名字为dump.rdb的二进制文件中

 

优点：

a:如果要进行大规模的数据恢复，RDB要比AOF恢复速度快

b:RDB可以最大化redis性能，父进程干的事情就是fork子进程，然后接着干自己份内的事情(接收客户端的请求)父进程不需要进行IO操作 子进程负责持久化

c:RDB是一个非常紧凑的文件，它就是保存了某一个时间点的数据集，很适合做备份，非常适合做容灾恢复，只有一个文件嘛，内容紧凑，通过备份原文件到本机外的其他主机，如果本机宕机了，把文件拷贝到redis的安装目录下，启动redis 数据就能很快恢复了

缺点:

a:不太适合对数据要求严格的情况，如果上次保存到下次保存这段时间内宕机的话，这部分数据会丢失，尽管你修改保存的频率，但是还是没法避免

b:每次RDB时父进程都要fork一个子进程，由子进程来负责持久化操作，如果数据量比较大，那么fork出子进程的这个操作是非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求，果数据集巨大并且CPU性能不是很好的情况下，这种情况会持续1秒。

 

2：AOF（追加日志）

以日志的形式记录redis的每一个写操作，只永许追加文件不能更改文件，redis启动的时候会读取这个appendonly.aof文件来实现对数据的恢复 redis默认不开始哦

 

2：AOF持久化的方式

 

always：每次数据发生改变都会持久化到磁盘上，性能差，但是数据完整性好

everysec:每秒内记录操作，异步操作，如果一秒内宕机了，会有数据丢失

no:不主动进行写文件，而是完全由操作系统来决定(即每30s一次)这是最快但最不安全的方式。

如果AOF一直对同一个文件追加，可能导致appendonly.aof 文件过于庞大，为了避免这种情况redis新增加了重写机制，当这个文件大小超过阈值时redis会自动启用AOF文件的压缩，只保留可以恢复数据的最小指令集 可以用命令bgrewiteaof

重写的原理:主进程fork一个子进程出来负责重写文件(也是先临时文件在rename)，遍历新进程的内存数据，每条记录都会有一条set，重写aof文件，这一些列操作当中并没有读取旧的aof文件，而是将内存中的数据库内容以redis 命令的形式重新生成了一份aof文件，重写操作有点像RDB的快照。重写期间父进程继续接受客户端的请求，此时父进程除了把新来的命令写入原aof文件中，同时把收到的写命令缓存起来，这部分命令是子进程在进行快照期间发生的操作，等子进程把临时快照处理完成之后，子进程发送信号通知父进程，然后父进程把缓存的指令追加到文件中去，追加完之后父进程才能用临时文件替换原来的aof文件，否则快照期间的新来的写指令只被父进程写入到了旧的aof文件中，临时文件并没有写入，临时文件替换原来的aof文件就会导致命令丢失。

重写的触发机制:redi会记录上一次重写是的aof文件大小，默认配置是当前AOF文件大小是上一次大小的一倍并且大于64mb时，会触发重写机制

 

优点：

a:AOF只对日志文件进行追加，因此对AOF文件的写入不需要进行seek，即使在追加的过程中，写入了不完整的命令（例如：磁盘已满），可以使用redis-check-aof工具可以修复这种问题

b:AOF日志文件过大时会触发重写机制，整个重写过程还是非常安全的，即使重写过程中宕机了，现有的AOF文件还在，一旦新的AOF文件创建好了，redis就会从旧的AOF文件切换到新的文件，后边的追加就会往这个新的文件中追加了。

c:AOF文件有序地保存了对数据库执行的所有写入操作,这些写入操作一Redis协议的格式保存，易于对文件进行分析.

d:AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求)，并且就算发生故障停机，也最多只会丢失一秒钟的数据

缺点：

a:对于相同的数据集合AOF文件要比RDB要大

b:根据所使用的持久化策略来说，AOF的速度要慢与RDB。一般情况下，每秒同步策略效果较好。不使用同步策略的情况下，AOF与RDB速度一样快。

 

RDB与AOF如何选择

一般来说，如果想达到足以媲美PostgreSQL的数据安全性，应该同时使用两种持久化方式。

有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug。

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

 

当同时选择2中持久化方式时，会有rdb和aof两个文件所以重启Redis时，如果dump.rdb与appendfsync.aof同时都存在时，Redis会自动读取appendfsync.aof文件，通过该文件中对数据库的日志操作，来实现数据的恢复。当然如果该文件被破坏，我们可以通过redis-check-aof工具来修复，如redis-check-aof --fix能修复破损的appendfsync.aof文件，当然如果dump.rdb文件有破损，我们也可以用redis-check-rdb工具来修复，如果appendfsync.aof文件破损了，是启动不了客户端的，也就是无法完成数据的恢复

	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定

手动持久化

save bgsave

bgrewriteaof

在新的redis版本中，bgsave执行过程中不可以执行bgrewriteaof。反过来说在bgrewriteaof执行过程中也不可以执行bgsave。这是为了防止两个redis后台进程同时对磁盘进行大量的IO操作。如果bgsave正在执行，并且用户显示调用bgrewriteaof命令，此时服务器会向用户回复一个OK状态，并告知用户bgrewriteaof已经被预定执行，一旦bgsave执行完毕，bgrewriteaof就会正式开始执行。redis在安全方面还是做的蛮周到的，不然2个进程在后台同时进行IO操作，有可能会把redis搞挂了。。。。。

命令	save	bgsave
IO类型	同步	异步
阻塞？	是	是（阻塞发生在fock()，通常非常快）
复杂度	O(n)	O(n)
优点	不会消耗额外的内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fock子进程，消耗内存

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

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

2：用户执行save或者bgsave命令

save指令 redis同步进行快照，执行快照期间阻塞所有来自客户端的请求。当数据库中的数据较多时，快照可能耗费比较长的时间。

bgsave指令 redis异步进行快照同时立即给客户端返回OK，可以通过lastsave命令获取最近一次成功执行快照的时间，返回一个unix时间戳

3：执行flushall命令

flushall执行时，redis会清除数据库中所有的数据。如果没有定义自动快照条件时，执行flushall不会进行快照。如果定义了条件，不论清空数据库的过程是否满足自动快照的条件，只要定义了条件redis就会进行快照，哪怕只有一个键值被更改

4：执行复制(replication)时

当设置了主从，redis会在复制初始化时进行自动快照。即使没有定义自动快照的条件，并且没有手动执行快照操作，也会产生RDB快照文件，redis集群中会有记录哦