redis默认开启持久化（redis什么时候持久化）

本文目录

• redis什么时候持久化
• docker配置redis持久化
• 面试中问到Redis持久化的原理，本篇在做详细解答
• Redis持久化策略（看这篇,你肯定会有所获）
• redis怎么做持久化
• Redis如何实现持久化方案（RDB和AOF使用）
• redis怎么实现持久化

redis什么时候持久化

持久化存储是将 Redis存储在内存中的数据存储在硬盘中，实现数据的永久保存。
我们都知道 Redis 是一个基于内存的 nosql 数据库，内存存储很容易造成数据的丢失，因为当服务器关机等一些异常情况都会导致存储在内存中的数据丢失。 （推荐学习：Redis视频教程）
开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。
redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
二者的区别
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

docker配置redis持久化

确认docker已安装并配置好redis

未配置redis可以参考 docker配置redis

以下内容是在我自己学习过程中，自己做持久化。其实菜鸟教程上也有完整的安装以及配置教程。
redis默认持久化方式为RDB，RDB就是Snapshot快照存储，是默认的持久化方式。
本文用的是aof持久化方式，具体区别，可以

因为我们以及创建完 目录 /root/redis 及 /root/redis/data/ 所以直接创建Dockerfile文件

1.进入redis目录，创建Dockerfile

2.修改Dockerfile内容如下：
data目录将映射为redis容器配置的/data目录,作为redis数据持久化的存储目录

3.修改redis配置文件redis.conf
***隐藏网址***
本文启用aof持久化方式，其他默认，未修改

4.启动redis

这样基本就完事啦。

谢谢。。。。。

面试中问到Redis持久化的原理，本篇在做详细解答

我们知道redis是一个 高效的分布式内存数据库 ，由于是操作内存所以性能非常之快，通常用它来做分布式缓存，用来提高微服务的高性能，但是因为是内存操作，所以当出现服务器故障，断电等情况就会造成 内存数据丢失 ，不可恢复，因此redis 引入了持久化机制来将内存数据写入磁盘，从而保障了Redis的数据不被丢失。

Redis有两种持久化的方式，一种是RDB，另外种是AOF。

RDB是将Redis内存中数据的快照存储在磁盘内，是Redis的默认持久化方案。

RDB持久化默认有三种策略

可在redis.conf中配置，会以一段时间内达到指定修改的次数为规则来触发快照操作，快照文件名为dump.rdb。每当Redis服务重启的时候都会从该文件中把数据加载到内存中。

在60秒内有10000次操作即触发RDB持久化。

没有满足第一种条件时，在900秒内有1次操作即触发RDB持久化。

没有满足第二种条件时，在300秒内有10次操作即触发RDB持久化。

RDB持久化除了可以根据配置中的策略来触发外，还可以使用save和bgsave命令手动来触发。这两个命令的区别在于save会阻塞服务器进程。在执行save命令的过程中，服务器不能处理任何请求，但是bgsave（background save，后台保存）命令会通过一个子进程在后台处理数据RDB持久化。本质上save和bgsave调用的都是rdbSave函数，所以Redis不允许save和bgsave命令同时执行，当然这也是为了避免RDB文件数据出现不一致性的问题。

每次都是一个大文件，备份写入IO操作笔记大，很容易耗时，影响进程资源使用。

如果最近一次进程崩溃，那么最近一次数据备份后的数据就被丢失。

文件直接就可以当冷备使用

AOF（Append Only File）以独立日志的方式记录每次的写命令，可以很好地解决了数据持久化的实时性。系统重启时可以重新执行AOF文件中的命令来恢复数据。AOF会先把命令追加在AOF缓冲区，然后根据对应策略写入硬盘。

AOF的实现流程有三个步骤

步骤一

把命令追加到AOF缓冲区，

步骤二

将缓冲区的内容写入程序缓冲区

步骤三

将程序缓冲区的内容写入文件

当AOF持久化功能处于开启状态时，服务器每执行完一个命令就会将命令以协议格式追加写入redisServer结构体的aof_buf缓冲区。而在服务重启的时候会把AOF文件加载到缓冲区中。

AOF有 三种触发机制

·always：每次发生数据变更都会被立即记录到磁盘，性能较差，但数据完整性比较好。

·everysec：每秒钟将aof_buf缓冲区的内容写入AOF文件，如果宕机，就会有1秒内的数据丢失。

·no：将数据同步操作交给操作系统来处理，性能最好，但是数据可靠性最差。在配置文件中设置appendonly=yes后，若没有指定apendfsync，默认会使用everysec选项。

