单点 Redis 的一些问题

• 数据丢失：Redis 是内存存储，服务重启可能会丢失数据。solution：实现 Redis 数据持久化。
• 并发能力：单节点 Redis 并发能力虽然不错，但也无法满足如618这样的高并发场景。solution：搭建主从集群，实现读写分离。
• 故障恢复：如果 Redis 宕机，则服务不可用，需要一种自动的故障恢复手段。solution：哨兵机制，实现健康检测及自动恢复。
• 存储能力：Redis 基于内存，单节点能存储的数据量难以满足海量数据需求。solution：搭建分片集群，利用插槽机制实现动态扩容。

Redis 持久化

• 使用缓存的时候，我们经常需要对内存中的数据进行持久化也就是将内存中的数据写入到硬盘中。大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了做数据同步（比如 Redis 集群的主从节点通过 RDB 文件同步数据）。
• Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持 3 种持久化方式：快照（snapshotting，RDB、只追加文件（append-only file, AOF）、以及RDB 和 AOF 的混合持久化（Redis 4.0 新增）。

1.RDB

• RDB 全称 Redis Database Backup file（Redis数据备份文件），也被叫做 Redis 数据快照。
• 简单来说就是把内存中某个时间点的所有数据都记录到磁盘中。当 Redis 实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为 RDB 文件，默认是保存在当前运行目录。

执行 RDB

• 谁来执行？
  • save 命令：由 Redis 主进程来执行 RDB，会阻塞所有命令。
  • bgsave 命令：开启子进程执行 RDB，避免主进程受到影响。默认选项。
    • bgsave 开始时会 fork 主进程得到子进程，子进程共享主进程的内存数据。完成 fork 后读取内存数据并写入新的 RDB 文件替换旧的。
    • fork 采用的是 copy-on-write 技术：当主进程执行读操作时，访问共享内存；当主进程执行写操作时，则会拷贝一份数据，执行写操作。
• 何时执行？
  • Redis 停机时会自动执行一次 RDB。
  • Redis 内部有触发 RDB 的机制，可以在 redis.conf 文件中找到，如：save 900 1 表示900秒内，如果至少有1个 key 被修改，则执行bgsave，
  • save "" 则表示禁用 RDB。

RDB 缺点

• RDB 执行间隔时间长，两次 RDB 之间去写入数据有丢失的风险。
• fork 子进程、压缩、写出 RDB 文件都比较耗时。

2.AOF

• AOF 全称 Append Only File（追加文件）。Redis 处理的每一个写命令，都会将该命令写入到 AOF 缓冲区中，然后再写入AOF 文件，可以看做是命令日志文件。

执行 AOF

• 执行流程？

  • 命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。
  • 文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数（系统调用），write将数据写入到了系统内核缓冲区之后直接返回了（延迟写）。注意！！！此时并没有同步到磁盘。
  • 文件同步（fsync）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
  • 文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
  • 重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。
    

• 谁来执行？

  • AOF 默认是关闭的。需要修改 redis.conf 配置文件来开启 AOF。

• 何时执行？

  • AOF 的命令记录频率也可以通过 redis.conf 文件来配置。默认每隔一秒记录一次。
    
    

AOF 自动重写功能

• AOF 重写（rewrite） 是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。
• 因为记录的是命令，AOF 文件会比 RDB 文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行 bgrewriteaof 命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
• AOF 文件重写期间，Redis 还会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。
• Redis 也会在触发阈值时自动去重写 AOF 文件。值也可以在redis.conf中配置。
  

AOF 为什么是在执行完命令之后记录日志？

• 避免额外的检查开销，AOF 记录日志不会对命令进行语法检查；
• 在命令执行完之后再记录，不会阻塞当前的命令执行。
• 这样也带来了风险：
  • 如果刚执行完命令 Redis 就宕机会导致对应的修改丢失；
  • 可能会阻塞后续其他命令的执行（AOF 记录日志是在 Redis 主线程中进行的）。

AOF 校验机制

• 纯 AOF 模式下，Redis 通过逐条解析文件中的命令来验证文件的有效性。
• 在 混合持久化模式（Redis 4.0 引入）下，AOF 文件由两部分组成：
  • RDB 快照部分：文件以固定的 REDIS 字符开头，存储某一时刻的内存数据快照，并在快照数据末尾附带一个 CRC64 校验和（位于 RDB 数据块尾部、AOF 增量部分之前）。
  • AOF 增量部分：紧随 RDB 快照部分之后，记录 RDB 快照生成后的增量写命令。这部分增量命令以 Redis 协议格式逐条记录，无整体或全局校验和。
• Redis 启动并加载 AOF 文件时，首先会校验文件开头 RDB 快照部分的数据完整性，即计算该部分数据的 CRC64 校验和，并与紧随 RDB 数据之后、AOF 增量部分之前存储的 CRC64 校验和值进行比较。如果 CRC64 校验和不匹配，Redis 将拒绝启动并报告错误。
• RDB 部分校验通过后，Redis 随后逐条解析 AOF 部分的增量命令。如果解析过程中出现错误（如不完整的命令或格式错误），Redis 会停止继续加载后续命令，并报告错误，但此时 Redis 已经成功加载了 RDB 快照部分的数据。

RDB 与 AOF

• RDB 和 AOF 各有自己的优缺点。
  
• 如何选择？
  • 如果 Redis 保存的数据丢失一些也没什么影响的话，可以选择使用 RDB。
  • 不建议单独使用 AOF，因为时不时地创建一个 RDB 快照可以进行数据库备份、更快的重启以及解决 AOF 引擎错误。
  • 如果数据要求的安全性比较高的话，建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化。