Redis-03a1-主从

分类于
字数统计: 1,264

建立主从集群

SLAVEOF 命令可以将当前服务器转变为指定服务器的从属服务器(slave server)。注意: 从 Redis 5 起使用 REPLICAOF 替代 SLAVEOF

e.g.在从实例执行：replicaof 192.168.0.1 6379

主从间的数据同步

➤ 2.8版本之前, Redis 的主从同步分为”全量同步”和”命令传播”两个阶段

  • 当slave实例执行SLAVEOF命令时, 会向master发送SYNC命令
  • master收到命令开始执行BGSAVE, 把内存数据存为RDB格式的文件, 同时在一个缓冲区记录从当前以后的所有写命令.
  • master把RDB文件发送给slave, 然后再将缓冲区的数据发送给slave.
  • Slave写入完成, 主从数据一致, 进入传播阶段, 每当master有数据更新, 把更新的数据传播给Slave
  • 2.8版本的主从同步存在的问题: 每次从服务器发送SYNC命令都会导致主服务器执行BGSAVE, 主服务器生成和传输RDB文件的消耗巨大;

➤ 2.8版本之后的同步:

  • 完整的同步过程仍是分为”全量同步”和”命令传播”两个状态, 但并不是每次同步过程都会执行’BGSAVE 同步’的步骤, 可能直接进入’命令传播’阶段’;
  • 判断是否执行”全量同步”, 是由 “复制偏移量 Offset” / “复制积压缓冲区 ReplicationBacklog” / runnid 共同决定的
    • master/slave服务器都会存储复制偏移量, master存储的是”向从服务器发送了多少字节”, slave存储的是”从主服务器同步了多少字节”;
    • master还有一个默认1MB大小的”复制积压缓冲区“, 每次master有数据更新, 除了向slave传播, 还会向这个缓冲区写入, 缓冲区大小固定,先进先出 缓冲区存储了每个偏移量和偏移量对应的字节;
    • slave还会存储已同步的master的 run id;
  • slave 向 master 发送 PSYNC 开始同步（例如 psync runID offset，同时还包括了已同步的主实例 runnid 和 offset ）, 同时还将存储的 run id 发送给 master, 如果 runid 和 master 的不一样, 则 master 开始完整同步的第一步骤;
  • 如果 runnid一致, master开始检查 slave发来的偏移量n, 检查n+1是否在缓冲区, 如果n+1不在缓冲区内(主从复制差距大于1MB), 则开始完整同步第一个步骤;
  • master/slave同步完成, slave每秒向master发送REPLCONF ACK <replication_offset>, 其中 replication_offset 是从服务器当前的复制偏移量, 这个命令有三个作用
    • 作为主从服务器的心跳检查
    • 同步复制偏移量
    • 辅助实现 min-slaves 选项: min-slaves-to-write 3, min-slaves-max-lag 10, 这两个配置选项表示: 从服务器数量小于3, 且从服务器写入延迟大于10s, 主拒绝写入

主节点为保障数据稳定性，当从节点挂掉的数量或者延迟过高时。将会拒绝信息同步。

这里有2个参数可以进行配置调整，e.g.

min-slaves-to-write 2
min-slaves-max-lag 8

表示从节点的数量就剩余2个，或者从节点的延迟大于8秒时，主节点就会强制关闭maste功能，停止数据同步。

复制积压缓冲区（ReplicationBacklog）：

  • 复制缓冲积压区是一个先进先出的队列，用户存储 master 收集数据的命令记录。复制缓冲区的默认存储空间是1M,可以在配置文件修改 repl-backlog-size 1mb 来控制缓冲区大小；
  • 复制缓冲区存储的内容和 AOF 文件相同：

Redis复制积压缓冲区

那 repl_backlog_buffer 缓冲区具体要调整到多大呢？

估算公式：write_size_per_second * second

  • second 为从服务器断线后重新连接上主服务器所需的平均时间(以秒计算)。
  • write_size_per_second 则是主服务器平均每秒产生的写命令数据量大小。

举个例子，如果主服务器平均每秒产生 1 MB 的写命令，而从服务器断线之后平均要 5 秒才能重新连接主服务器。那么 repl_backlog_buffer 大小就不能低于 5 MB。

@ref:

主从切换

如果主实例挂掉，主从实例的切换依赖于 Sentinel（哨兵） @link:: Redis-03a2哨兵-Sentinel

主从一致性

Redis 的主/从一致性分析:

  • 非强一致性: 向 Master 进行写操作, 与”Master 向 Slave 同步数据”操作, 是异步的. 客户端向 Master 写数据并成功返回时, 不能保证 Slave 也同步了刚写入的数据, 故非强一致性;

  • 符合最终一致性: 即使主从网络断开或从宕机, 当恢复后 Slave 会采取多种策略追赶主节点的数据.

哪些情况可能导致主从不一致：

  • 主→从的广播是异步的，见上；
  • Sentinel + Master/Slave 模式下，可能产生脑裂（brain split）的问题，哨兵正在进行主从切换，但… ；
  • Cluster 模式下，