Redis持久化(重点)
redis数据存储在内存中(更快)，关机/重启数据会丢失—不具有持久性。
要使得redis的数据具有持久性，就需要对数据进行持久化，也就是要存到磁盘，重启时再从磁盘读取数据。
RDB持久化机制(Redis DataBase)
==定期备份机制。==定期把redis中的所有数据写入到硬盘中，生成一个“快照”。
1. 基本介绍
定期备份方式有两种：
1.手动触发“快照”。用户通过客户端执行命令(save，bgsave)进行备份。
(1). save ：阻塞式的进行备份，进程自己停下现在所有的活进行备份，生成“快照”，**会阻塞客户端命令！！**所以一般不用。
(2). bgsave ：(background save) **后台备份，不会影响redis服务器处理客户端的其他请求。**具体是通过多进程的方式实现的—创建子进程，子进程内存中的数据是拷贝父进程的，并且文件描述符表也是一样的，所以完全可以独立的进行备份！！(写时拷贝！！并且一般父进程也不会有大的改动，也就是不会真正拷贝太多，所以效率也很高！！)
2.自动触发“快照”。在配置文件中设置备份的周期，而后自动进行备份。在redis服务器正常关机/重启，主从复制时也会自动触发RDB快照。但是服务器异常退出就不会自动触发RDB快照了。
# 配置文件中 # save 900s 至少一次操作 表示在900s后并且至少有1次操作才会自动触发快照 save 900 1 save 300 10 ... # 关闭自动触发快照 save ""
==生成RDB快照成本还是比较高的，不能太频繁！！！==这就会导致备份的快照和实际内存中的数据大概率会有偏差。
2. RDB文件(二进制文件)
默认保存在/var/lib/redis目录下，可以通过配置文件(/etc/redis/redis.conf)更改。(修改配置文件后要重启服务才能生效)
默认会对RDB文件进行压缩处理，虽然会消耗CPU资源，但是压缩后体积更小，节省硬盘并且方便进行网络传输。
还可以通过redis-check-rdb程序对RDB文件进行校验，查看文件是否损坏。(/usr/bin/redis-check-rdb) 若RDB文件损坏，则重启得到的结果时未定义的！！
redis-check-rdb /var/lib/redis/dump.rdb # 校验RDB文件
RDB文件只有一个，当其已经存在时新生成的RDB文件会替换掉原来的。
当redis服务异常挂了可以查看redis日志：/var/log/redis目录下。
3. RDB持久化的优缺点
优点：
- RDB文件是压缩的二进制文件，代表redis在某个时间点的快照，适合定期全量备份。
- 重启时加载RDB文件恢复更快！！
缺点：
- 不能实时备份，两次快照之间的数据可能会丢失。
- 不同redis版本的RDB文件可能不兼容。
AOF持久化机制(Append Only File)
实时备份机制。
1. 基本介绍
有点像MySQL的binlog，把用户的所有redis操作命令记录下来保存到磁盘中，并定期进行重写压缩。恢复时只需依次执行这些命令即可。(默认关闭AOF)
开启AOF持久化：
# 在 /etc/redis/redis.conf 文件中 appendonly yes # 默认是 no
AOF文件也是保存在/var/lib/redis目录下，和RDB一样。当RDB和AOF持久化策略都开启时以AOF为主！！
并不是每一次redis操作都要写入到磁盘，那样就太慢了！！而是写入到缓冲区，定期刷到磁盘上，减少I/O操作。而且写到磁盘上也是顺序写入。
**但是这样缓冲区中还没有落盘的数据也是有可能会丢失的！！！鱼和熊掌不可兼得。**缓冲区落盘频率越高，对性能影响越大，但是数据丢失的可能更小；缓冲区落盘频率越低，对性能影响越小，但是数据丢失的可能更大。
redis提供了三种缓冲区的刷新策略：(配置文件中 appendfsync)
- always 有命令就落盘！！
- everysec 每秒落盘一次。(默认)
- no 交给操作系统进行落盘。
2. AOF文件(文本文件)
就是一个文本文件，记录每次操作命令。
当AOF文件内容持续增多时会有重写机制：把同一类命令进行合并整理，删除已经不需要的命令…==因为我们只是需要redis内数据的最终状态，中间过程并不关心。==这样可以压缩AOF文件的大小，提升重启时读取恢复的速度。
**其实重写时就是把当前redis内存中的数据进行“命令化”，然后替换原有的文件，而不是去整理已有的AOF文件，显然这样做更简单！！**这就和RDB机制差不多了，记录快照。
重写机制也有手动触发和被动触发两种：(也是创建子进程进行重写，不会阻塞redis服务)
- 手动触发：调用 bgrewriteaof命令。
- 自动触发：设置配置文件中的触发时机。
auto-aof-rewrite-min-size auto-aof-rewrite-percentage
重写流程：注意父进程仍然在处理客户端请求，会==将新的操作写到两个缓冲里，==一个同步到旧的AOF文件，一个同步到新的AOF文件(子进程重写完成后)。这样就能做到实时备份了！
两种备份方式的比较
**没有好坏之分，只有适合与不适合！！**但是当RDB和AOF持久化策略都开启时以AOF为主！！
其实在redis中有结合了两个持久化的特点进行“混合持久化”的倾向！！比如：在AOF重写后是按照RDB的二进制文本方式进行的重写的！！！然后再把缓冲区的记录按照文本文件的方式追加到AOF文件后面。
启时以AOF为主！！
其实在redis中有结合了两个持久化的特点进行“混合持久化”的倾向！！比如：在AOF重写后是按照RDB的二进制文本方式进行的重写的！！！然后再把缓冲区的记录按照文本文件的方式追加到AOF文件后面。
