Redis持久化
持久化就是将 Redis 的所有数据保存在内存中，对数据的更新将异步保存到硬盘上
持久化的实现方式：
- 快照：在某时某刻对数据进行一次完整备份
- RDB
- 写日志：记录所有的操作日志，要恢复数据，只要把日志重新走一遍就可以了
- AOF
一、RDB
RDB 就是在 Redis 触发备份的时候，创建 RDB 文件并且把内存中的数据保存到文件中，在重新启动的时候又从 RDB 文件中载入数据
RDB 问题：
耗时，耗性能。
不可控，可能会丢失数据。
注：每一次备份的时候都是全量复制，并不是增量复制。
触发机制
RDB 的触发机制主要有三种方式
方式一：save（同步）
1 客户端执行save命令----》redis服务端----》同步创建RDB二进制文件
2 会造成redis的阻塞（数据量非常大的时候）
3 文件策略：如果老的RDB存在，会替换老的
4 复杂度 o(n)
方式二：bgsave（异步）
1 客户端执行save命令----》redis服务端----》异步创建RDB二进制文件（fork函数生成一个子进程（fork会阻塞reids），执行createRDB，执行成功，返回给reids消息）
2 此时访问redis，会正常响应客户端
3 文件策略：跟save相同，如果老的RDB存在，会替换老的
4 复杂度 o(n)
方式三：自动（通过配置）
save 900 1 # 如果900s中改变了1条数据，自动生成rdb
save 300 10 # 如果300s中改变了10条数据，自动生成rdb
save 60 10000 # 如果60s中改变了1w条数据，自动生成rdb
dbfilename dump-${port}.rdb # 以端口号作为文件名，可能一台机器上很多reids，不会乱
dir /bigdiskpath # 保存路径放到一个大硬盘位置目录
stop-writes-on-bgsave-error yes # 如果bgsave出现错误，是否停止写入，默认为yes
rdbcompression yes # 采用压缩格式
rdbchecksum yes # 是否对RDB文件进行校验和检验
二、AOF
AOF 就是客户端每写入一条命令，都记录一条日志，放到日志文件中，如果出现宕机，就可以将数据完全恢复。
AOF的三种策略
首先 AOF 日志不是直接写在硬盘上，而是先放在缓冲区，缓冲器根据策略在写到硬盘上
always
Redis——>写命令刷新到缓冲区——>每条命令同步到硬盘——>写入AOF文件
everysec（默认）
Redis——>写命令刷新到缓冲区——>每秒把缓冲区的同步到硬盘——>写入AOF文件
no
Redis——>写命令刷新到缓冲区——>操作系统决定，缓冲区同步到硬盘——>写入AOF文件
| 命令 | always | everysec | no |
|---|---|---|---|
| 优点 | 不丢失数据 | 每秒一次fsync，丢失1秒数据 | 不用管 |
| 缺点 | IO开销大，一般的sata盘只有几百TPS | 丢1秒数据 | 不可控 |
AOF重写
当命令的持续写入，并发量的变大，AOF文件会越来越大，通过AOF重写可以解决该问题
AOF 重写的本质就是把过期的，无用的，重复的，可以优化的命令，都做优化。这样可以减少磁盘占用量，加速恢复速度
使用方法：
在客户端主动输入：bgrewriteaof
客户端向服务端发送 bgrewriteaof 命令，服务端会起一个 fork 进程，完成AOF重写
AOF持久化配置
最优方案：
appendonly yes # 将该选项设置为yes，打开AOF
appendfilename "appendonly-${port}.aof" # 文件保存的名字
appendfsync everysec # 采用第二种策略
dir /bigdiskpath # 存放的路径
no-appendfsync-on-rewrite yes # 开启 AOF 重写，在AOF重写的时候，是否要做AOF的append操作，因为AOF重写消耗性能，磁盘消耗，正常AOF写磁盘有一定的冲突，这段期间的数据，允许丢失
版权声明：本文为XiaoYang-sir原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。