玩转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比较占用内存

写在最后

原文地址:https://blog.51cto.com/14409778/2414547

时间: 2024-08-04 01:24:55

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

万丈高楼平地起:阿里架构师带你吃透不一样的Redis核心原理实战

前言 随着互联网科技的不断发展,我们以前单纯直接操作数据库的方式已经不能满足现有的高性能和高并发的需求了,于是缓存技术应用而生. Redis是互联网技术领域使用最为广泛的存储中间件,它是「Remote DictionaryService」的首字母缩写,也就是「远程字典服务」.Redis 以其超高的性能.完美的文档.简洁易懂的源码和丰富的客户端库支持在开源中间件领域广受好评.国内外很多大型互联网公司都在使用 Redis,比如 Twitter.YouPorn.暴雪娱乐.Github.StackOve

月薪80k阿里架构师漫谈他是如何从一名小码农走到今天这一步。

01 刚当程序员时,我是属于那种勤勤恳恳类型的员工,工作态度用认真来形容不为过,每天我几乎是团队里最早到公司,又最晚下班的一个.而组员张工一般情况下都是准时上下班的,即使项目进度比较紧急,他也很少加班,除非是有特殊情况,他才加班. 要是按勤奋程度和工作时间长短来衡量,我想我比张工积极多了.按理说,我这么积极,工作量应该比张工多才对,其实不然,领导安排给我的工作任务和张工的任务相比,我比他还要少. 张工之前是做java服务端的,后来自学了Android移动开发,再后来又自学了iOS移动开发,那时他

阿里架构师告诉你最新Java架构师学习路线图

1.Java架构师是什么?要想往Java架构师的方向发展首先要知道Java架构师是什么?Java架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物.一个Java架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展,为目标客户提供更为全面的需求清单.Java架构师在软件开发的整个过程中起着很重要的作用.说的详细一些,架构师就是确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节.扫清主要难点的技术人员.主要着眼于系统的"技术实现

你真的了解微服务架构吗?听听八年阿里架构师怎样讲述Dubbo和Spring Cloud微服务架构

微服务架构是互联网很热门的话题,是互联网技术发展的必然结果.它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.虽然微服务架构没有公认的技术标准和规范或者草案,但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路,例如Dubbo和Spring Cloud.各大互联网公司也有自研的微服务框架,但其模式都于这二者相差不大. 微服务主要的优势如下: 1.降低复杂度 将原来偶合在一起的复杂业务拆分为单个服务,规避了原本复杂度无止境的积累.每一个微服务专

从普通JAVA程序员到阿里架构师,他用了六年

工作年限:8 年服务公司:4 家(含四大门户中的两家)最近职业:Java 架构师职场关键词:社交平台.高并发系统架构设计.技术团队管理.多款从零到一的产品城市! 六年间,这位职人呆过四大门户中的两家,完成了工程师到架构师的蜕变.经手多款从零到一产品的开发和增长,也经历国内最大社交平台亿级流量和用户的架构设计及优化工作.工作上思路清晰.认真负责,是同事们心目中优秀 Problem Solver. 问:介绍一下你自己? 答:我 2008 年硕士毕业后,前 2 年在一家传统 IT 公司,最近 6 年在

听听八年阿里架构师怎样讲述Dubbo和Spring Cloud微服务架构

转自:https://baijiahao.baidu.com/s?id=1600174787011483381&wfr=spider&for=pc 微服务架构是互联网很热门的话题,是互联网技术发展的必然结果.它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.虽然微服务架构没有公认的技术标准和规范或者草案,但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路,例如Dubbo和Spring Cloud.各大互联网公司也有自研的微服务框架,但

阿里架构师分享:一线程序员该如何面对中年危机?

中年危机是真实存在的,即便有技术傍身,在一些特定阶段及环境下,还是难免对未来产生质疑与焦虑.一线程序员该如何面对中年危机呢?这是绝大多数程序员的困惑,这也是绝大多数职场人的困惑.希望大家能通过此篇找到一些方法. 一.程序员中年危机的焦虑 说到程序员的"中年危机",这四个字承载着太多焦虑,而焦虑的原因主要有以下三点: 1.上有老下有小.左有房贷右有车贷,职业选择经不起任性: 2.自己不断增长的期望和实现之间的差距越来越大: 3.行业从业者更加年轻化,互联网寒冬人才需求缩减,自己却一直停滞

在阿里架构师眼中构建一个较为通用的业务技术架构就是如此简单

1.通用架构概述 创业之初,我们往往会为了快速迭代出产品,而选择最简单的技术架构,比如LAMP架构,SSH三层架构.这些架构可以适应初期业务的快速发展,但是,随着业务变得越来越复杂,我们会发现这些架构越来越难支撑业务的发展,出现在一个类中写好几千行代码,一个方法中到处都是if else语句,如果中间遇到主程序猿离职,后面介入的程序猿几乎无法理解这些代码,到最后,产品越来越难迭代,只能推翻重做.如果我们在创业初始就以一种适应性较强的架构去写代码,后面就会少走很多弯路.下面的文章是我自己总结出来的一

记录一次阿里架构师全程手写Spring MVC 原

人见人爱的Spring已然不仅仅只是一个框架了.如今,Spring已然成为了一个生态.但深入了解Spring的却寥寥无几.这里,我带大家一起来看看,我是如何手写Spring的.我将结合对Spring十多年的研究经验,用不到400行代码来描述SpringIOC.DI.MVC的精华设计思想,并保证基本功能完整. 首先,我们先来介绍一下Spring的三个阶段,配置阶段.初始化阶段和运行阶段(如图): 配置阶段:主要是完成application.xml配置和Annotation配置. 初始化阶段:主要是