写入指令随着时间的推移，记录了很多重复的指令，导致数据量非常大。

RDB优先级高于AOF

RDB小，AOF较大

RDB慢，AOF快

RDB快，AOF慢

Redis持久化策略（看这篇,你肯定会有所获）

RDB：Redis DataBase ， 记录快照

        RDB是redis 默认的持久化方案. RDB 是当满足一定条件时, 就会将redis内存中的数据写入磁盘,并生成一个快照文件dump.rdb 文件.Redis 重启会通过加载dump.rdb文件恢复数据.

        一定条件分为以下几种情况: 1.自动触发  2. 手动触发 . 下面分开说明下:

a).redis.conf 中 SNAPSHOTTING 其中定义了触发把数据保存到磁盘的触发频率.

        如果不需要rdb 方案, 注释save 或者配置成空字符串" ".

        save 900 1 #900秒内至少有一个key被修改(包括添加)

        save 300 10 #400秒内至少10个key被修改

        save 10000 #60秒内至少有10000个key 被修改.

        这三条配置不冲突, 只要满足一条就触发.

        rdb 文件位置和目录 (默认在安装根目录下) 

        #文件路径

        dir ./

        #文件名称

        dbfilename dump.rdb

        #是否以LZY压缩rdb 文件

        rdbcompression yes 

        #开启数据校验

        rdbchecksum yes

b) shutdown触发 ,保证服务器正常关闭.

c) flushall , rdb文件是空的, 会生成一个空的文件,所以这种情况也没有什么意义.但需要知道,这种情况下

会触发生成rdb文件.

Redis 提供了两条命令: save 和 bgsave

a). save 命令

        save 在生成快照的时候会阻塞当前Redis 服务器,Redis不能处理其他命令.如果内存数据较多,会造成

b).bgsave 命令

        执行bgsave命令时,   Redis会在后台进行异步快照操作,快照同时还可以响应客户端请求.

具体操作

        具体操作:Redis进程会执行fork操作创建子进程(copy-on-write),RDB 持久化过程由子进程负载,完成后自动结束.它不会记录fork之后产生的记录.阻塞只发送在fork阶段,一般时间较短.

一.优势

    1.RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集.这种文件非常适合进行备份和

灾难恢复.

    2.生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存的工作,主进程不需要进行任何

IO操作.

    3.RDB在恢复大数据集时的速度比AOF的恢复速度要快

二.劣势

    1).RDB 没办法做到实时持久化/妙级持久化.因为bgsave每次运行都要执行fork创建子进程,频繁执行成本过高.    

    2).在一定间隔时间做一次备份,所以如果Redis 以为down掉的话,就会丢失最后一次快照之后所有修改

(数据有丢失)

AOF：《Append Only File》 ， 记录日志

Redis 默认不开启.AOF采用日志的形式来记录每个写操作,并追加到文件中.开启后,执行更改Redis    命令时,就会把命令写入到AOF文件中.

Redis 重启时会根据日志文件的内容把写指令从前往后执行一次以完成数据的恢复工作.

#开关

appendonly no

#文件名

appendfilename "appendonly.aof"

        由于操作系统缓存机制,AOF数据并没有真正地写入硬盘,而是进入了系统的硬盘缓存.什么时候

把缓冲区的内容写入到AOF文件中? 由下面参数决定

appendfsync :  值: no  \ always \everysec 

        no: 表示不执行fync, 由操作系统保证数据同步到磁盘,速度最快,但是不安全.

        always:表示每次写入都执行fync,以保证数据同步到磁盘,效率很低

        everysec:表示每秒执行以fync ,可能会导致丢失1s数据.通常选择everysec,兼顾效率和安全性.

    因为AOF文件只有一个, 随着redis 不断进行,AOF 的文件会越来越大,文件越大, 文件占用服务器内存

以及AOF恢复要求时间越长.

    为了解决这个问题,可以使用bgwriteaof来重写.那什么时候重写? 又是怎样重写?

    一. 什么时候重写?

    #重写触发机制

    auto-aof-rewrite-percentage 100 默认值是100. 当前aof 文件大小超过 上一次重写的aof文件大小百分之多少进行重写,即当aof文件增长到一定大小时,Redis能够调用bgwriteaof对日志文件进行重写.当前aof文件大小是上次日志重写得到aof文件大小的二倍时, 自动启动新的日志重写过程.

    auto-aof-rewrite-min-size 默认是64M.设置允许重写的最小aof文件大小,避免达到了约定百分比 但尺寸

