redis(三)redis持久化
持久化方式
redis主要工作在内存中。内存本省就不是一个持久化的设备，断电后数据会清空。但是redis提供了持久化方式。个人看来 这是redis提供了一种备份机制，可以将内存中的数据持久化到磁盘上，有利于这些热点数据的备份恢复和迁移。
redis提供了两种持久化方式，分别是RDB 和AOF
RDB持久化方式能够在指定的时间间隔对数据进行快照存储
AOF持久化方式记录每次对服务器的写操作，当服务器重启的时候会重新执行这些命令来恢复原始数据，个人认为类似于MySQL的binlog日志
RDB
RDB：在指定的时间间隔内将内存中的数据写入磁盘，它恢复时是将文件读取到内存中。
RDB是默认开启的
RDB工作机制
工作机制：每隔一段时间，就会把内存中的数据保存到硬盘上的指定文件中。
RDB在持久化时会单独创建一个fork子进程来进行持久化操作，会先将数据写入到一个临时文件中，等到持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程work是不会进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模的数据恢复，RDB性能比AOF好很多。
保存策略
save 900 1 900 秒（15分钟）内如果至少有 1 个 key 的值变化，则保存
save 300 10 300 秒（5分钟）内如果至少有 10 个 key 的值变化，则保存
save 60 10000 60 秒（1分钟）内如果至少有 10000 个 key 的值变化，则保存
save "" 是禁用RDB模式
RDB属性设置
| 属性 | 含义 | 默认 |
|---|---|---|
| save | 保存策略 | 默认开启三个 也就是15分钟1个key则保存 |
| dbfilename | RDB 快照文件名 | dump.rdb |
| dir | RDB 快照保存的目录 | 必须是一个目录，不能是文件名。最好改为固定目录。默 认为./代表执行 redis-server 命令时的当前目录！ |
| stop-writes-on-bgsave-error | 是否在备份出错时，继续接受写 操作 | 如果用户开启了 RDB 快照功能，那么在 redis 持久化数据 到磁盘时如果出现失败，默认情况下，redis 会停止接受所 有的写请求 |
| rdbcompression | 对于存储到磁盘中的快照，可以 设置是否进行压缩存储。 | 如果是的话，redis 会采用 LZF 算法进行压缩。如果你 不想消耗 CPU 来进行压缩的话， 可以设置为关闭此功能，但是存储在磁盘上的快照会 比较大。 |
| rdbchecksum | 是否进行数据校验 | 在存储快照后，我们还可以让 redis 使用 CRC64 算法 来进行数据校验，但是这样做会增加大约 10%的性能消耗， 如果希望获取到最大的性能提升，可以关闭此功能。 |
触发持久化的方式
1、基于自动保存策略
2、执行save，或者bgsave命令，执行时save时是阻塞状态
3、执行 shutdown 命令时，也会主动地备份数据。
4、执行 flushdb 命令，也会产生 dump.rdb，但里面是空的，没有意义
优缺点
优点
1、RDB是一个文件，保存了某个时间点的数据集，非常适合用于数据集的备份。
2、压缩格式 恢复速度快
缺点
1、（可能有 但是我没找到）没有设置固定大小的策略，随着业务量的增加 只能任由rdb文件增大
2、不是实时的，可能会丢数据，操作比较重。
3、fork时内存中的数据被克隆了一份，大概2倍的膨胀。
备份脚本
每小时备份一次rdb文件
crontab -e
0 */1 * * * cp /etc/redis/dump.rdb /etc/redis/dump.rdb`date +%Y%m%d%H`
AOF
1、AOF是以日志的形式来记录每个写操作，将每一次对数据进行修改，都会把新建、修改数据的命令保存到指定文件中。redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
2、默认不开启，需要手动启动
3、AOF 在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！
4、当 RDB 和 AOF 存的不一致的情况下，按照 AOF 来恢复。因为 AOF 是对 RDB 的补充。备份周期更短，也就更可靠。
保存策略
appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！
appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即 1 秒钟的数据）。
appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
AOF属性设置
| 属性 | 含义 | 默认 |
|---|---|---|
| appendonly | 是否开启 AOF 功能 | 默认是关闭的 |
| appendfilename | AOF 文件名称 | |
| appendfsync | AOF 保存策略 | 官方建议 everysec |
| no-appendfsync-on-rewrite | 在重写时，是否执行保存策略 | 执行重写，可以节省 AOF 文件的体积；而且在恢复的时候 效率也更高。 |
| auto-aof-rewrite-percentage | 重写的触发条件 | 当目前 aof 文件大小超过上一次重写的 aof 文件大小的百分 之多少进行重写 |
| auto-aof-rewrite-min-size | 设置允许重写的最小 aof 文件 大小 | 避免了达到约定百分比但尺寸仍然很小的情况还要重写 |
| aof-load-truncated | 截断设置 | 如果选择的是 yes，当截断的 aof 文件被导入的时候，会自 动发布一个 log 给客户端然后 load |
AOF文件的修复
如果 AOF 文件中出现了残余命令，会导致服务器无法重启。此时需要借助 redis-check-aof 工具来修复！
命令： redis-check-aof –fix 文件
AOF的rewrite机制
AOF采用文件追加方式，文件会越来越大，为了避免出现这种情况，新增加了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof
重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重新（也就是先写临时文件最后rename），遍历新进程的内存中数据，每条记录有一条set语句。重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这点和RDB快照相似。
触发机制
redis会记录上次重写时AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大小大于64M时触发。
优缺点
优
1、备份机制更稳健，丢数据概率更低
2、可读的日志文本，通过操作AOF文件，可以处理误操作。
缺
1、比起RDB占用更多的磁盘空间
2、恢复备份速度要慢
3、每次读写都同步的话，有一定的性能压力
两种备份方式的有优先级
如果同时开启两种持久化方式：
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不是实时的，同时使用两者时服务器重启也只会找AOF文件。那要不要只用AOF呢？
也不建议，因为RDB更适合备份数据库，进行快速重启。
应用场景
一、服务器卡死或者redis卡死
如果数据不是很重要 建议直接使用RDB恢复。
恢复步骤：
1、移动AOF文件（因为默认是从AOF文件reload）
2、检查RDB文件 进行redis restart 重新reload RDB文件
二、人为误删除部分数据
数据不重要：删除了就删除吧
数据重要：AOF恢复
三、人为误删除全部数据
数据不重要：使用crontab 定时备份任务 备份的RDB文件进行恢复
数据重要：使用AOF的方式，vim appendonly.aof文件，将flushall命令删除后进行重启redis
四、误删除AOF文件
误删除了 就是没了。只能从现在再开始记录。
五、误删除RDB文件
save \bgsave触发条件会再次自动生成dump.rdb 是无所谓的
