Redis③ —— 持久化

1. Redis如何实现数据不丢失？

• 为了保证内存中的数据不会丢失，Redis 实现了数据持久化的机制，这个机制会把数据存储到磁盘，这样在 Redis 重启就能够从磁盘中恢复原有的数据。
• redis有三种持久化方式：
  • AOF日志：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里；
  • RDB快照：将某一时刻的内存数据，以二进制的方式写入磁盘；
  • 混合持久化方式：集成了 AOF 和 RBD 的优点

2. AOF日志实现

• Redis 在执行完一条写操作命令后，就会把该命令以追加的方式写入到一个文件里，然后 Redis 重启时，会读取该文件记录的命令，然后逐一执行命令的方式来进行数据恢复。

2.1 为什么先执行命令，再把数据写入日志呢？

• 避免额外得检查开销
  • 执行命令时会检查语法问题，先记录可能记录错的得语法
• 不会阻塞当前写操作命令得执行
• 数据可能会丢失
• 可能阻塞其他操作
  • AOF也是再主线程执行，写磁盘过程中可能会阻塞后续操作

2.2 AOF写回策略

• 流程：
  • 执行写操作，将命令追加到 server.aof_buf 缓冲区
  • 通过 write() 系统调用，将 aof_buf 缓冲区的数据写入到 AOF 文件，此时数据并没有写入到硬盘，而是拷贝到了内核缓冲区 page cache，等待内核将数据写入硬盘
  • 具体内核缓冲区的数据什么时候写入到硬盘，由内核决定
• 对于第三步怎么写回硬盘，有3种策略
  • always：每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘
  • everysec：每隔一秒将缓冲区里的内容写回到硬盘
  • no：不由 Redis 控制写回硬盘的时机，转交给操作系统控制写回的时机

2.3 AOF过大会触发什么机制？

• 提供了AOF重写机制，来压缩AOF文件
• 在重写时，读取当前数据库中的所有键值对，然后将每一个键值对用一条命令记录到「新的 AOF 文件」，等到全部记录完后，就将新的 AOF 文件替换掉现有的 AOF 文件。
• 相当于移除了历史命令（被覆盖的命令）
• 重写AOF过程是由后台子进程bgrewriteaof完成的，避免阻塞主进程；并且使用进程不用加锁就能保证数据安全
• 触发重写机制后，主进程就会创建重写 AOF 的子进程，此时父子进程共享物理内存，重写子进程只会对这个内存进行只读

2.4 重写机制的数据一致性问题

• 如果重写AOF过程中，主进程修改了已存在的kv，会发生写时复制，这时会出现数据不一致问题
• redis设置了一个AOF重写缓冲区，当 Redis 执行完一个写命令之后，它会同时将这个写命令写入到 「AOF 缓冲区」和 「AOF 重写缓冲区」。
• 在 bgrewriteaof 子进程执行 AOF 重写期间，主进程需要执行以下三个工作：
  • 执行客户端发来的命令
  • 将执行后的写命令追加到AOF缓冲区
  • 将执行后的写命令追加到AOF重写缓冲区
• 当子进程完成AOF重写工作后，向主进程发送一条信号（异步的），主进程收到后会调用一个信号处理函数：
  • • 将 AOF 重写缓冲区中的所有内容追加到新的 AOF 的文件中，使得新旧两个 AOF 文件所保存的数据库状态一致；
  • 新的 AOF 的文件进行改名，覆盖现有的 AOF 文件。

3. RDB快照

• RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据，而 AOF 文件记录的是命令操作的日志，而不是实际的数据。
• 在 Redis 恢复数据时， RDB 恢复数据的效率会比 AOF 高些，因为直接将 RDB 文件读入内存就可以，不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。

3.1 RDB做快照时会阻塞线程吗？

• 如何生成RDB文件：
  • 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
  • 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；
• Redis 的快照是全量快照，意思是每次执行都是把内存中得所有数据都记录到磁盘中
  • 执行太频繁会对Redis性能产生影响
  • 频率太低当服务器故障时丢失的数据会更多

3.2 RDB 在执行快照的时候，数据能修改吗？

• 可以，使用写时复制技术
• 执行 bgsave 命令的时候，会通过 fork() 创建子进程，此时子进程和父进程是共享同一片内存数据的，因为创建子进程的时候，会复制父进程的页表，但是页表指向的物理内存还是一个，此时如果主线程执行读操作，则主线程和 bgsave 子进程互相不影响。
• 如果主线程执行写操作，则被修改的数据会复制一份副本，然后 bgsave 子进程会把该副本数据写入 RDB 文件，在这个过程中，主线程仍然可以直接修改原来的数据。

4. 混合持久化

• 集成了RDB数据恢复快和AOF丢失数据少的优点
• 在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。
• AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。
• 优点：
  • 前半部分是 RDB 内容，这样加载的时候速度会很快
  • 后半部分的 AOF 内容 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失
• 缺点：
  • 使得AOF可读性变差
  • 兼容性变差

5. Redis大key对持久化的影响

• 若AOF写回策略配置了Always策略，写入大key主线程会阻塞的时间比较久
• AOF 重写机制和 RDB 快照（bgsave 命令）的过程，都会分别通过 fork() 函数创建一个子进程来处理任务。会有两个阶段会导致阻塞父进程（主线程）：
  • 创建子进程的途中，由于要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长
  • 创建完子进程后，如果父进程修改了共享数据中的大 Key，就会发生写时复制，这期间会拷贝物理内存，由于大 Key 占用的物理内存会很大，那么在复制物理内存这一过程，就会比较耗时，有可能会阻塞父进程
• 如何避免大key：
  • 在设计阶段，就把大 key 拆分成一个一个小 key
  • 定时检查 Redis 是否存在大 key ，如果该大 key 是可以删除的，不要使用 DEL 命令删除，因为该命令删除过程会阻塞主线程，而是用 unlink 命令删除大 key，因为该命令的删除过程是异步的，不会阻塞主线程