Redis 的持久化机制--RDB和AOF

Redis 的持久化机制—RDB和AOF

Redis 的数据全部在内存里,如果突然宕机,数据就会全部丢失,因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失,这种机制就是 Redis 的持久化机制,Redis提供了两种持久化的方式

  • RDB(Redis DataBase)
  • AOF(Append Only File)

    RDB:就是将存储的数据以快照的方式存储到磁盘上,快照是内存数据的二进制序列化形式,在存储上非常紧凑
    AOF:将redis执行过的所有写指令记录下来,通过write函数追加到AOF文件的末尾。在下次redis重新启动时,只要把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了。

    RDB机制

    概念

    RDB持久化是指在一定的 时间间隔内将内存的数据集快照写入磁盘, 默认的持久化方式 这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照,下面是默认的快照保存配置

1
2
3
save 900 1 #900秒内如果超过1个key被修改,则发起快照保存
save 300 10 #300秒内容如超过10个key被修改,则发起快照保存
save 60 10000

RDB文件保存过程

  1. redis在持久化时会调用 glibc 的函数fork产生一个子进程,快照持久化完全交给子进程来处理,子进程刚刚产生时,它和父进程共享内存里面的代码段和数据段
  2. fork的字进程只拷贝了父进程的页表,实际的物理内存还是同父进程同一块
  3. 父进程继续处理client请求,子进程做数据持久化,它不会修改现有的内存数据结构,它只是对数据结构进行遍历读取,然后序列化写到磁盘中。

注:每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。

优势

  1. 方便备份
  2. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

AOF

概念

AOF 日志存储的是 Redis 服务器的顺序指令序列,AOF 日志只记录对内存进行修改的指令记录
Redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
Redis 会在收到客户端修改指令后,进行参数校验进行逻辑处理后,如果没问题,就立即将该指令文本存储到 AOF 日志中,也就是先执行指令才将日志存盘。这点不同于leveldb、hbase等存储引擎,它们都是先存储日志再做逻辑处理。

AOF文件保存过程

  1. AOF 日志是以文件的形式存在的,当程序对 AOF 日志文件进行写操作时,实际上是将内容写到了内核为文件描述符分配的一个内存缓存中,然后内核会异步将脏数据刷回到磁盘的。
  2. 这就意味着如果机器突然宕机,AOF 日志内容可能还没有来得及完全刷到磁盘中,这个时候就会出现日志丢失。那该怎么办?
  3. Linux 的glibc提供了fsync(int fd)函数可以将指定文件的内容强制从内核缓存刷到磁盘。只要 Redis 进程实时调用 fsync 函数就可以保证 aof 日志不丢失。但是 fsync 是一个磁盘 IO 操作,它很慢!如果 Redis 执行一条指令就要 fsync 一次,那么 Redis 高性能的地位就不保了,fsync是一个后台操作。
  4. 在生产环境的服务器中,Redis 通常是每隔 1s 左右执行一次 fsync 操作,周期 1s 是可以配置的。这是在数据安全性和性能之间做了一个折中,在保持高性能的同时,尽可能使得数据少丢失。
  5. Redis 同样也提供了另外两种策略,一个是永不 fsync——让操作系统来决定何时同步磁盘,很不安全,另一个是来一个指令就 fsync 一次——非常慢

    AOF 重写

    Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令,序列化到一个新的 AOF 日志文件中。序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中,追加完毕后就立即替代旧的 AOF 日志文件了,瘦身工作就完成了,比如 incr test命令100次,文件中必须保存全部的100条命令,bgrewriteaof 就回合成一条命令 set test 100。

总结


快照是通过开启子进程的方式进行的,它是一个比较耗资源的操作。

  1. 遍历整个内存,大块写磁盘会加重系统负载
  2. AOF 的 fsync 是一个耗时的 IO 操作,它会降低 Redis 性能,同时也会增加系统 IO 负担
    所以通常 Redis 的主节点是不会进行持久化操作,持久化操作主要在从节点进行。从节点是备份节点,没有来自客户端请求的压力,它的操作系统资源往往比较充沛。

    Redis 4.0 混合持久化

    重启 Redis 时,我们很少使用 rdb 来恢复内存状态,因为会丢失大量数据。我们通常使用 AOF 日志重放,但是重放 AOF 日志性能相对 rdb 来说要慢很多,这样在 Redis 实例很大的情况下,启动需要花费很长的时间。
    Redis 4.0 为了解决这个问题,带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志,而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志,通常这部分 AOF 日志很小
    于是在 Redis 重启的时候,可以先加载 rdb 的内容,然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放,重启效率因此大幅得到提升

    思考

    持久性-Redis数据丢失率,不管是RDB还是AOF都会进行IO操作,那么在持久化过程为了提高性能就需要降低保存频率,那么必然会有数据丢失的情况,无法保证数据的完整性,这在业务上可能不被允许,是否考虑更好的解决方案。


  Redis

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×