RDB技术

概述: 在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

执行过程：

1. Redis会单独创建（fork）一个子进程来进行持久化;
2. 会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
3. 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
4. RDB的缺点是最后一次持久化后的数据可能丢失。
5. fork这个进程的使用就是引进的"写时复制技术"

丢失的原因: 将数据写入到临时文件时,这个时候进程挂掉,剩下的数据就会丢失

配置文件参数解释:

//文件存储的位置
dir
//当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.
stop-writes-on-bgsave-error yes
//如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.
rdbcompression yes
//检查完整性 但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能,推荐yes.
rdbchecksum yes
// saveVS bgsave
save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。
bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。(推荐)
save 秒数 次数

AOF技术

概述:
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件 ,将策略修改为always,不会造成数据丢失

执行过程:

1. 客户端的请求写命令会被append追加到AOF缓冲区内；
2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，只记录最后的操作 ,达到压缩AOF文件容量的要求；
4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

配置参数介绍:

//开启AOF : 默认是不开启的,RDB和AOF都开启默认读取AOF文件
appendonly yes
//AOF同步频率设置 三种模式 : 同步追加/每秒进行同步/交给系统进行同步
appendfsync always/everysec/no