仍然很小的情况还要重写.

   二. 怎样重写?

    并不是对原文件进行重新整理,而是直接读取服务器上现有的键值对,然后用一条命令去代替之间记录这

个键值对的多条命令,生成一个新的文件后去替换原来的 AOF文件.

    看下面这两个参数:

        no-appendfsync-on-rewrite

        aof-load-truncated
   AOF 数据恢复

        重启Redis之后就会进行AOF文件恢复.

   AOF 的优势和劣势

优点:

1.AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis最多也就丢失

1秒的数据.

缺点:

1.对于具有相同数据的Redis, AOF文件通常比RDF文件体积更大(RDB存的是数据快照)

2.虽然AOF提供了多种同步的频率,默认的情况下,没秒同步一次的频率也具有较高的性能.在高并发的情况下,RDB比AOF具有更好的性能.

        如果可以忍一小段时间数据的丢失,毫无疑问使用RDB 是最好的,定时生成RDB快照非常便于进行数据备份,而且RDB恢复数据集的速度也要比AOF恢复速度要快.

        否则就要使用AOF重写.但是一般情况下建议不要单独使用某一种持久化机制,而是两种一起用.
本文内容来自咕泡学院-青山老师,感谢青山老师!!

redis怎么做持久化

Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。
Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
Redis跟memcache不同的是，储存在Redis中的数据是持久化的，断电或重启后，数据也不会丢失。因为Redis的存储分为内存存储、磁盘存储和log文件三部分，重启后，Redis可以从磁盘重新将数据加载到内存中，这些可以通过配置文件对其进行配置，正因为这样，Redis才能实现持久化。

Redis如何实现持久化方案（RDB和AOF使用）

以上三条符合任意一条，就自动生成rdb，内部使用bgsave
#配置：
save 900 1 #配置一条
save 300 10 #配置一条
save 60 10000 #配置一条
dbfilename dump.rdb #rdb文件的名字，默认为dump.rdb
dir ./ #rdb文件存在当前目录
stop-writes-on-bgsave-error yes #如果bgsave出现错误，是否停止写入，默认为yes
rdbcompression yes #采用压缩格式
rdbchecksum yes #是否对rdb文件进行校验和检验
#最佳配置
save 900 1
save 300 10
save 60 10000 dbfilename dump-${port}.rdb
#以端口号作为文件名，可能一台机器上很多reids，不会乱
dir /bigdiskpath #保存路径放到一个大硬盘位置目录
stop-writes-on-bgsave-error yes
#出现错误停止
rdbcompression yes #压缩
rdbchecksum yes #校验
RDB触发机制一般使用第三种方式，但是这种方式也会有缺点。如果修改的条数没有在设置范围内那么就不会触发，就会引发很多数据没有持久化的情况。所以我们一般采用下面方式：AOF。
如果是保存不重要的数据可以使用RDB方式（比如缓存数据），如果是保存很重要的数据就要使用AOF，但是两种方式也可以同时使用。
三、AOF
1.RDB问题
耗时，耗性能。不可控，可能会丢失数据。
2.AOF介绍
客户端每写入一条命令，都记录一条日志，放到日志文件中，如果出现宕机，可以将数据完全恢复
3.AOF的三种策略
日志不是直接写到硬盘上，而是先放在缓冲区，缓冲区根据一些策略，写到硬盘上
#第一种：always：redis--》写命令刷新的缓冲区---》每条命令fsync到硬盘---》AOF文件
#第二种：everysec（默认值）：redis——》写命令刷新的缓冲区---》每秒把缓冲区fsync到硬盘--》AOF文件
#第三种：no:redis——》写命令刷新的缓冲区---》操作系统决定，缓冲区fsync到硬盘--》AOF文件
命令alwayseverysecno优点不丢失数据
每秒一次fsync，丢失1秒数据 不用管
缺点
IO开销大，一般的sata盘只有几百TPS丢1秒数据不可控4.AOF重写
随着命令的逐步写入，并发量的变大， AOF文件会越来越大，通过AOF重写来解决该问题
原生AOFAOF重写set hello world《br/》
set hello java《br/》
set hello hehe《br/》
incr counter《br/》
ncr counter《br/》
rpush mylist a《br/》
rpush mylist b《br/》
rpush mylist c《br/》
过期数据
set hello hehe《br/》
set counter 2《br/》
rpush mylist a b c

