【redis】-- redis的持久化（作为数据库）
redis是一个基于内存的数据库，故在redis正在运行的数据都在内存中，而内存掉电，内存上所以数据都会消失。故把redis当成数据库使用时就需要对redis进行持久化。
在说redis持久化的时候，我们先来聊聊其他的知识。linux的父子进程。在Linux中使用fork()函数会给当前正在运行的进程创建一个子进程。那么现在问题就来了，fork时父子进程中的数据有什么关系呢？一般说到进程我们都会知道进程间彼此是数据隔离的。然而实际上，子进程在刚创建时，可以看到子进程中的数据。而在修改该数据时，却不会对父进程造成影响。同样子进程也不会受到父进程修改数据的影响。而造成这种现象的，正是因为linux的copy on write机制。
copy on write：是一种内核机制，通俗来讲就是写时复制。及创建子进程并不发生复制，创建子进程后父子进程共用数据。只有在修改数据是才会创建新的空间。
这样做的好处是创建进程变快了。而且根据开发经验，我们创建子进程后不可能父子进程把所有数据都改一遍。而这套机制就是指针支撑的。玩的是指针
redis中有两种数据到存储方式，rdb和aof。下面我们来着重讲一下这两种持久化方式：
1.RDB
rdb持久化的方式
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
redis的rdb持久化方式有存储的是时点数据即某一个时间点的数据。因为如果存储实时更新的数据的话，如果一直有数据写入会导致，持久化过程一直进行，降低了redis的快捷的特性。因此redis有两种持久化数据的方式
- save：前台更新数据，如果使用这种方法持久化，那么只能在服务器停机维护时，发生因为它会阻塞redis进程造成redis的服务不可用。
- bgsave：后台运行，该命令的原理是，创建一个子进程来进行redis的持久化，而redis依然提供服务。此时就用到了刚才讲到的copy on write机制，父子进程共用了一套数据。
以上两个命令直接可以在redis的客户端运行。
注意如果使用配置文件的方式配置数据持久化，配置文件中给出bgsave的规则： save这个标识。配置的规则：(要修改的文件是dbfilename dump.rdb，文件一般存储在var/lib/redis/6379)
save 900 1
save 300 10
save 60 10000
该规则意味着，在每60秒检测一次redis的数据量，如果达到10000就进行持久化，否则不持久化。在每300秒检测一次redis的数据量，如果达到10就进行持久化，否则不持久化。在每900秒检测一次redis的数据量，如果达到1就进行持久化，否则不持久化。
rdb方式的优点：
- RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
- RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
- RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
- 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.
rdb的缺点
- 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
- RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.
- 不支持拉链化，只有一个rdb文件
- 丢失数据相对多一些时点与时点之间窗口数据容易丢失。8点得到一个rdb，9点刚要写一个rdb，挂机了。那么8~9之间的数据就会丢失。
2.AOF
AOF实际是把对redis操作的操作记录，通过日志的方式记录下来，这样想要恢复数据库文件，只需要把所以指令执行一遍就行。
需要开启aof只需要把dump修改appendonly该为yes即可。
appendonly yes
aof的优点
- 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
- AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态
aof的缺点
弊端，体量无线变大， 恢复慢
为解决aof的弊端日志，优点如果能保住，还是可以用的。就有一个方案：设计一个方案让日志，AOF足够小
就是hdfs，fsimage+edits.log 。让日志只记录增量，合并操作的中间过程。
而4.0版本也是这项技术的分界点
- 4.0以前进行重写时，删除抵消的命令合并重复的命令。这样最终也是一个纯指令的日志文件
- 4.0以后将老的数据RDB到aof文件中，将增量的以指令的方式Append到AOFAOF是一个混合体。其利用了RDB的快，利用了日志的全量
从这点可以看出，aof和rdb是可以共存的。
3.持久化的其他特性
日志重写
Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild）。执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写， 具体信息请查看 2.4 的示例配置文件。
工作原理
AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制:
- Redis 执行 fork() ，现在同时拥有父进程和子进程。子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
- 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
redis的持久化想要开启其实挺简单的只需要，修改conf配置文件的几个配置项即可。
rdb和aof混合使用
当二者混合使用时，如果redis服务器停止后重新运行，那么redis恢复数据只会从aof中同步，而不会去向rdb同步。而且在主从复制时，rdb会记录上一次连接的端口，而aof不会。所以主从复制时，如果没有开启aof，那么从服务器在断开主服务器后重新连接主服务器，只会同步从服务器断开时的增量数据，而开启aof后从服务器需要同步主服务器中的所有内容。
