踢一场足球需要很长的时间,那么就需要充足的体力来支撑。那么redis中的持久化机制是怎么样的?接下来就来聊一聊。
每一个足球运动员的身体是真的强,为了胜利,在大草原上奔跑,那个路程我感觉比我一年都跑的多。
client redis[内存] -----> 内存数据- 数据持久化–>磁盘
Redis官方提供了两种不同的持久化方法来将数据存储到硬盘里面分别是:
这种方式可以将某一时刻的所有数据都写入硬盘中,当然这也是redis的默认开启持久化方式,保存的文件是以.rdb形式结尾的文件因此这种方式也称之为RDB方式。
RDB:在指定时间间隔后,将内存中的数据集快照写入数据库 ;在恢复时候,直接读取快照文件,进行数据的恢复 ;
默认情况下, Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。文件名可以在配置文件中进行自定义。
客户端方式: BGSAVE 和 SAVE指令
服务器配置自动触发
客户端方式是BGSAVE
客户端可以使用BGSAVE
命令来创建一个快照,当接收到客户端的BGSAVE命令时,redis会调用fork¹来创建一个子进程,然后子进程负责将快照写入磁盘中,而父进程则继续处理命令请求。
名词解释
:fork当一个进程创建子进程的时候,底层的操作系统会创建该进程的一个副本,在类Lunix系统中创建子进程的操作会进行优化:在刚开始的时候,父子进程共享相同内存,直到父进程或子进程对内存进行了写之后,对被写入的内存的共享才会结束服务。
在进行 RDB
的时候,redis
的主线程是不会做 io
操作的,主线程会 fork
一个子线程来完成该操作;
客户端方式SAVE
客户端还可以使用SAVE命令来创建一个快照,接收到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他的命令。
服务器配置方式之满足配置自动触发
如果用户在redis.conf中设置了save配置选项,redis会在save选项条件满足之后自动触发一次BGSAVE命令,如果设置多个save配置选项,当任意一个save配置选项条件满足。
触发机制
如何恢复rdb文件
$ config get dir
"dir"
"/usr/local/bin"
服务器接收客户端shutdown指令
当redis通过shutdown指令接收到关闭服务器的请求时,会执行一个save命令,阻塞所有的客户端,不再执行客户端执行发送的任何命令,并且在save命令执行完毕之后关闭服务器
# 1.修改生成快照名称
$ dbfilename dump.rdb
# 2.修改生成位置
$ dir ./
优点:
缺点:
这种方式可以将所有客户端执行的写命令记录到日志文件中,AOF持久化会将被执行的写命令写到AOF的文件末尾,以此来记录数据发生的变化,因此只要redis从头到尾执行一次AOF文件所包含的所有写命令,就可以恢复AOF文件的记录的数据集。(将我们所有的命令都记录下来,history,恢复的时候就把这个文件全部再执行一遍)
在redis的默认配置中AOF持久化机制是没有开启的,需要在配置中开启,默认是不开启的,我们需要手动配置,然后重启redis,就可以生效了!
开启AOF持久化
修改日志同步频率
# appendfsync always
appendfsync everysec
# appendfsync no
如果这个aof文件有错位,这时候redis是启动不起来的,我需要修改这个aof文件
redis给我们提供了一个工具 直接运行这个就行redis-check-aof --fix
如果文件正常,重启就可以直接恢复了
优点
缺点
RDB是日志,而AOF是记录写操作的
RDB 和 AOF 对比
RDB | AOF | |
---|---|---|
启动优先级 | 低 | 高 |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定 |
如何选择使用哪种持久化方式?
一般来说, 如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能。
如果你非常关心你的数据, 但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化, 但并不推荐这种方式: 因为定时生成 RDB 快照(snapshot)非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。
因为是无限追加 ,AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次,文件中必须保存全部的100条命令,其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件Redis提供了AOF重写(ReWriter)机制。
用来在一定程度上减小AOF文件的体积
注意:重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,替换原有的文件这点和快照有点类似。
重写流程
两种持久化方案既可以同时使用(aof),又可以单独使用,在某种情况下也可以都不使用,具体使用那种持久化方案取决于用户的数据和应用决定。
无论使用AOF还是快照机制持久化,将数据持久化到硬盘都是有必要的,除了持久化外,用户还应该对持久化的文件进行备份(最好备份在多个不同地方)。
AOF和RDB同时存在的话,会优先考虑AOF,因为它全,而且丢失数据不会超过2s。
部分图片参考了网络上的内容,有问题请联系。