Redis 中数据的持久化前言我们知道 Redis 是内存数据库所有操作都在内存上完成。内存的话服务器断电内存上面的数据就会丢失了。这个问题显然是需要解决的。Redis 中引入了持久化来避免数据的丢失主要有两种持久化的方式 RDB 持久化和 AOF 持久化。AOF 持久化什么是 AOF 持久化AOF(Append Only File):通过保存数据库执行的命令来记录数据库的状态。AOF日志对数据库命令的保存顺序是Redis 先执行命令把数据写入内存然后才记录日志。为什么要后记录日志呢1、后写能够避免记录到错误的命令。因为是先执行命令后写入日志只有命令执行成功了命令才能被写入到日志中。2、避免阻塞当前的写操作是在命令执行后才记录日志所以不会阻塞当前的写操作。AOF 的潜在风险1、如果命令执行成功写入日志的时候宕机了命令没有写入到日志中这时候就有丢失数据的风险了因为这时候没有写入日志服务断电之后这部分数据就丢失了。这种场景在别的地方也很常见比如基于 MQ 实现分布式事务也会出现业务处理成功 事务消息发送失败这种场景RabbitMQRocketMQKafka 事务性消息丢失和消息重复发送的处理策略2、AOF 日志写入也是在主线程进行的如果磁盘的压力很大写入速度变慢了会影响后续的操作。这两种情况可以通过调整 AOF 文件的写入磁盘的时机来避免AOF 文件的写入和同步AOF 文件持久化的功能分成三个步骤文件追加(append),文件写入文件同步(sync)。AOF 文件在写入磁盘之前是先写入到 aof_buf 缓冲区中然后通过调用 flushAppendOnlyFile 将缓冲区中的内容保存到 AOF 文件中。写入的策略通过 appendfsync 来进行配置Always同步写回 每次操作命令执行完后同步将 AOF 日志数据写回硬盘Everysec每秒写回 每次操作命令执行完后先将命令写入到 AOF 文件的内核缓冲区然后每隔一秒将缓冲区里的内容写回到硬盘No操作系统控制的写回 Redis 不在控制命令的写会时机交由系统控制。每次操作命令执行完成之后命令会被放入到 AOF 文件的内核缓冲区之后什么时候写入到磁盘交由系统控制。AOF 文件重写机制因为每次执行的命令都会被写入到 AOF 文件中随着系统的运行越来越多的文件会被写入到 AOF 文件中这样 AOF 文件势必会变得很大这种情况该如何去处理呢为了解决这种情况Redis 中引入了重写的机制什么是重写呢因为 AOF 文件中记录的是每个命令的操作记录举个比如当一个键值对被多条写命令反复修改时AOF文件会记录相应的多条命令那么重写机制就是根据这个键值对当前的最新状态为它生成对应的写入命令保存成一行操作命令。这样就精简了 AOF 文件的大小。192.168.56.118:6379 set name xiaoming OK 192.168.56.118:6379 get name xiaoming 192.168.56.118:6379 set name xiaozhang OK 192.168.56.118:6379 set name xiaoli OK # 重写后就是 192.168.56.118:6379 set name xiaoli简单来讲就是多变一就是把 AOF 中日志根据当前键值的状态合并成一条操作命令。重写之后的文件会保存到新的 AOF 文件中这是旧的 AOF 文件和新的 AOF 文件中键值对应的状态是一样的。然后新的 AOF 文件会替换掉旧的 AOF 文件这样 重写操作一直在进行AOF 文件就不至于变得过大。重写是后台进行的 AOF 重写会放到子进程中进行的使用子进程的优点1、子进程处理 AOF 期间不会影响 Redis 主线程对数据的处理2、子进程拥有所在线程的数据副本子进程能够避免锁的使用保证数据的安全。这里来看下AOF 的处理流程AOF 重写也有一个缓冲区当服务节接收到新的命令的时候如果在正在进行 AOF 重写命令同样也会被发送到 AOF 缓冲区的进程执行 AOF 重写的过程,服务端进程主要处理以下内容1、接收并处理客户端发送的命令2、将执行后的命令写入到 AOF 缓冲区3、将执行后的命令也写入到 AOF 重写缓冲区AOF 缓冲区和 AOF 重写缓冲区中的内容会被定期的同步到 AOF 文件和 AOF 重写文件中当子进程完成重写的时候会给父进程发送一个信号这时候父进程主要主要进行下面的两步操作1、将 AOF 重写缓冲区中的内容全部写入到 AOF 重写文件中这时候重写 AOF 文件保存的数据状态是和服务端数据库的状态一致的2、将 AOF 重写文件替换旧的 AOF 文件通过 AOF 的重写操作新的 AOF 文件不断的替换旧的 AOF 文件这样就能控制 AOF 文件的大小AOF 的数据还原AOF 文件包了重建数据库索引锁需要的全部命令所以只需要读入并重新执行一遍 AOF 文件中保存的命令即可还原服务关闭之前数据库的状态。RDB 持久化什么是 RDB 持久化RDB(Redis database)实现方式是将存在 Redis 内存中的数据写入到 RDB 文件中保存到磁盘上从而实现持久化的。和 AOF 不同的是 RDB 保存的是数据而不是操作在进行数据恢复的时候直接把 RDB 的文件读入到内存即可完成数据恢复。RDB 如何做内存快照Redis 中对于如何备份数据到 RDB 文件中提供了两种方式1、save: 在主线程中执行不过这种会阻塞 Redis 服务进程2、bgsave: 主线程会 fork 出一个子进程来负责处理 RDB 文件的创建不会阻塞主线程的命令操作这也是 Redis 中 RDB 文件生成的默认配置对于 save 和 bgsave 这两种快照方式服务端是禁止这两种方式同时执行的防止产生竞争条件。Redis 中可以使用 save 选项来配置服务端执行 BGSAVE 命令的间隔时间# # Save the DB on disk: # # save seconds changes # # Will save the DB if both the given number of seconds and the given # number of write operations against the DB occurred. # # In the example below the behaviour will be to save: # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed # # Note: you can disable saving completely by commenting out all save lines. # # It is also possible to remove all the previously configured save # points by adding a save directive with a single empty string argument # like in the following example: # # save save 900 1 save 300 10 save 60 10000save 900 1 就是服务端在900秒读数据进行了至少1次修改就会触发一次 BGSAVE 命令save 300 10 就是服务端在300秒读数据进行了至少10次修改就会触发一次 BGSAVE 命令快照时发生数据修改举个栗子我们在t时刻开始对内存数据内进行快照假定目前有 2GB 的数据需要同步磁盘写入的速度是 0.1GB/s 那么快照的时间就是 20s那就是在 t20s 完成快照。如果在 t6s 的时候修改一个还没有写入磁盘的内存数据 test 为 test-hello。那么就会破坏快照的完整性了因为 t 时刻备份的数据已经被修改了。当然是希望在备份期间数据不能被修改。如果不能被修改就意味这在快照期间不能对数据进行修改操作就如上面的栗子快照需要进行20s,期间不允许处理数据更新操作这显然也是不合理的。这里需要聊一下 bgsave 是可以避免阻塞不过需要注意的是避免阻塞和正常读写操作是有区别的。避免阻塞主线程确实没有阻塞可以处理读操作但是为了保护快照的完整性是不能修改快照期间的数据的。这里就需要引入一种新的处理方案写时复制技术Copy-On-Write, COW在执行快照的同时正常处理写操作。bgsave 子进程是由主线程 fork 生成的所以是可以共享主线程的内存的bgsave子进程运行后会读取主线程中的内存数据并且写入到 RDB 文件中。写复制技术就是如果主线程在内存快照期间修改了一块内存那么这块内存会被复制一份生成该数据的副本然后 bgsave 子进程在把这段内存写入到 RDB 文件中。这样就可以在快照期间进行数据的修改了。多久做一次快照对于快照如果做的太频繁可能会出现前一次快照还没有处理完成后面的快照数据马上就进来了同时过于频繁的快照也会增加磁盘的压力。如果间隔时间过久服务器在两次快照期间宕机丢失的数据大小会随着快照间隔时间的增长而增加。是否可以选择增量式快照呢选择增量式快照我们就需要记住每个键值对的状态如果键值对很多同样也会引入很多内存空间这对于内存资源宝贵的Redis来说有些得不偿失。相较于 AOF 来对比RDB 是会在数据恢复时速度更快。但是 RDB 的内存快照同步频率不太好控制过多过少都有问题。Redis 4.0中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说内存快照以一定的频率执行在两次快照之间使用AOF日志记录这期间的所有命令操作。通过混合使用AOF日志和内存快照的方法RDB 快照的频率不需要过于频繁在两次 RDB 快照期间使用 AOF 日志来记录这样也不用考虑 AOF 的文件过大问题在下一次 RDB 快照开始的时候就可以删除 AOF 文件了。过期的键如何持久化在生成 RDB 文件的过程中如果一个键已经过期那么其不会被保存到 RDB 文件中。在载入 RDB 的时候要分两种情况1、如果 Redis 以主服务器的模式运行那么会对 RDB 中的键进行时间检查过期的键不会被恢复到 Redis 中。2、如果 Redis 以从服务器的模式运行那么 RDB 中所有的键都会被载入忽略时间检查。在从服务器与主服务器进行数据同步的时候从服务器的数据会先被清空所以载入过期键不会有问题。对于 AOF 来说如果一个键过期了那么不会立刻对 AOF 文件造成影响。因为 Redis 使用的是惰性删除和定期删除只有这个键被删除了才会往 AOF 文件中追加一条 DEL 命令。在重写 AOF 的过程中程序会检查数据库中的键已经过期的键不会被保存到 AOF 文件中。在运行过程中对于主从复制的 Redis主服务器和从服务器对于过期键的处理也不相同1、对于主服务器一个过期的键被删除了后会向从服务器发送 DEL 命令通知从服务器删除对应的键2、从服务器接收到读取一个键的命令时即使这个键已经过期也不会删除而是照常处理这个命令3、从服务器接收到主服务器的 DEL 命令后才会删除对应的过期键。这样保证了数据的一致性一个键值对存在于主服务器也必然存在于从服务器。总结AOF优点AOF 中有三种策略可以进行选择AOF 的默认策略为每秒钟 fsync 一次在这种配置下Redis 仍然可以保持良好的性能并且就算发生故障停机也最多只会丢失一秒钟的数据。缺点AOF 文件体积一般情况下比 RDB 文件体积大并且数据还原速度也慢于 RDB。RDB优点可以快速恢复数据相比于 AOF 的顺序逐一执行操作命令效率更高缺点因为是内存快照频率过快过慢都会有响应的问题。过快浪费磁盘资源会给磁盘造成压力过慢会存在较多数据丢失的问题。Redis 4.0中提出了一个混合使用 AOF 日志和内存快照的方法如果想要保证数据不丢失这是一个比较好的选择如果允许分钟级别的数据丢失可以只使用RDB如果只用AOF优先使用 everysec 的配置选项因为它在可靠性和性能之间取了一个平衡。