Redis 的读写操作都是在内存中,所以 Redis 性能才会高,但是当 Redis重启后,内存中的数据就会丢失,为了保证内存中的数据不会丢失,Redis 实现了数据持久化的机制,这个机制会把数据存储到 磁盘,这样在 Redis 重启就能够从磁盘中恢复原有的数据。
Redis中共有三种数据持久化的方式:
Redis 在执行完一条写操作命令后,就会把该命令以追加的方式写入到一个文件里,然后redis 重启时,会读取该文件记录的命令,然后逐一执行命令的方式来进行数据恢复。
为什么先执行命令,再把数据写入日志呢?
Redis 是先执行写操作命令后,才将该命令记录到 AOF 日志里的,这么做其实有两个好处。
当然,这样做也会有风险:
AOF 写回策略有几种?
Redis 写入 AOF 日志的过程,如下图:
具体过程:
Redis 提供了 三种 写回硬盘的策略,控制的就是上面说的第三步的过程。在 Redis.conf 配置文件中的 appendfsync 配置项可以有以下三种参数可填:
AOF日志过大会触发什么机制?
AOF 日志是一个文件,随着执行的写操作命令越来越多,文件的大小会越来越大。如果当 AOF 日志文件过大就会带来性能问题,比如 重启 Redis 后,需要读AOF文件的内容以恢复数据,如果文件过大,整个恢复过程就会很慢。
所以,为了Redis 为了避免 AOF 文件越写越大,提供了 AOF 重写机制,当 AOF 文件的大小超过所设定的阈值后,Redis 会启用 Redis 重写机制,来压缩 AOF 文件。
AOF 重写机制是在重写时,读取当前数据库中的所有键值对,然后将每一个键值用一条命令记录到 [新的 AOF 文件],等到全部记录完后,就将新的 AOF 文件替换掉现有的 AOF文件。
eg:在没有重写机制前,假设前后执行了 [set name xiaolin] 和 [set name xiaolincoding] 这两个命令的话,就会将这两个命令记录到 AOF 文件。
但是在使用重写机制后,就会读取 name 最新的 value (键值对),然后用一条 [set name xiaolincoding] 命令记录到新的 AOF 文件,之前第一个命令就没必要记录了,因为它属于 [历史] 命令,没有作用了。这样一来,一个键值对在重写日志中只有一条命令就行了。
重写工作完成后,就会将新的 AOF 文件覆盖现有的 AOF 文件,这就相当于压缩了 AOF 文件,使得 AOF 文件体积小了。
重写 AOF 日志的过程是怎样的?
Redis 的重写 AOF 过程是由后台进程 bgrewriteaof 来完成的,这么做由两个好处:
触发重写机制后,主进程就会创建重写 AOF 的子进程,此时父子进程共享物理内存,重写子进程只会对这个内存进行只读,重写 AOF 子进程会读取数据库里的所有数据,并逐一把内存数据的键值对转换成一条命令,再将命令记录到重写日志(新的AOF文件)。
但是重写过程中,主进程依然可以正常处理命令,那么问题来了,重写 AOF 日志过程中,如果主进程修改了已经存在 key-value ,那么会发生写时复制,此时这个 key-value 数据在子进程的内存数据就跟主进程的内存数据不一致了,这时要怎么办呢?
为了解决这种数据不一致的问题,Redis 设置了一个 AOF 重写缓冲区,这个缓冲区在创建 bgrewriteaof 子进程后就开始使用。
在重写 AOF 期间,当 Redis 执行完一个写命令后,它会同时将这个写命令写入到 [ AOF缓冲区 ] 和 [ AOF重写缓冲区 ]。
也就是说,在 bgrewriteaof 子进程执行 AOF 重写期间,主进程需要执行以下三个工作:
当子进程完成 AOF 重写工作(扫描数据库中所有数据,逐一把内存数据的键值对转换成一条命令,再将命令记录到重写日志)后,会向主进程发送一条信号,信号是进程间通讯的一种方式,而且是异步的。
主进程收到该信号后,会调用一个信号处理函数,该函数主要做以下工作:
信号函数执行完后,主进程就可以继续像往常一样处理命令了。
因为 AOF 日志记录的是操作命令,不是实际数据,所以用 AOF 方法做故障恢复时,需要全量把日志都执行一遍,一旦 AOF 日志非常多,势必会造成 Redis 的恢复操作缓慢。
为了解决这个问题,Redis 增加了 RDB 快照。所谓的快照,就是记录某一瞬间的东西(与MySQL中的 Read View 类似)。
所以,RDB快照就是记录某一个瞬间的内存数据,记录的是实际数据,而 AOF 文件记录的是命令操作的日志,而不是实际数据。
因此在 Redis 恢复数据时,RDB 恢复数据的效率比 AOF 高一些,因为直接将 RDB 文件读入内存就行了,不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。
RDB 做快照时会阻塞线程吗?
Redis 提供了两个命令来生成 RDB 文件,分别是 save 和 bgsave ,他们的区别就是在于是否在 [主线程] 里执行:
Redis 还可以通过配置文件的选项来实现每隔一段时间自动执行一次 bgsave 命令,默认会提供以下配置:
save 900 1
save 300 10
save 60 10000
选项名虽然是 save ,但实际上执行的时 bgsave 命令,也就是会创建子进程来生成 RDB 快照文件。只要满足上面条件的任意一个,就会执行 bgsave ,它们的意思分别是:
PS:Redis 的快照是全量快照,也就是说每次执行快照,都是把内存中的 [所有数据] 都记录到磁盘中。所以执行快照是一个比较重的操作,如果频率太频繁,可能会对 Redis 性能产生影响。如果频率太低,服务器故障时,丢失的数据会更多。
RDB 在执行快照的时候,数据能修改吗?
可以,在执行 bgsave 的过程中,Redis 依然可以继续处理操作命令,也就是数据是能被修改的,关键的技术就在于写时复制技术。
执行 bgsave 命令的时候,会通过 fork() 创建子进程,此时子进程和父进程时是共享一片内存数据的,因为创建子进程的时候,会复制父进程的页表,但是页表指向的物理内存还是一个,此时如果主线程执行读操作,则主线程和 bgsave 子进程互相不影响。
如果主线程执行写操作,则被修改的数据会复制一份副本,然后 bgsave 子进程会把该副本数据写入 RDB 文件,在这个过程中,主线程仍然可以直接修改原来的数据。
RDB 优点是数据恢复速度快,但是快照的频率不好把握。频率太低,丢失的数据就会比较多,频率太高就会影响性能。
AOF 优点是丢失数据少,但是数据恢复不快。
为了集成两者的优点, Redis 4.0 提出了混合使用 AOF 日志和内存快照,也叫混合持久化,即保证了 Redis 重启速度,又降低了数据丢失的风险。
混合持久化工作在 AOF 日志重写过程,当开启了混合持久化时,在 AOF 重写日志时,fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件,然后主线程处理的操作命令会被记录在重写缓冲区里,重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件,写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的 AOF 文件。
也就是说,使用了混合持久化,AOF 文件的前半部分是 RDB 格式的全量数据,后半部分是 AOF 格式的增量数据。
这样的好处在于,重启 Redis 加载数据的时候,由于 前半部分是 RDB 内容,这样加载的时候速度就会很快。
加载完 RDB 的内容后,才会加载后半部分的 AOF 内容,这里的内容是 Redis 后台子进程重写 AOF 期间,主线程处理的操作命令,可以使得数据更少的丢失。
混合持久化优点:
混合持久化缺点: