支持的数据持久化方案

  • AOF
  • RDB
  • 混合持久化

AOF持久化

aof持久化原理是redis每执行一次命令,就将该命令存储到aof。 数据恢复时读取aof文件,将文件内容重新解析为命令后完成数据在内存中的重放

日志回写机制

always

同步写,每次的数据变更,都会写些入内存,然后调用系统的fsync进行数据落盘,可以最大程度的保证数据不丢失

everySec

由于always策略会阻塞主进程,当写入大key到磁盘,或磁盘产生性能瓶颈时,这是对单线程的redis来说,这是致命的,所以产生了eversec这种折中方案,它的意思是每次写操作命令执行完后,先将命令写入到 AOF 文件的内核缓冲区,然后每隔一秒将缓冲区里的内容异步写回到硬盘

no

不由redis控制数据落盘机制,将数据写回硬盘的的时机交给操作系统控制。也就是每次写操作命令执行完后,先将命令写入到 AOF 文件的内核缓冲区,再由操作系统决定何时将缓冲区内容写回硬盘。

以上三种策略性能从低到高,数据可靠性从高到低。他们都无法完美的解决主进程阻塞和数据丢失的问题,原因如下:
1、always可以最大程度的保证数据不丢失,但是会导致进程阻塞
2、no策略将数据回写能力交给了操作系统,假设数据还在内核缓冲区时发生了宕机,数据是会丢失的。no策略是异步的不会阻塞主进程
3、everysec 是每秒进行一次异步写,可能会丢失一秒的数据

RDB 持久化

rdb持久化的原理是将所有的数据进行快照存储在rdb文件中。数据恢复时直接读取rdb中的数据到内存实现数据重放。

  • AOF操作的是命令
  • RDB操作的是数据

    持久化机制

    rdb一般是通过配置bgsave的时间,来定时进行内存快照

性能问题

执行快照时可以进行内存的数据变更吗?

可以,rdb利用了Linux中的写时复制技术,数据写入时会重新copy出一块内存空间进行存放,这里有个注意的点:如果在快照期间产生了全量数据变更,那么会占用正常情况下2倍的内存空间!

执行快照时会阻塞主进程吗?

bgsave是在后台异步执行的,不会阻塞主进程

虽然rdb带来了更高效的的数据重放能力,但是rdb数据数据丢失的可能性确更严重,因为rdb是全量快照,可以过于频繁的保存数据会对性能产生影响

混合持久化AOF+RDB

混合持久化可以兼备RDB的数据回放速度和AOF丢失数据少的优点,原理是将日志文件拆分为2个部分,前半部分是RDB全量快照, 后半部分是AOF格式的增量数据

Copyright © 运维知识库 all right reserved,powered by Gitbook文件修订时间: 2023-10-13 15:50:03

results matching ""

    No results matching ""