redis第四讲 持久化

redis第四讲 持久化

• Redis 的持久化主要有两大机制，即 AOF 日志和 RDB 快照

• AOF是写后日志

• 传统数据库的日志，例如 redo log(重做日志)，记录的是修改后的数据，而 AOF 里记 录的是 Redis 收到的每一条命令，这些命令是以文本形式保存的。

• 

• 为什么写后？

  • 为了避免额外的检查开销，Redis 在向 AOF 里面记录日志的时候，并不会先去对这 些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误 的命令，Redis 在使用日志恢复数据时，就可能会出错。而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志 中。

• AOF两个风险

  • 如果 Redis 是直接用作数据库的话，此时，因为命令没有记入日志，所以就 无法用日志进行恢复了。
  • AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因 为，AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就 会导致写盘很慢，进而导致后续的操作也无法执行了

• 三种写回策略：

Always，同步写回:每个写命令执行完，立马同步地将日志写回磁盘;
Everysec，每秒写回:每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲
区，每隔一秒把缓冲区中的内容写入磁盘;
No，操作系统控制的写回:每个写命令执行完，只是先把日志写到 AOF 文件的内存缓 冲区，由操作系统决定何时将缓冲区内容写回磁盘。

AOF重写：
AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文 件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写 入。比如说，当读取了键值对“testkey”: “testvalue”之后，重写机制会记录 set testkey testvalue 这条命令。这样，当需要恢复时，可以重新执行该命令，实 现“testkey”: “testvalue”的写入。
为什么重写机制可以把日志文件变小呢? 实际上，重写机制具有“多变一”功能。所谓 的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命 令。

• AOF重写会阻塞主线程吗
  • 和 AOF 日志由主线程写回不同，重写过程是由后台线程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。
  • 一个拷贝，两处日志
    • “一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此 时，fork 会把主线程的页表拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的 最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数 据写成操作，记入重写日志。
    • “两处日志”是：
      • 因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指 正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这 个 AOF 日志的操作仍然是齐全的，可以用于恢复。
      • 而第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。重写日 志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我 们就可以用新的 AOF 文件替代旧文件了。