Redis数据持久化
前言
redis 的数据都是存储在内存中，持久化的意义就是将数据保存到硬盘中，来保证数据的可重用性与安全，一旦redis发生断电或者宕机导致数据丢失
概念
在redis中提供了2种持久化方式，AOF(追加文件)和RDB(快照)，AOF会将执行的写命令操作，写入到硬盘中，RBD类型于我们打游戏中的存档操作，它会将某一时刻的数据都写入到硬盘中。
如何选择
如果该redis的数据内容可有可无，不会给网站带来整体大的负担，那其实可以将备份都关闭掉，但如果需要备份的话，又不能接受丢失长时间内的数据那么建议使用aof，反之则可以使用快照备份.
实际使用中，是２种方式结合的使用的，rdb做冷备，aod做热备份
注意：在redis重启过程中，先会读取aof文件（原因：aof文件较rdb完整）
AOF持久化
配置说明
appendonly yes //开启aof持久化
appendfsync always //always每个redis的写命令都写入硬盘，降低redis的QPS（不建议）
appendfsync everysec //everysec每秒执行一次同步，将多个写命令同步到硬盘
appendfsync no //让操作系统决定何时同步（不建议）
appendfilename "appendonly.aof" //aof文件名
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100 // 当AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据；
auto-aof-rewrite-min-size 64mb // 写入超过64M将重新读取一遍内存，而不是重新读取文件
aof-load-truncated yes
appendfsync everysec操作，Redis每秒同步一次AOF文件的性能和不使用任何持久化特性时的性能相差无几，而通过每秒同步一次AOF文件，Redis可以保证，即时出现系统崩溃，用户最多丢失一秒之内产生的数据。
appendonly.aof 文件内容
$3
ddd
$4
1111
$2
ex
$5
10000
不知道是我设置有问题还是啥，我看别的博文当key有过期时间的时候，存的是过期的那个时间戳，而我这存的是有效的时间
AOF优缺点
1. 优点
1. AOF文件的定期重写，可以压缩aof文件。
2. AOF 文件重写就是把 Redis 进程内的数据转化为写命令，然后同步到新的 AOF 文件中。在重写的过程中，Redis 服务器会创建一个新的 AOF 文件来替代现有的 AOF 文件，新、旧两个 AOF 文件所保存的数据库状态相同，但是新的 AOF 文件不会包含冗余命令。
3. AOF能保证最大的丢失数据量最1秒。
4. AOF 日志文件的命令通过非常可读的方式进行记录，这个特性非常**适合做灾难性的误删除的紧急恢复**。比如某人不小心用 `flushall` 命令清空了所有数据，只要这个时候后台 `rewrite` 还没有发生，那么就可以立即拷贝 AOF 文件，将最后一条 `flushall` 命令给删了，然后再将该 `AOF` 文件放回去，就可以通过恢复机制，自动恢复所有数据。
2. 缺点
1. AOF文件通常都会比较大，在数据恢复的时候时间会比较久。
RDB快照
使用
- 客户端可以通过向Redis发送BGSAVE命令来创建一个快照。对于支持BGSAVE命令的平台来说（基本所有的平台都只支持，除了windows平台），Redis会调用fork来创建一个子进程，然后子进程负责将快照写入磁盘，而父进程则继续处理命令请求。
- 客户端还可以通过向Redis发送SAVE命令来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前将不再响应任何其他命令。SAVE命令并不常用，我们通常只会在没有足够内存区执行BGSAVE命令的情况下，又或者即时等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令。
- 如果用户设置了save配置选项，比如
save 60 10000，那么从Redis最近一次创建快照之后开始算起，当“60秒之内有10000次写入”，这个条件被满足时，Redis就会自动触发BGSAVE命令。如果 用户设置了多个save配置选项，那么当任意一个save配置选项所设置的条件被满足时，Redis就会触发一次BGSAVE命令。 - 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有的客户端，不在执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器。
- 当一个Redis服务器连接另一个Redis服务器，并向对象发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令。
RDB优缺点
- RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说 Amazon 的 S3 云服务上去，在国内可以是阿里云的 ODPS 分布式存储上，以预定好的备份策略来定期备份redis中的数据。
- RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
- 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
- 如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。一般来说，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。
- RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
配置文件
备份配置
* save 1 900 // 在900秒内，有一条记录更新或者插入
* save 3 1000
*
* dbfilename dump.rdb // 默认文件名
*
* 默认备份文件名
* dump.rdb
* 默认备份文件位置
* 在客户端命令行中输入 config get dir 获取路径
如果需要关闭rdb备份就将配置文件的save ""即可