一、持久化

Redis 的数据 全部存储 在 内存 中，如果 突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的 持久化机制，它会将内存中的数据库状态 保存到磁盘 中。

1.AOF增量持久化

AOF(Append Only File - 仅追加文件) 它的工作方式非常简单：每次执行 修改内存 中数据集的写操作时，都会 记录 该操作。假设 AOF 日志记录了自 Redis 实例创建以来 所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例 顺序执行所有的指令，也就是 「重放」，来恢复 Redis 当前实例的内存数据结构的状态

• AOF文件
  
  执行流程
• 命令追加：将redis的写命令追加到缓冲区aof_buf
• 文件写入和同步：根据策略 将aof_buf种的内容同步到硬盘，appendsync 参数支持always、no、everysec
• 文件重写：定期重写AOF文件，达到压缩的目的
  • 手动触发：手动执行bgrewriteaof
  • 自动触发：配置参数 auto-aof-rewrite-min-size等等

• 优点
  • AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog，当redis重启时再次执行AOF文件中的命令来恢复数据
  • 取决于AOF日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据
• 缺点
  • 一样的数据，AOF文件比RDB还要大
  • AOF开启后，Redis支持写的QPS会比RDB支持写的要低，他不是每秒都要去异步刷新一次日志嘛fsync，当然即使这样性能还是很高
  • 数据恢复比较慢，不适合做冷备

2.RDB全量持久化

是最简单的 Redis 持久性模式。当满足特定条件时，它将生成数据集的时间点快照，例如，如果先前的快照是在2分钟前创建的，并且现在已经至少有 100 次新写入，则将创建一个新的快照。此条件可以由用户配置 Redis 实例来控制，也可以在运行时修改而无需重新启动服务器。快照作为包含整个数据集的单个 .rdb 文件生成，将当前进程中的数据生成快照保存到硬盘中，当redis 重新启动时，可以读取快照文件恢复数据

操作系统多进程 COW(Copy On Write) 机制 拯救了我们。Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程 复制 了一个进程，主进程和子进程会共享内存里面的代码块和数据段

• RDB文件
  • 二进制文件
  • 会进行压缩
  • 可以通过rdbtools分析RDB文件
• 触发条件
  • 手动触发
    • 手动执行bgsave 命令会创建一个子进程，由子进程来负责创建RDB文件
    • bgsave命令执行过程中，只有fork子进程会阻塞
  • 自动触发
    • 最常见的就是在配置文件中通过save 指定sconds秒内至少发生次变化，会触发bgsave
    • 执行shutdown命令时，自动执行RDB持久化

• 优点
  • 他会生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里面的数据，这种方式，有没有觉得很适合做冷备，完整的数据运维设置定时任务，定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了
  • RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快
• 缺点
  • RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF则最多丢一秒的数据，数据完整性上高下立判
  • RDB在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，你公司在做秒杀的时候他刚好在这个时候fork了一个子进程去生成一个大快照，哦豁，出大问题

二、主从同步

三、高可用