Redis学习之持久化
前言
在前面我们学习了Redis的基本操作，也学习了Redis的Java客户端Jedis的使用，接下来我们来学习Redis的持久化。
在前面的学习中，我们知道Redis是基于内存的键值对数据库，众所周知，基于内存的数据会在内存断电之后丢失，所以，如果Redis中没有持久化机制，那么，当Redis服务器重启之后，存储的数据就丢失了，这显示是不能接受的，所幸，Redis有持久化机制，本小节我们就来学习这部分的内容。
持久化
Redis支持两种不同的持久化方式，RDB以及AOF，RDB会定时将内存中的数据存储在硬盘上，而AOF则是每次将命令记录下来，Redis中这两种方式可以单独使用，也可以混合使用。
RDB方式
RDB持久化是通过快照的方式完成的，当符合一定条件时，Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上
触发条件
- 根据配置规则进行自动快照
- 用户执行save或者bgsave命令
- 执行flushall命令
- 执行复制时
配置规则
配置规则配置在Redis的配置文件中，save命令后面跟一个时间窗口大小以及该时间内被修改的键的个数，举例如下
save 900 1 # 900秒内至少一个键被修改
save 300 10 # 300秒内至少十个键被修改
save 60 10000 # 60秒内至少10000个键被修改
多个规则之间是或的关系，也就是只要其中一个条件满足，则触发RDB持久化
save/bgsave命令
save命令是前台操作，命令执行后Redis会阻塞所有的客户端请求，在生产环境中不建议使用
bgsave执行之后，Redis会在后台执行快照操作(异步)，快照的同时服务器可以继续响应客户端请求
flushall命令
执行flushall时，Redis会清除数据库中所有数据，无论清空数据库的过程是否满足触发条件，只要自动快照条件不为空，则会进行快照操作
快照原理
Redis默认将快照文件存储在当前进程工作目录下的dump.rdb文件中，可以通过配置dbfilename FILENAME来指定文件的名称，通过dir PATH来指定工作的目录
快照过程
- Reids使用fork系统调用产生子进程
- 父进程继续处理请求，子进程开始将内存中的数据写入临时文件
- 当子进程完成所有数据的写入操作后，将该临时文件替换旧的RDB文件，完成快照操作
由于fork操作采用的是写时复制策略，所以，如果父进程没有进行操作，子进程与父进程共享同份内存，如果父进程发生写入操作，则子进程会复制一份父进程的内存空间，所以，快照的内容其实只是fork时刻的内存，而不是实时的数据。
RDB文件是经过压缩的，可以通过配置rdbcompression yes/no来决定是否启动压缩功能，启动压缩功能会消耗多一点CPU资源，但减少文件的大小。
Redis启动后会自动读取RDB文件，并将数据从硬盘载入到内存中。
AOF方式
AOF是将每条命令追加到硬盘中，可以通过appendonly yes/no来启用，通过appendfilename FILENAME来设置AOF文件的名称，存储位置也是dir指定的目录之下。
默认情况下AOF会记录所有的操作，当命令重复比较大的情况下，会比较消耗空间，所以，Redis提供了重写AOF的功能，可以通过auto-aof-rewrite-percentage PERCENT、auto-aof-rewrite-min-size SIZE来配置自动重写的触发条件
auto-aof-rewrite-percentage表示当前的AOF文件的大小超过上一次重写时AOF文件大小的百分比时会自动重写，如果之前没有重写过，则以启动时的AOF文件大小为基准。
auto-aof-rewrite-min-size表示允许重写的最小AOF文件大小
可以通过bgrewriteaof来手动触发重写
由于OS本身会对写入磁盘的数据做缓存，所以虽然AOF是将每条命令写入到磁盘中，但是实际上并不会实时刷新到硬盘中，所以，如果需要实时写入，需要配置如下内容
#appendfsync always #每次写入，会对性能有影响
appendfsync everysec # 每秒写入
# appendfsync no # 由OS来决定写入时间
如果同时开启AOF和RDB，Redis会在重启之后使用AOF来恢复数据，毕竟AOF丢失的数据量比较少
总结
本小节我们主要学习了Redis的两种持久化方式，RDB和AOF，RDB是根据触发条件对内存的数据执行一次快照操作，AOF则是将每次操作的命令记录下来。两种方式中，Redis默认启用的是RDB方式，AOF则需要我们手动开启，相比于RDB，AOF能保存的数据更加完整，所以如果两者都启用，Redis重启的时候，以AOF为基准进行数据的恢复。
