没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
21页
Redis持久化 RDB快照(snapshot) 在默认情况下, Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。 你可以对 Redis 进行设置, 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动保存一次 数据集。 比如说, 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时, 自动保存一次 数据集: # save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可 还可以手动执行命令生成RDB快照,进入redis客户端执行命令save或bgsave可以生成dump.rdb文件, 每次命令执行都会将所有redis内存快照到一个新的rdb文件里,并覆盖原有rdb快照文件。 bgsave的写时复制(COW)机制 Redis 借助操作系统提供的写时复制技术(Copy-On-Write, COW),在生成快照的同时,依然可以正常 处理写命令。简单来说,bgsave 子进程是由主线程 fork 生成的,可以共享主线程的所有内存数据。
资源推荐
资源详情
资源评论
Redis 持久化
RDB 快照(
snapshot)
在默认情况下, Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
你可以对 Redis 进行设置, 让它在“
N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动保存一次
数据集。
比如说, 以下设置会让 Redis 在满足“
60 秒内有至少有 1000 个键被改动”这一条件时, 自动保存一次
数据集:
# save 60 1000 //关闭 RDB 只需要将所有的 save 保存策略注释掉即可
还可以手动执行命令生成 RDB 快照,进入 redis 客户端执行命令 save 或 bgsave 可以生成
dump.rdb 文件,
每次命令执行都会将所有 redis 内存快照到一个新的 rdb 文件里,并覆盖原有 rdb 快照文件。
bgsave 的写时复制(COW)机制
Redis 借助操作系统提供的写时复制技术(
Copy-On-Write, COW),在生成快照的同时,依然可以正常
处理写命令。简单来说,bgsave 子进程是由主线程 fork 生成的,可以共享主线程的所有内存
数据。
bgsave 子进程运行后,开始读取主线程的内存数据,并把它们写入 RDB 文件。此时,如果主
线程对这些
数据也都是读操作,那么,主线程和 bgsave 子进程相互不影响。但是,如果主线程要修改一
块数据,那
么,这块数据就会被复制一份,生成该数据的副本。然后,bgsave 子进程会把这个副本数据写
入 RDB 文
件,而在这个过程中,主线程仍然可以直接修改原来的数据。
save 与 bgsave 对比:
命令
save
bgsave
IO 类型
同步
异步
是否阻塞 redis 其它命令
是
否(在生成子进程执行调用 fork 函
数时会有短暂阻塞)
复杂度
O(n)
O(n)
优点
不会消耗额外内存
不阻塞客户端命令
缺点
阻塞客户端命令
需要 fork 子进程,消耗内存
配置自动生成 rdb 文件后台使用的是 bgsave 方式。
AOF(
append-only file)
快照功能并不是非常耐久(
durable): 如果 Redis 因为某些原因而造成故障停机, 那么服务器将丢失
最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始, Redis 增加了一种完全耐久的
持久化方
式: AOF 持久化,将修改的每一条指令记录进文件 appendonly.aof 中(先写入 os cache,每
隔一段时间
fsync 到磁盘)
比如执行命令“
set zhuge 666”,aof 文件里会记录如下数据
1 *3
2 $3
3 set
4 $5
5 zhuge
6 $3
7 666
这是一种 resp 协议格式数据,星号后面的数字代表命令有多少个参数,$号后面的数字代表这
个参数有几
个字符
注意,如果执行带过期时间的 set 命令,aof 文件里记录的是并不是执行的原始命令,而是记录
key 过期的
时间戳
比如执行“
set tuling 888 ex 1000”,对应 aof 文件里记录如下
1 *3
2 $3
3 set
4 $6
5 tuling
6 $3
7 888
8 *3
9 $9
10 PEXPIREAT
11 $6
12 tuling
13 $13
14 1604249786301
你可以通过修改配置文件来打开 AOF 功能:
1 # appendonly yes
从现在开始, 每当 Redis 执行一个改变数据集的命令时(比如 SET), 这个命令就会被追加
到 AOF 文
件的末尾。
这样的话, 当 Redis 重新启动时, 程序就可以通过重新执行 AOF 文件中的命令来达到重建
数据集的目
的。
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。
有三个选项:
1 appendfsync always:每次有新命令追加到 AOF 文件时就执行一次 fsync ,非常慢,也非常安全。
2 appendfsync everysec:每秒 fsync 一次,足够快,并且在故障时只会丢失 1 秒钟的数据。
3 appendfsync no:从不 fsync ,将数据交给操作系统来处理。更快,也更不安全的选择。
推荐(并且也是默认)的措施为每秒 fsync 一次, 这种 fsync 策略可以兼顾速度和安全性。
AOF 重写
AOF 文件里可能有太多没用指令,所以 AOF 会定期根据内存的最新数据生成 aof 文件
例如,执行了如下几条命令:
1 127.0.0.1:6379> incr readcount
2 (integer) 1
3 127.0.0.1:6379> incr readcount
4 (integer) 2
5 127.0.0.1:6379> incr readcount
6 (integer) 3
7 127.0.0.1:6379> incr readcount
8 (integer) 4
9 127.0.0.1:6379> incr readcount
10 (integer) 5
重写后 AOF 文件里变成
剩余20页未读,继续阅读
资源评论
灰飞烟灭2016
- 粉丝: 0
- 资源: 6
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功