Redis实践

一、持久化

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

• AOF增量持久化

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

执行流程

• 命令追加：将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，当然即使这样性能还是很高
  • 数据恢复比较慢，不适合做冷备

• 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持久化