08.主从同步-Slave

为什么使用主、从架构：

1. 单机下如果宕机，通过AOF、RDB恢复需要时间。服务会出现中断，为了高可用性
2. 单机性能存在瓶颈上限，主、从可以提升读操作的瓶颈上限，为了高性能

主、从模式特点：

• 主、从之间的数据同步操作是异步进行的，属于弱一致性（最终一致）
• 通过冗余解决可用性问题：
  • 数据冗余（每个节点都存数据）
  • 服务冗余（每个节点都可以提供读服务，不支持写）
• 冗余带来的新问题：
  • 主、从数据的一致性问题：
    • Redis提供了主从复制模式，避免数据不一致
  • 多服务的通信问题：
    • 主、从心跳监测
    • 哨兵机制
• 读、写分离：
  • 读操作：主、从都可以接收命令
  • 写操作：仅主库接收命令，执行后同步给从库

主、从首次同步流程：

1. 命令：replicaof/slaveof 主库IP PORT
2. 流程：
   • runID: 每个实例唯一id；
   • offset：表示首次复制；
   • FULLRESYNC：全量复制
   • replication buffer： 主库RDB文件生成后，收到的所有写操作存储在该buffer
   • 过程说明：
     • 第一阶段：协商
       • 从库给主库发送：psync ? -1
         • 表示要进行数据同步，因为不知道主库的runID所以设置?，且首次offset=-1
       • 主库收到psync命令，发送：FULLRESYNC runID offset
         • 告诉从库主库的ID、以及主库目前的复制进度offset
     • 第二阶段：RDB数据同步
       • 主库执行bgsave生成RDB文件，将RDB文件同步给从库
       • 从库收到RDB数据后，清空先前数据并加载收到的RDB数据
       • 从库完成加载，回复ACK给主库
     • 第三阶段：增量数据同步
       • 主库把第二阶段执行过程中，新收到的存放在replication buffer中的写命令发送给从库
       • 从库有序执行这些写命令，首次同步即完成
     • 后续：
       • 第一次主、从同步后，主、从TCP连接会一直维持着
       • 主库后续的增量数据都会通过replication buffer缓冲区，传给从库。
3. 主节点复制缓冲区 replication buffer：
   • 主库会为每个从库创建一个单独的缓冲区
   • 该缓冲区的默认大小是 32M
   • 设计的目的：确保命令的实时性、有序性、完整性和传输的可靠性(与AOF缓冲区作用相似，一个是磁盘IO、一个是网络IO)
   • 当replication buffer满了，会导致连接断开，主库删除缓存，从节点重新连接并重新开始全量复制

主、从断联后的增量同步流程：

1. 发生时机：

   • 当第一次主、从同步的TCP长连接因为网络原因中断，又重新连接时

2. 流程：

   • 过程说明：
     1. 主、从库的连接恢复
     2. 从库给主库发送 psync 自己runID offset 命令，并把自己当前的 slave_repl_offset作为offset发给主库
     3. 主库会判断自己的master_repl_offset 和 slave_repl_offset 之间的差距，如果有差距发送CONTINUE命令
     4. 主库把 master_repl_offset 和 slave_repl_offset 之间的写命令操作，同步给从库

3. repl_backlog_buffer：

• 主库只有一个repl backlog buffer
• 该缓冲区的默认大小是 1M
• 写时机：主、从首次同步完成后，主服务器进行命令传播时，开始将增量写操作写入repl_backlog_buffer，然后通过replication buffer发送
• repl_backlog_buffer 是一个环形缓冲区，写满后会覆盖写
• 覆盖写的问题：
  • 如果从库的读取速度比较慢，主库写入速度快，会导致从库还未读取的命令被主库写覆盖，这样会导致主、从库间的数据不一致，会再次触发低效的全量同步
• 覆盖写问题的优化：
  • 设置合适的repl_backlog_size
  • 所需缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小（生产速度-消费速度）
  • repl_backlog_size = 所需缓冲空间大小 * 2（做冗余）