本质就是把过期的，无用的，重复的，可以优化的命令，来优化这样可以减少磁盘占用量，加速恢复速度
实现方式
bgrewriteaof：客户端向服务端发送bgrewriteaof命令，服务端会起一个fork进程，完成AOF重写
AOF重写配置：
重写流程
AOF配置文件 （******）
appendonly yes #将该选项设置为yes，打开appendfilename "appendonly-${port}.aof" #文件保存的名字appendfsync everysec #采用第二种策略dir /bigdiskpath #存放的路径no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失
四、RDB和AOF的选择
1.rdb和aof的比较
命令rdbaof启动优先级低
高(挂掉重启，会加载aof的数据)
体积小
大
恢复速度
快慢
数据安全性
丢数据
根据策略决定
轻重
重
轻
2.rdb最佳策略
rdb关掉，主从操作时
集中管理：按天，按小时备份数据
主从配置，从节点打开
3.aof最佳策略
开：缓存和存储，大部分情况都打开，
aof重写集中管理
everysec：通过每秒刷新的策略
4.最佳策略
小分片：每个redis的最大内存为4g
缓存或存储：根据特性，使用不通策略
时时监控硬盘，内存，负载网络等
有足够内存

redis怎么实现持久化

redis作为当下web编程必不可少的服务，它的特点的是显而易见，相对memcached而言，做缓存，重启数据不丢失，非常好用。那么问题来了，它是怎么做到的呢？
RDB
RDB就是持久化的一种手段，把内存中数据在某些条件下写到磁盘中去。那么在哪些条件下写入呢？不可能无脑写入，来一个写一个，影响性能，也不能等老半天才写一个，万一中间宕机了，数据全丢失，还不如用memcached。在redis的配置里有着这样的一段配置：
save 900 1
save 300 10
save 60 10000
很关键的一段配置，这时RDB持久化的核心。意思是：
1.如果900秒时，有1个key变化（插入或者更新），我就同步到磁盘一下
2.如果300秒时，有10个key变化（插入或者更新），我就同步到磁盘一下
3.如果60秒时，有10000个key变化（插入或者更新），我就同步到磁盘一下
这些时间点和变化的数量是怎么知道的，这时有另外两个极为关键的东西，一个叫dirty计数器，一个叫lastsave（上次save的时间），dirty计数器专门记录从上次save后变化key的数量，lastsave记录执行save的时间，举个例子刚开始时间是time1，dirty是0，这时有20个key发生了变化，dirty是20，然后现在的时间是time2，time2-time1 》= 300,满足第二个条件，这时内存中的数据会save一下，同时dirty清为0，然后再等待条件触发。
如果我60秒内有10万个key，那么问题来了，一下大量磁盘io来临，这时redis主进程就会阻塞，期间的所有的命令都不执行，这哪能行，于是就来了一个叫bgsave的，它是redis主进程fork出来的一个子进程，专门执行rdb的持久化工作的。
保存的文件格式是二进制格式的，万一数据库宕机，恢复不需要人为干预，redis会自动读取磁盘文件。
AOF
与RDB不同，AOF存储的是你执行的命令，当aof功能打开的时候，执行的更新命令不会直接写到aof文件中去，而是先写到一个aof buf中，我们知道不能一直往buf中写，buf也是内存啊，那么何时才能同步到磁盘中去呢？redis中也有这样一段配置
appendfsync always
appendfsync everysec
appendfsync no
意思是：
1.只要有更新的命令我就同步
2.如果上次同步时间距离现在超过一秒就同步
3.不同步，等待操作系统自己判断（什么时候我有空我才同步）
分析下，第一种io频繁，io压力大，但丢失数据的概率最小，第二种io压力不是很大，最多也就丢失1秒左右的数据，第三中io压力很小，丢失数据概率太大。综合考虑，一般第二种。但还有个问题，我执行了100次INCR num，按道理num就是100，aof中也有100个同样的命令，没毛病，那么请问执行100次INCR num和SET num 100有什么区别，同样的结果前者多了99倍的空间，很浪费啊，于是就出现了AOF重写，它是怎么做到的。很简单：首先从数据库读取现在的值，然后用一条记录代替，这就是AOF重写的原理。重写很花时间，所以也是子进程来处理。重写的过程中，如果有新的命令来临怎么办，老办法，写buf缓冲，重写完成后，把buf中的命令追加到新的aof中，然后用新的aof替代老的aof，就实现了重写。
本文来自redis教程，欢迎学习。