## 一、持久化的作用
* 什么是持久化
* redis所有数据保存在内存中，对数据的更新将异步地保存到磁盘上。
* 持久化方式
* 快照 - 某事某点数据的完整备份
* MySQL Dump
* Redis RDB
* 写日志 - 只要有操作就记录到日志中
* MySQL Binlog
* Hbase HLog
* Redis AOF
## 二、RDB
* 什么是RDB
* 通过一条命令将redis内存中的数据完整生成一个快照保存到硬盘当中，也就是RDB文件（二进制），进行持久化。
* 对redis进行重启，可以加载 RDB文件，进行恢复。
* 触发机制-主要三种方式
* save 同步
* 向redis发送一个save命令，创建RDB文件，会造成redis阻塞。
* 文件策略：如存在老的RDB文件，新替换老。
* 负责度：O（N）
* bgsave 异步
* 在redis主进程生产fork() 子进程，创建RDB文件
* 如果fork 慢，会阻塞主进程。非常快的情况不会阻塞主进程。
* 自动
* 默认配置
| 配置 | seconds | changes |
| --- | --- | --- |
| save | 900 | 1 |
| save | 300 | 10 |
| save | 60 | 10000 |
当900秒内有1条修改则执行save，当300秒内有10条修改则执行save，当60秒内有10000条修改则执行save
| 配置 | 参数 | 说明 |
| --- | --- | --- |
| dbfilename | dump.rdb | 生产的文件名 |
| dir | ./ | 保存的文件路径 |
| stop-writes-on-bgsave-error | yes | 发生错误是否停止写入 |
| rdbcompression | yes | 是否采用压缩格式 |
| rdbchecksum | yes | 是否进行检验 |
* 推荐配置
| 配置 | 参数 |
| --- | --- |
| dbfilename | dump-${port}.rdb |
| dir | /bigdiskpath |
| stop-writes-on-bgsave-error | yes |
| rdbcompression | yes |
| rdbchecksum | yes |
* save 与 bgsave 的不同
| 命令 | save | bgsave |
| --- | --- | --- |
| IO类型 | 同步 | 异步 |
| 阻塞？ | 是 | 是（阻塞发生在fork） |
| 复杂度 | O(n) | O(n) |
| 优点 | 不会消耗额外内存 | 不阻塞客户端命令 |
| 缺点 | 阻塞客户端命令 | 需要fork，消耗内存 |
* 触发机制-不容忽视方式
* 全量复制，即主从复制
* debug reload，发生错误时需建立RDB
* shutdown，重启时建立RDB
* 总结
* RDB是Redis内存到硬盘的快照，用于持久化。
* save通常会阻塞Redis。
* bgsave不会阻塞Redis，但是会fork新进程。
* save自动配置满足任一条件就会被执行。
* 有些触发机制不容忽视
## 三、AOF
* RDB有什么问题
* 耗时、耗性能
* 需要把所有数据dumo到磁盘中，耗时O(n)的过程
* fork() : 消耗内存，copy-on-writh策略
* Disk I/O : IO性能消耗
* 不可控、丢失数据
| 时间戳 | save |
| --- | --- |
| T1 | 执行多个写命令 |
| T2 | 满足RDB自动创建的条件 |
| T3 | 再次执行多个写命令 |
| T4 | 宕机 |
当T1时间点执行了很多写命令，在T2时间点满足RDB自动创建的条件，T3时间点又执行了很多写命令，T4时间点宕机了，T3-T4时间段的写入命令会丢失。
* AOF运行原理
* 创建 -- 以写日志的方式把每一条写命令追加到AOF文件当中
* redis在执行写命令时，会写到硬盘的缓冲区当中，缓冲区会根据一些**策略**把写命令的日志刷新到磁盘当中
* 恢复 -- 当发生宕机时，重启之后将AOF文件载入到Redis当中，进行数据恢复。
* AOF的三种策略
* always
* 写每条命令都会fsync到磁盘
* everysec
* 每秒把缓冲区 fsync 到磁盘，出现故障有可能会丢失一秒的数据
* no
* 根据操作系统决定，操作系统说什么时候 刷，就什么时候刷。
| 命令 | always | everysec | no |
| --- | --- | --- | --- |
| 优点 | 不丢失数据 | 每秒一次 fsync 丢1秒数据 | 不用管 |
| 缺点 | IO开销较大，一般的 sata 盘只有几百 TPS | 丢1秒数据 | 不可控 |
* AOF重写
* 把过期的、没有用的、重复的以及可以优化的命令进行化简，化简为一个很小的AOF文件。
* 减少硬盘占用量
* 加速恢复速度
* AOF重写实现的两种方式
* bgrewriteaof
* 由客户端发送 bgrewriteaof 命令到服务端，redis接收到命令后会 fork 出一个子进程，来完成AOF重写。
* AOF重写配置---实现自动重写
| 配置名 | 含义 |
| --- | --- |
| auto-aof-rewrite-min-size | AOF文件重写需要的尺寸 |
| auto-aof-rewrite-percentage | AOF 文件增长率 |
| 统计名 | 含义 |
| --- | --- |
| aof_current_size | AOF当前尺寸（单位：字节） |
| aof_base_size | AOF上次启动和重写的尺寸（单位：字节） |
* 自动触发时机
* 当前尺寸 > 最小尺寸
* （当前尺寸 - 最小尺寸） / 最小尺寸 > 增长率
* 配置
| 命令 | 配置 | 说明 |
| --- | --- | --- |
| appendonly | yes | 开打AOF功能 |
| appendfilename | appendonly-${port}.aof | AOF生产的文件名 |
| appendfsync | everysec | 同步的策略 |
| dir | /bigdiskpath | 保存的目录 |
| no-appendfsync-on-rewrite | yes | 是否在重写的时候，关闭 AOF 的 appen操作，如果不关闭有可能会导致数据丢失，这里是 yes ，重写时不做其他操作 |
| auto-aof-rewrite-percentage | 100 | 增长率 |
| auto-aof-rewrite-min-size | 64mb | 最小尺寸 |
* RDB和AOF抉择
| 命令 | RDB | AOF |
| --- | --- | --- |
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 丢数据 | 根据策略决定 |
| 操作的轻重 | 重，因为它要操作全部的redis数据 | 轻，日志追加的方式 |
* RDB最佳策略
* “关”- 在主从会用到
* 集中管理 - 如果需要按天按小时备份数据，是个不错的选择。
* 主从，从开？
* AOF最佳策略
* “开”：缓存和存储 -- 如果只当缓存可以关掉
* AOF重写集中管理
* everysec
* 最佳策略
* 小分片 -
* 缓存或者存储 - 根据缓存或存储的特性决定使用那种策略
* 监控（硬盘、内存、负载、网络）
* 足够的内存
