1）什么是持久化
redis所有数据保存在内存中， 对数据的更新将异步地保存到磁盘上
2）Redis持久化的实现方式
* 快照方式
Redis RDB
* 写日志
Redis AOF
3）RDB
* 什么是RDB
* 触发机制-主要三种方式
第一种：save同步
当客户端连接到redis服务器，执行save命令，此时redis会被阻塞，其他客户端的请求就会被阻塞咯，等待save命令执行完毕后
第二种：bgsave异步
当客户端连接redis服务器，执行bgsave命令，此时redis主进程会通过系统调用fork一个子进程出来，阻塞发生在fork阶段，之后父进程还可以正常接收请求，有子进程创建生成RDB文件，成功后，通知redis主进程
第三种： 自动配置
save 900 1
save 300 10
save 60 10000
通过在配置文件redis.conf中配置，满足任意一个条件，就触发bgsave命令，通过异步地方式创建RDB文件（二进制）
还有其他方式也会触发生成RDB文件
比如shutdown（关闭redis），debug reload
总结：
RDB是redis内存到硬盘的快照
save通常会阻塞客户端命令
bgsave不会阻塞客户端命令，但是会fork新进程
编写redis.conf文件save命令，满足任意一个条件就会触发执行
比如shutdown，debug reload也会触发生成RDB
4）AOF
* RDB存在的问题
第一：耗时
如果数据量大，耗时时间更长，通过bgsave模式，需要执行fork（），消耗内存资源，磁盘I/O性能
第二：不可靠，会丢失部分数据
比如在上午9点执行了多个写命令，在9点20分钟满足RDB自动创建的条件，此时生成一份RDB文件，然后9点22分钟再次执行了很多写命令，在9点30分钟，redis机器故障，此时还没有触发条件也没有手动save或bgsave，此时从9点20到9点30之间的keys就会被丢失
* 什么是AOF
* AOF三种策略
# appendfsync always
appendfsync everysec （每秒钟写一次）
# appendfsync no
第一种：awlays
redis写命令刷新到缓冲区，然后实时每条命令fsync到硬盘
第二种：everysec
redis写命令刷新到缓冲区，然后每秒把缓冲区的命令fsync到硬盘到
第三种： no
redis写命令刷新到缓冲区，然后又OS系统觉得fsync到硬盘，一般不用
* AOF重写
因为 AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大，执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。
AOF重写的所用：
减少硬盘占有量和加速恢复速度
AOF重写实现的两种方式
第一种：通过bgrewriteaof
client连接redis执行bgrewriteaof命令，redis立即返回ok，然后redis主进程通过fork()生成子进程，由子进程完成AOF重写
第二种：通过aof重写配置
重写过程：
1）redis主进程通过fork创建子进程
2）子进程根据redis内存中的数据创建数据库重建命令序列与临时文件中
3）父进程继续执行client的请求，并会把这些请求中的写操作追加到原来AOF文件，额外，这些新的写请求，也会放到一个缓存队列中
4）当子进程重写完成，会通知父进程，父进程把缓冲的命令追加到临时文件中
5） 父进程用临时文件替换老的AOF文件
配置如下
~~~
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec （每秒钟写一次）
# appendfsync no
no-appendfsync-on-rewrite no（yes）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
dir /var/lib/redis
~~~
[root@huancun01 redis]# ll
total 8
-rw-r--r--. 1 redis redis 1599 Feb 26 16:27 appendonly.aof
-rw-r--r--. 1 redis redis 391 Feb 26 16:34 dump.rdb
