Redis持久化

AOF

• Redis数据会丢失么？
  redis提供三种策略来保证CAP

  1. Always： 每次写操作都写入文件。可靠性高数据不丢失。每次落盘带来的性能影响大。
  2. EvertSec: 每秒写入一次。 宕机可能丢失一秒数据
  3. NO: 将操作写入到操作系统文件缓存区。 无法得知什么时候落盘，数据丢失可能很大，但是效率提高了。

• 什么是AOF？

  1. Redis持久化日志系统。
  2. Redis采用写后日志先执行命令再写入日志。
  3. 记录的是命令如 set key value
     

• AOF怎么处理键过期的？
  AOF过期记录的是绝对时间

• AOF为什么设计成写后日志？

  1. 读取插入时无需语法检查
  2. 不阻塞当前命令

• AOF文件太大怎么办，有什么办法？

  1. 当AOF文件满足指定条件后发送重写，重写会将当前内存中数据以k-v形式写入新的AOF文件并取出原文件。以上操作就将原AOF文件中记录的多个操作更新一个KEY的内容改为了一个。
  2. fork一个子进程，拷贝主进程内存数据地址到子进程，创建一个新的AOF文件，执行重写操作。
  3. 重写期间收到新的更新请求，先在旧AOF文件中记录，再记录在主进程的AOF重写缓冲区中，这样就避免了重写期间宕机的数据丢失
     

• 重写触发时机是什么时候？

  1. auto-aof-rewrite-min-size=64mb: AOF文件到达设置大小后
  2. auto-aof-rewrite-percentage=100：比上次重写后的体量增加了100%时触发重写

• 重写时有新的更新操作怎么办？
  采用了操作系统的写实复制技术
  fock后主进程内存空间给子进程访问成为了共享内存，主进程对共享内存的键操作就可以copy一个出来给子进程读取

  1. 已存在的key: 从共享内存中拷贝数据，新申请一个内存地址存放
  2. 申请一个内存地址存放

• fork子进程时拷贝父亲进程内存信息，那么会不会超出内存上线？

  1. 子进程并不拷贝内存内存数据，而是拷贝的内存页表（虚拟内存和物理内存的映射索引表）。
  2. 主进程的内存越大fork时间越长，阻塞主线程

RDB

• 什么是RDB？

  1. 由于AOF方式需要吧日志都执行一遍，耗时较长，所以有啦RDB模式， 将某一个时刻内存数据快照存入磁盘。
  2. RDB执行的是全量快照，将内存所有数据写入磁盘
  3. Redis提供俩个命令主动执行快照save阻塞主现场bgsavefork方式执行

• RDB执行流程？

  1. bgsave方式 先fork一个字进程。
  2. 逐个读取数据写入磁盘

• RDB时数据更新怎么办？

  1. RDB fork也是使用了写实复制技术，遇到更新先copy一个副本。
  2. 子进程复制了主线程的页表，所以通过页表映射，能读到主线程的原始数据，而当有新数据写入或数据修改时，主线程会把新数据或修改后的数据写到一个新的物理内存地址上，并修改主线程自己的页表映射。所以，子进程读到的类似于原始数据的一个副本，而主线程也可以正常进行修改。

• RBD执行的频次直接影响数据丢失的数量？
  1. 是的但也不是越快越好，RDB执行也是需要时间的，频繁写入磁盘也会给系统带来压力
  2. fork操作也会阻塞主线程的

推荐使用

Redis4.0提出将AOF与RDB混合使用，流程如下：

但是这样也是有问题的：

1. AOF重写期间RDB是否可以执行?