Redis持久化之RDB

RDB 即快照持久化方式，把redis当前某一时刻的数据全部存入磁盘当中。存在的问题，当redis在下一次快照执行点发生的时候崩溃，会造成数据的丢失，这是不可避免的

RDB 持久化的触发方式
  1. 手动触发 线上采用bgsave方式
  2. 自动触发 通过在redis.conf 中进行配置save m n
    例如 save 60 1000 即60秒内如果有1000次写入就进行RDB持久化

需要注意的bgsave，理论上是redis创建了一个子进程进行存储逻辑，但现实场景中，bgsave也会导致redis的系统发生停顿。取决于硬件，数据量等因素。
例如：虚拟机场景下，redis每占用一个GB内存，创建子进程会耗费200～300毫秒，

AOF 持久化

将被执行的写命令写到AOF文件的末尾，以此来记录数据的变化
AOF的执行流程：

  1. 命令追加：将Redis的写命令追加到缓冲区aof_buf
  2. 文件写入和文件同步 根据不同的同步策略将内容刷写到硬盘中
  3. 文件重写 定期重写AOF文件，达到压缩的目的

总结：通过以上学习，我们都知道，如果是单个redis的实例，不管开启哪个持久化的操作，在数据量极大的情况下，由于需要创建子进程，对redis服务的整体性能或多或少都会带来影响。因此，我们为了保证redis服务的高可用，一般会使用redis的复制特性

复制

所谓的复制功能，即横向扩展redis的性能，通过主从服务架构，减少数据丢失的风险
2.8版本以前的主从复制流程分为两步骤：

  1. 从服务器会发送Sync命令给到主服务器（RDB的形式保持一致）
  2. Sync同步完成后，会进行命令传播

注意：Sync命令是一个耗费资源的操作，所以redis有必要保证在真正有需要时才执行sync命令

新版本复制功能PSYNC

有两个模式：

  1. 完整重同步 和Sync一致
  2. 部分重同步 用于主从服务器两者断线后的同步
实现原理
概念一 复制偏移量
主从服务器会维护一套自己复制偏移量，当两边的复制偏移量不相等，则肯定是出现了断线等异常问题。那么就会考虑进行部分重同步。

redis 执行bgsave文件在哪里 redis bgsave原理_redis

概念二 复制积压缓冲区

由主服务器维护的一个固定长度先进先出FIFO队列，默认大小为1MB

  1. 复制积压缓冲区的数据结构：FIFO 先进先出的队列
  2. 主服务器再进行命令传播的时候，会同时往复制积压缓冲区中写数据
  3. 复制积压缓存区的每个字节值都会对应一个偏移量。正式有这个数据结构，给最后执行什么同步方式提供了参考依据
概念三 服务器运行ID

即每个服务器运行的时候都会存在一个运行ID，从服务器再连接上主服务器的时候，会记录下当前连接的主服务器的服务器运行ID。
当断线重连的情况下，会进行判断，重新连接的服务器是否是上一次的服务器运行ID

参考文章

redis 设计与实现第二版
redis 实战