Redis持久化

Redis持久化

Redis持久化,就是将内存中的数据,永久保存到磁盘上。

Redis持久化有两种方式:RDB(Redis DB)、AOF(AppendOnlyFile)

RDB(快照模式)

在默认情况下,Redis 将数据库快照保存在名字为dump.rdb的二进制文件中,可以在redis.conf配置文件中修改持久化信息

策略:

1)自动:BGSAVE

按照配置文件中的条件满足就执行BGSAVE;

非阻塞,Redis服务正常接收处理客户端请求;

Redis会folk()一个新的子进程来创建RDB文件,子进程处理完后会向父进程发送一个信号,通知它处理完毕;

父进程用新的dump.rdb替代旧文件。

2)手动:SAVE

客户端(redis-cli)发起SAVE命令;

n  阻塞Redis服务,无法响应客户端请求;

n  创建新的dump.rdb替代旧文件

优点

(1)执行效率高;

(2)恢复大数据集速度较AOF快。

缺点

(1)会丢失最近写入、修改的而未能持久化的数据;

(2)folk过程非常耗时,会造成毫秒级不能响应客户端请求。

AOF(追加模式、文本重演)

特点

Append only file,采用追加的方式保存,默认文件appendonly.aof;

记录所有的写操作命令,在服务启动的时候使用这些命令就可以还原数据库;

AOF默认关闭,需要在配置文件中手动开启。

写入机制

说明:AOF机制,添加了一个内存缓冲区(buffer)。


(1)将内容写入缓冲区

(2)当缓冲区被填满、或者用户手动执行fsync、或者系统根据指定的写入磁盘策略自动调用fdatasync命令,才将缓冲区里的内容真正写入磁盘里。

(3)在缓冲区里的内容未写入磁盘之前,可能会丢失。

写入磁盘的策略

nappendfsync选项,这个选项的值可以是always、everysec或者no

Always:服务器每写入一个命令,就调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据

Everysec(默认):服务器每一秒重调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据

No:服务器不主动调用fdatasync,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外停机时,丢失命令的数量是不确定的

运行速度:always的速度慢,everysec和no都很快

 aof重写机制

AOF文件过大,合并重复的操作,AOF会使用尽可能少的命令来记录

重写过程

(1)folk一个子进程负责重写AOF文件

(2)子进程会创建一个临时文件写入AOF信息

n(3)父进程会开辟一个内存缓冲区接收新的写命令

n(4)子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写操作由子进程写入到临时文件中

n(5)新文件替代旧文件

重写的本质:就是将操作同一个键的命令,合并。从而减小AOF文件的体积

aof重写触发机制

(1)手动:

客户端向服务器发送BGREWRITEAOF命令


(2)自动:

配置文件中的选项,自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size ,

触发AOF重写所需的最小体积:只要在AOF文件的体积大于等于size时,才会考虑是否需要进行AOF重写,这个选项用于避免对体积过小的AOF文件进行重写

auto-aof-rewrite-percentage <percent>

指定触发重写所需的AOF文件体积百分比:当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积,并且超过上一次重写之后的AOF文件体积的percent %时,就会触发AOF重写。(如果服务器刚刚启动不久,还没有进行过AOF重写,那么使用服务器启动时载入的AOF文件的体积来作为基准值)。将这个值设置为0表示关闭自动AOF重写。

优点

n写入机制,默认fysnc每秒执行,性能很好不阻塞服务,最多丢失一秒的数据;

n重写机制,优化AOF文件;

n如果误操作了(FLUSHALL等),只要AOF未被重写,停止服务移除AOF文件尾部FLUSHALL命令,重启Redis,可以将数据集恢复到FLUSHALL 执行之前的状态。


缺点

相同数据集,AOF文件体积较RDB大了很多;

恢复数据库速度较RDB慢(文本,命令重演)。

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

推荐阅读更多精彩内容

  • 一、Redis高可用概述 在介绍Redis高可用之前,先说明一下在Redis的语境中高可用的含义。 我们知道,在w...
    空语阅读 1,597评论 0 2
  • 企业级redis集群架构的特点 海量数据 高并发 高可用 要达到高可用,持久化是不可减少的,持久化主要是做灾难恢复...
    lucode阅读 2,206评论 0 7
  • Redis持久化方式有两种:RDB和AOF。 1 RDB持久化 RDB(Redis Database)持久化是把当...
    HRADPX阅读 428评论 0 5
  • 本文翻译自官方文档http://redis.io/topics/persistence 。 Redis 持久化 R...
    六尺帐篷阅读 1,631评论 1 15
  • Redis 持久化: 常用的两种持久化 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持...
    边学边记阅读 1,129评论 0 1