redis的两种持久化的机制,你真的了解么?

redis提供了两种持久化的机制 RDB和AOF机制

RDB(redis Database):RDB保存某一个时间点之前的快照数据。

AOF(Append-Only File):指所有的命令行记录以redis命令请求协议的格式完全持久化存储保存为aof文件

混合持久化(4.0版本以后):指进行AOF重写时子进程将当前时间点的数据快照保存为RDB文件格式,而后将父进程累计命令保存为AOF格式。

RDB快照有两种触发方式

1:为通过配置参数,如下:

通过一定的时间周日内看,命令执行的个数,超过阈值立即执行快照生成

save 900 1  //900秒内有1次更新
save 300 10 //30秒内有10次更新
save 60 10000  //60秒内有10000次更新

2:手动执行bgsave/save,手动触发生成快照 直接执行save会阻塞主进程,bgsave的话会fork一个子进程完成快照

但是redis在发生RDB持久化的过程中有几个问题需要思考

1.RDB快照过程中Redis是否会停止对外服务 2.如果不回停止服务,那如何处理新的请求

接下来我们看redis的RDB持久化的具体过程 [图片上传失败...(image-59becd-1602242176869)]

1:主进程会fork一个子进程

2:子进程会共享一部分主进程的数据空间,并且把共享的数据置为read-only的状态,在这个过程中,子进程以rdb的协议来实行持久化

3:在持久化的过程中是避免不了有新的数据写入的,因为我们有一部分的数据是共享的,两个进程同时拥有一块数据,肯定会导致数据不一致的问题, 但是依赖于操作系统的fork机制,在修改的时候一定是修改部分内存页的数据,这个时候会触发对应内存页的copyonwrite的操作,不会影响子进程完 成持久化,持久化结束后,主进程会对子进程进行回收

RDB的文件格式 [图片上传失败...(image-df5c57-1602242176869)]

redis的rdb文件是一个非常紧凑的格式

开头的REDIS是固定的一个格式,redis在读取持久化文件的时候发现不是以REDIS开头的会报错

0006是RDB_VERSION当前RDB协议的版本

AUX_FIELD_KEY_VALUE_PAIRS是一些辅助的字段

data则为保存的数据,数据首先会选择redis_db,db选择之后就是键值对的数据,对应的键值对又会分为设置过过期时间和未设置过期时间的数据

RDB持久化的优点

1:二进制的数据非常紧凑,数据的恢复速度非常快

2:在持久化的过程中,性能最大化,fork子进程来完成写操作,让主进程继续处理命令,使用单独子进程来进行持久化,保证了redis的高性能

RDB持久化的缺点

1:数据安全性低,RDB是间隔一段时间进行持久化,如果持久化之间redis发生了故障,会发生数据丢失

2:linux fork之后,kernel把父进程中所有的内存页权限都设置readonly,然后子进程的地址空间指向父进程。当父子进程都只读内存时,相安无事。当其中某个进程写内存时,CPU硬件检测到内存页是read-only的,于是触发页异常终端(page-fault),陷入kernal的一个中断例程。中断例程中,kernel的copyonwrite机制就会把触发的异常页复制一份,于是父子进程各自持有独立的一份。如果这个时候有大量的写入操作,会产生大量的分页错误(页异常中断page-fault ),这样就得耗费不少性能在复制上。

AOF持久化执行流程

通过appendonly yes开启 [图片上传失败...(image-8827b-1602242176869)]

Redis使用单线程响应命令,如果每次AOF文件命令都追加到磁盘,会极大的影响处理性能,所以Redis先写入aof缓冲区,根据用户配置的同步磁盘策略写入aof文件中,可以通过appendfsync参数配置同步策略:含义如下

appendfsync always #表示每次更新操作后手动调用fsync()将数据写入到磁盘
appendfsync everysec #表示每秒同步一次(折中方案,默认值)
appendfsync no  #表述等操作系统进行数据缓存同步到磁盘(快速响应客户端,不对AOF做数据同步,同步文件由操作系统负责,通常同步周期最长30S)

AOF重写机制 随着命令得不断写入AOF,文件会越来越大,为了解决这个问题Redis引入了AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程,AOF重写机制可以通过手动触发了自动触发

手动触发:bgreweuteaof命令

自动触发:

auto-aof-rewrite-percentage 100 #表示当前AOF文件空间和上一次重写后AOF文件空间的比值(100%)
auto-aof-rewrite-min-size 64mb #代表AOF重写时文件最小体积

AOF的优点:数据安全,AOF持久化可以配置appendfsync属性,有always,每进行一次命令操作就记录到aof文件中一次。

AOF的缺点:数据集比较大的时候,比RDB启动效率低

混合持久化 可以通过aof-use-rdb-preamble yes开启

加载时,首先会识别AOF文件是否以REDIS字符串开头,如果是,就按照RDB格式加载,加载完RDB后继续按AOF格式加载剩余部分。 混合式持久化方案兼顾了RDB的速度,和AOF的安全性

微信公众号搜索: 程序员养成日记 更多精彩敬请期待

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,519评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,842评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,544评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,742评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,646评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,027评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,513评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,169评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,324评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,268评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,299评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,996评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,591评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,667评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,911评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,288评论 2 345
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,871评论 2 341