玩转redis持久化,阿里架构师给你来一篇方案介绍-创新互联

玩转redis持久化,阿里架构师给你来一篇方案介绍

创新互联坚持“要么做到,要么别承诺”的工作理念,服务领域包括:网站建设、做网站、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的襄汾网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!

一、基本介绍

本次演示使用的redis版本是3.2.100,操作系统是win10。

redis支持两种持久化方案,RDB和AOF,前者是默认打开的,后者需要手动开启。我们通过配置文件可以验证这一点,

RDB默认开启

save 900 1
save 300 10
save 60 10000

这三条配置是RDS触发快照的条件,它们的意思分别是:

  1. 900秒内如果有一条写入,则产生快照
  2. 300秒内如果有1000次写入,则产生快照
  3. 60秒内如果有10000次写入,则产生快照

当然,触发rdb快照的条件不止这些,下面会讲到。

AOF默认关闭

appendonly no

二、RDB介绍

RDB的方案是当满足触发条件是,将内存中的数据以二进制的方式写入磁盘保存,默认保存的文件叫dump.rdb(可以改),当redis重启时,会读取该文件进行数据恢复。

查看快照文件的信息

127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"
127.0.0.1:6379> config get dir
1) "dir"
2) "C:\\redis-6379"
127.0.0.1:6379>

触发RDB快照条件

除了上面提到的在指定时间内,指定写次数触发之外,下面几种情况也会触发redis执行RDB快照,

  1. 手动执行save(同步阻塞)或者bgsave(异步阻塞)命令
  2. 执行flushall命令
  3. redis退出,执行shutdown命令

下面拿第一种情况演示下,这里会用到info Persistence命令,用来查看持久化信息。

127.0.0.1:6379> info persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1561595205
...省略其它
127.0.0.1:6379> save
OK
127.0.0.1:6379> info persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1561595940
...省略其它
127.0.0.1:6379>

注意看rdb_last_save_time字段,说明save命令触发了持久化。

三、AOF介绍

为了演示AOF,我们需要手动把AOF开关打开,然后重启redis。

AOF将Redis执行的每一条写命令追加到磁盘文件(appendonly.aof)中,如果打开了AOF,redis启动时候优先选择从AOF文件恢复数据。

相关配置

除了开关,和AOF相关的配置还有以下几个:

appendfilename "appendonly.aof"   #数据库文件名
# appendfsync always    #每个命令都追加写入
appendfsync everysec    #每秒写1次
# appendfsync no        #写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof

no-appendfsync-on-rewrite  yes:   #正在导出rdb快照的过程中,是否停止同步aof
auto-aof-rewrite-percentage 100   #aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb    #aof文件,至少超过64M时,才重写

重写机制

通过前面讲述的AOF的过程,聪明的你可能会想到一个问题,AOF不断的追加命令到文件,那文件岂不是越来越大,时间长了对磁盘空间也是负担啊。

你都想到了,redis的作者会想不到吗?redis引入了重写机制来解决这个问题。上面配置的最后两条其实就是重写的触发条件,说白了意思就是:

当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

除了上面的条件触发,AOF也支持手动触发(bgrewriteaof命令)下面用这个命令演示重写

λ redis-cli.exe
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
127.0.0.1:6379>

启动日志:

[18268] 27 Jun 09:23:41.282 # Server started, Redis version 3.2.100
[18268] 27 Jun 09:23:41.282 * The server is now ready to accept connections on port 6379
[18268] 27 Jun 09:24:03.236 * Background append only file rewriting started by pid 18740
[18268] 27 Jun 09:24:03.388 * AOF rewrite child asks to stop sending diffs.
[18268] 27 Jun 09:24:03.488 # fork operation complete
[18268] 27 Jun 09:24:03.489 * Background AOF rewrite terminated with success
[18268] 27 Jun 09:24:03.491 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
[18268] 27 Jun 09:24:03.496 * Background AOF rewrite finished successfully

四、总结

  1. 如果使用持久化,建议RDB和AOF都开启,双重保障。AOF会优先执行,如果执行失败还有RDB
  2. RDB适合大规模数据恢复,但是完整性不如AOF,因为RDB可能在最后一次备份时宕机了
  3. RDB相对AOF比较占用内存

写在最后

玩转redis持久化,阿里架构师给你来一篇方案介绍

创新互联www.cdcxhl.cn,专业提供香港、美国云服务器,动态BGP最优骨干路由自动选择,持续稳定高效的网络助力业务部署。公司持有工信部办法的idc、isp许可证, 机房独有T级流量清洗系统配攻击溯源,准确进行流量调度,确保服务器高可用性。佳节活动现已开启,新人活动云服务器买多久送多久。


分享文章:玩转redis持久化,阿里架构师给你来一篇方案介绍-创新互联
分享地址:http://scyanting.com/article/ddhdpe.html