为了账号安全,请及时绑定邮箱和手机立即绑定

《Redis系列专题》之 Redis的持久性

作者: 常明,Java架构师
[请尊重原创,盗版必究,转载请指明出处]


q
Redis和Memcached都是基于内存的key-value存储系统,但Redis有很多独特特性受到更加青睐。

Redis和Memcached的显著不同除了Redis支持更多数据类型外,Redis数据支持持久化也是很重要的一个方面。这也是在很多应用场合选择Redis的一个重要原因。

Redis数据持久化有两种模式,分别是RDB和AOF。这两种模式可以分别独立存在,也可以同时使用。当然,开启Redis数据持久化功能毕竟会消耗资源影响到性能,故在不必要开启时尽量不要开启,以保证Redis最高效地运行。
q1
RDB模式即是在给定时间点将Redis数据库快照保存为一个.rdb文件。当Redis重启时会根据这个快照文件重新加载数据。

其实,这个快照文件就相当于Redis的一次数据备份。如有必要,可以制定数据备份策略,进行数据月备份、周备份、日备份甚至是小时备份,必要时进行灾难恢复。

我们知道,Redis是单线程处理客户请求操作的。当Redis启动RDB数据快照备份时,主线程会fork出一个子线程专门处理持久化操作,最大限度地减少对Redis性能的影响。

当然,由于是定点数据快照备份,Redis数据恢复时可能会有一定的数据损失。

客户端可以执行BGSAVESAVE命令启动快照备份。SAVE命令与BGSAVE命令的区别是SAVE命令执行时Redis会停止其它响应服务,在服务正常shutdown时也会启动。

BGSAVE操作也可以通过在redis.conf文件中配置相关操作来触发:

save 参数,设置定点保存快照数据规则,如:

save 900 1 900秒后至少有1个键发生改变
save 300 10 300秒后至少有10个键发生改变

可以有多条save规则同时起作用,当最后有save "" 语句时表示禁用RDB模式。

RDB模式其它的相关配置参数包括:

stop-writes-on-bgsave-error yes 如果快照文件存硬盘发生错误,是否停止写操作。一般用yes,明确告知前端数据备份出错了。

rdbcompression yes rdb备份文件是否采用压缩模式, 一般yes。

rdbchecksum yes rdb文件是否启用CRC64文件数据完整性检查,一般yes。

dbfilename dump.rdb rdb文件名

dir ./ rdb文件目录,,也适用于AOF模式,即aof文件的目录。
q2
AOF模式是将每一写操作命令写入文件,在数据恢复时,AOF模式会尽最大可能减少数据损失。因此如果两个模式都开启,Redis重启时会优先根据aof文件进行数据恢复。

但aof文件通常会比rdb文件要大很多,加载时间也更长。不过Redis会自动启动rewrite重写aof文件,仅保留有效写操作,这样会减少文件大小。

AOF模式相关的配置参数有:

appendonly no 是否开启AOF持久化模式

appendfilename "appendonly.aof" aof文件名

appendfsync everysec Redis 执行数据从缓冲区写入硬盘的策略,可以有三个选项,everysec 是缺省推荐,每秒执行一次。no 表示由操作系统自己决定。always 是每次写操作,该选项会影响性能但能最大保证写操作命令写入aof文件。

no-appendfsync-on-rewrite no 在Redis执行save或rewrite后台I/O操作时,同样执行appendfsync写入硬盘策略。当对性能产生较大影响时,可设置为yes,不执行appendfsync策略。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

上两句表示BGREWRITEAOF后台进程rewrite启动策略,这两项表示aof文件至少64mb,且aof文件大小增长了100%

aof-load-truncated yes Redis启动加载aof文件,如果发现末尾命令不完整则自动截掉,成功加载前面正确的数据。如果设置为no,遇到此类情况,Redis启动失败,用redis-check-aof 工具手工修复。
q3
无论RDB还是AOF,都会对Redis的高性能运行或多或少产生影响。为了最大化提高Redis运行效率,无持久化必要的情况下尽量不开启持久化功能。如开启,可以利用Redis复制功能将持久化功能转移到从库上。

Redis复制,本身是用来解决大规模应用场景下,Redis的服务响应能力。由于其存在多个数据源,数据丢失风险大为降低。同时,持久化功能可以分布式部署不占用主计算资源。当然,这种配置下主库慎用restart功能,防止从库自动复制刷新掉持久化数据。

Redis复制功能支持主从复制,一个主库可以挂多个从库,支持读写分离。同时从库可以再挂从库形成级联复制。

对于2.8版本以上的Redis,Redis会支持增量复制。第一次连接时,执行完全同步操作。主库收到命令后,和收到sync一样,会启动bgsave保存rdb文件,传输rdb文件到从库进行加载,完成复制。同时,在此过程中,主库会把后续的写操作存入backlog缓存区,这样不影响rdb复制过程中,主库继续对外工作。从库加载rdb完成,随即主库传输backlog写命令完成同步。此后,主库将以Redis自定义的私有协议继续传输写命令保持同步。

如各种原因与主库连接中断,从库发出psync命令看是否可以增量复制,从库将保存主库的run id和replication offset发送给主库,主库核实run id,且复制偏移量的数据在backlog中仍存在,则进行增量复制。否则,重新进行全量复制。

主从复制配置比较简单,主库相关参数:
repl-backlog-size 1mb 将写命令存入backlog缓存区,为以后从库与主库重新联接后,执行增量复制。

从库相关参数:

slaveof <主库IP> <主库端口号> 连接主库,会向主库发出sync同步命令。

slave-serve-stale-data yes 从库和主库失联或数据复制正在进行中,如该变量是yes,则从库仍用老版本数据提供服务,如为no,则拒绝服务,返回"SYNC with master in progress" 错误。

slave-read-only yes 只读模式
qq


本文出自慕课网,转载请注明出处,侵权必究。
点击查看更多内容
11人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
JAVA开发工程师
手记
粉丝
455
获赞与收藏
3117

关注作者,订阅最新文章

阅读免费教程

感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消