文章目录
一、RDB
1.1 概念
根据指定的时间间隔，将内存中的数据集快照（Snapshot 快照）写入磁盘，恢复时将快照文件直接读到内存中。
1.2 原理
1、Redis 会单独创建一个 fork 子进程来进行持久化
2、子进程先将数据写入到一个临时文件中
3、持久化过程结束后用这个临时文件替换上次的 RDB 文件。
1.3 启动方式
1.3.1 手动触发——save 指令
1、命令
save
2、说明
手动执行一次保存操作，并且是立即执行，但会阻塞当前 Redis 服务器，知道当前 RDB 过程完毕为止，有可能会造成长时间的阻塞，线上环境不建议使用。
1.3.2 手动触发——bgsave 指令
1、命令
bgsave
2、说明
手动执行一次保存操作，但不是立即执行，而是在后台进行保存操作。bgsave 是对 save 阻塞问题做的优化，Redis 内部所有涉及到 RDB 的操作都采用 bgsave 的方式，save 指令可以放弃使用。
1.3.3 自动触发——save 配置
- 配置
save second changes
second：监控的时间范围
changes：监控 key 的变化次数
- 说明
在 second 秒内 key 的修改次数达到 changes，则自动触发 bgsave。
- 配置范例
save 900 1
save 300 10
save 60 10000
1.3.4 RDB 特殊的启动方式
- 没有开启 AOF 持久化功能情况下执行 shutdown 命令，自动执行 bgsave
shutdown
- 关闭服务器时指定保存数据
shutdown save
- 服务器运行过程中重启
debug reload
- 主从复制中执行复制 replication 初始化之前自动保存快照
1.4 相关配置
- defilename dump.rdb
- 说明：设置 RDB 快照的文件名，默认为 dump.rdb
- 经验：通常设置为 dump-端口号.rdb
- dir ./
- 说明：设置 RDB 文件的保存路径，默认为 Redis 启动命令所在的目录
- 经验：通常设置成目录空间较大的目录中，目录名称 data
- rdbcompression yes
- 说明：保存 RDB 快照时，是否启用压缩
- 经验：默认开启，若设置为 no 可节省 CPU 资源，但 RDB 文件会很大
- rdbchecksum yes
- 说明：在读写 RDB 文件的过程中是否对其进行校验
- 经验：默认开启，若设置为 no 可节省约 10％ 的性能，但 RDB 文件存在损坏风险
- stop-wirtes-on-bgsave-error yes
- 说明：使用 bgsave 指令进行后台保存并出现错误导致无法写入磁盘时，是否停止保存操作
- 经验：通常默认为开启状态
- save second changes
- 在 second 秒内 key 的修改次数达到 changes，则自动触发 bgsave
1.5 save 和 bgsave 对比
| 方式 | save | bgsave |
|---|---|---|
| 同/异步 | 同步 | 异步 |
| 是否阻塞客户端指令 | 是 | 否 |
| 是否额外消耗内存 | 否 | 是 |
| 是否启动新进程 | 否 | 是 |
1.6 RDB的优缺点
- 优点
- RDB 是二进制文件，磁盘占用空间小，适合数据备份和全量复制；
- RDB 恢复数据的速度比 AOF 快很多。
- 缺点
- 无法实时持久化，如果最后一次持久化后宕机，还是会损失一些数据的；
- 当数据量过去庞大时，还是会损失一些性能的；
- Redis 的众多版本中，未对 RDB 文件格式进行统一，不同版本的数据之间可能会出现无法兼容的现像。
二、AOF
2.1 概念
- 以独立日志的方式记录每次的写命令，将 redis 执行过的所有写指令（读操作不记录）追加到文件的末尾。redis 重启后会重新执行 AOF 文件中的指令来达到恢复数据的目的。
主要是解决了数据持久化的实时性
2.2 原理
1、命令写入：所有的写命令都会追加到缓冲区中(aof_buf)
2、文件同步：AOF 缓冲区根据策略写入磁盘
3、文件重写：AOF 文件超过一定大小后，会对AOF文件进行重写
4、重启加载：Redis 服务重启，加载 AOF 文件进行数据恢复（优先 AOF）
2.3 三种策略
- appendfsync always
- 始终同步，每次 Redis 的写入命令都会立刻同步到 AOF 文件中；
- 数据零误差，性能较低；
- appendfsync everysec
- 每秒同步，每秒将缓冲区的指令同步到 AOF 文件中；
- 数据准确性较高，性能较高；
- appendfsync no
- 不自动同步，由操作系统控制指令同步到 AOF 文件的时机；
- 整体过程不可控
2.4 相关配置
- appendonly yes|no
- 说明：是否开启 AOF 持久化功能，默认为不开启状态
- 经验：；一般都设置为开启
- appendfsync always|everyone|no
- 说明：AOF 写入策略
- 经验：建议使用 everyone，在数据准确性和性能之间比较均衡
- appendfilename
- 说明：设定 AOF 文件的文件名，默认为 appendonly.aof
- 经验：建议文件名配置为 appendonly-端口号.aof
- dir ./
- 说明：AOF 文件的保存路径，默认为 Redis 启动命令所在的目录
2.5 AOF 重写
随着命令被不断写入 AOF 文件，文件会越来越大，为了解决这个问题，redis 引入了重写机制来压缩 AOF 文件体积。
2.5.1 概念
- AOF 文件重写是将 Redis 进程中的数据转化为写命令同步到新 AOF 文件的过程。
- 或者说：只保留可以恢复数据的最小指令集。
2.5.2 作用
- 缩小文件体积
- 加快数据恢复速度
- 提高持久化效率，降低持久化写时间，提高 IO 性能
2.5.3 重写规则
- 进程内已经超时的数不再写入文件
- 重写时使用进程内的数据直接生成写入命令
- 对同一数据的多条写命令合并为一条命令
2.5.4 重写方式
方式一：手动重写
bgrewriteaof
方式二：自动重写
- 自动重写的触发条件设置
# 要在配置文件中配置
auto-aof-rewrite-min-size size # 文件大小
auto-aof-rewrite-percentage percentage # 文件大小比例
- 自动重写触发条件
aof_base_size：系统载入或上次重写完毕时，redis 会记录此时 AOF 文件的大小，设为 aof_base_size
aof_current_size：AOF 文件当前大小（运行指令 info Persistence 获取具体信息）
# 1、aof文件当前大小 >= aof基础大小*(1+100％) （默认为100％）
aof_current_size >= aof_base_size + aof_base_size*percentage
# 2、aof文件当前大小 >= 64mb （默认为64mb）
aof_current_size >= size
三、RDB 和 AOF 的区别
3.1 RDB VS AOF
| 持久化方式 | RDB | AOF |
|---|---|---|
| 占用空间 | 小（数据级：压缩） | 大（指令级：重写） |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢失数据 | 依据策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |
3.2 RDB 与 AOF 的选择
1、对数据很敏感，建议使用 AOF
- AOF 策略使用 everysecond，每秒钟 fsync 一次。该策略可以很好的权衡性能和安全，最多丢失 1 秒的数据；
- AOF 文件较大，恢复起来较慢。
2、数据呈现阶段有效性，建议使用 RDB
- 可以做到阶段内无丢失，且恢复速度较快；
- 若使用 RDB 的频率高，会严重影响 redis 的性能。
3、综合对比
- 对数据敏感，能忍受最多几秒内数据的丢失，选择 AOF；
- 追求数据恢复的速度，且能忍受数分钟内的数据丢失，选择 RDB；
- 灾备，选择 RDB；
- 双保险策略，同时开启 RDB 和 AOF。redis 重启后，优先使用 AOF 恢复数据。
扫一扫
1731
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
