redis主从复制

Redis 主从复制是一种用于实现数据复制和数据备份的机制，它允许将一个 Redis 服务器的数据复制到其他 Redis 服务器上。主从复制在 Redis 中通常用于构建高可用性架构、读写分离以及数据分析等场景。

主从复制的角色

主服务器（Master）：主服务器是数据源，它负责处理客户端的写操作和读操作。主服务器会将自己的数据发送给从服务器，以便实现数据复制。

从服务器（Slave）：从服务器是主服务器的副本，它会复制主服务器上的数据。从服务器通常用于处理只读操作，以减轻主服务器的负担，同时也可以提供备份和故障恢复的能力。

在这里插入图片描述

命令	说明
`SLAVEOF master-ip master-port`	在从服务器上设置主服务器连接信息
`MASTERAUTH password`	在从服务器上设置主服务器的密码
`INFO replication`	检查主从复制的状态
`SLAVEOF NO ONE`	断开从服务器与主服务器的连接
`INFO clients`	在主服务器上查看从服务器信息
`INFO server`	在从服务器上查看主服务器信息

主从复制的流程

主从复制的过程大致可以分为三个阶段：

建立连接阶段：

在这个阶段，从节点需要设置主节点的地址和端口，然后向主节点发起连接请求。这可以通过以下三种方式实现：

配置文件：在从节点的配置文件中加入 slaveof masterip masterport 选项。
启动命令：在从节点启动时，使用 redis-server --slaveof masterip masterport 命令。
客户端命令：在从节点启动后，使用 slaveof masterip masterport 命令。

无论使用哪种方式，从节点都会将主节点的地址和端口保存到服务器状态的属性里面。然后，从节点会创建一个socket连接，并向主节点发送 PING 命令来检测主节点的状态。如果主节点正常响应，则继续进行身份验证（如果有设置密码）；如果超时或返回其他结果，则断开连接并重试。

身份验证是通过向主节点发送 AUTH 命令进行的，参数为配置文件中的 masterauth 的值。如果主节点设置密码的状态与从节点 masterauth 的状态一致（一致是指都存在且密码相同，或者都不存在），则身份验证通过；如果不一致，则断开连接并重试。

数据同步阶段：

在这个阶段，从节点会向主节点发送 PSYNC 命令（Redis 2.8 以前是 SYNC 命令），开始同步数据。根据从节点是否有保存主节点的复制偏移量（offset）和运行ID（runid），可以分为全量复制和部分复制两种情况：

全量复制：如果从节点是第一次连接主节点，或者从节点保存的偏移量和运行ID与主节点不匹配，那么就需要进行全量复制。
全量复制的过程：
- 主节点会执行 BGSAVE 命令来生成一个 RDB 文件，并将自己执行过的写命令缓存起来；
- 然后主节点会将 RDB 文件以及缓存的写命令发送给从节点，并向从节点返回 +FULLRESYNC [runid] [offset] 消息；
- 从节点会接收并加载 RDB 文件，并执行收到的写命令，最终达到与主节点一致的状态。
部分复制：如果从节点保存的偏移量和运行ID与主节点匹配，那么就可以进行部分复制。
部分复制的过程：
- 主节点会根据从节点提供的偏移量，发送从该偏移量之后执行过的写命令；
- 从节点会接收并执行这些写命令，最终达到与主节点一致的状态。

命令传播阶段:

在这个阶段，主节点会将自己执行的写命令实时地发送给从节点，从节点会接收并执行这些写命令，保持与主节点的数据一致性。在命令传播阶段，从节点默认会以每秒一次的频率，向主节点发送 REPLCONF ACK [offset]命令，其中 [offset] 是从节点当前的复制偏移量。

这个命令有三个作用：

检测主从服务器的网络状态。
辅助实现 min-slaves 选项。
检测命令丢失。

主从复制中三种常用模式

一主二仆

这是最简单的主从复制模式，就是一个主节点对应两个或多个从节点，从节点直接连接到主节点，接收并执行主节点发送的写命令。这种模式的优点是可以提高数据的可靠性和可用性，同时可以实现读写分离，提高读性能。缺点是如果主节点宕机，需要手动选择一个从节点来升级为主节点，并且重新配置其他从节点的连接。

假设现在我们6379端口的redis服务器是主服务器，6380端口和6381端口的redis服务器为6379服务器的从服务器。

主从复制中，如果从机中途宕机后重启，数据是否还会同步？

如果从机在复制数据过程中发生宕机并在之后重新启动，数据是否会继续同步取决于配置和具体情况。

手动配置复制关系：如果在启动过程中没有直接在从机的配置文件中定义主机（Master）信息，而是通过命令行启动并使用类似于 SLAVEOF 127.0.0.1 6379 的命令将从机连接到主机，那么在从机宕机后重新启动时，它将会以自己作为主机的状态启动，并不会自动恢复数据同步。为了使数据同步重新开始，需要再次手动执行 SLAVEOF 127.0.0.1 6379 这样的命令，将其重新设为主机的从机，以实现数据同步。
配置文件定义复制关系：如果在从机的配置文件中明确指定了主机的信息，那么在从机宕机后重新启动时，它会自动尝试连接到指定的主机并恢复数据同步。这种情况下，从机会重新以从属身份连接到主机，继续同步数据。

主从复制中，如果主机宕机，两台从机会怎么样？

主机宕机后：当主机宕机时，从机不会立即意识到主机的状态变化。它们会继续认为主机是活跃的，但是在执行命令 info replication 时，会显示主机状态为 “down”。这表示从机意识到主机无法响应。从机仍会尝试与主机保持连接，但由于主机已宕机，连接将无法建立。

主机重启后：当主机再次复活并重启后，从机会重新尝试连接到主机。如果从机的配置正确，并且主机恢复正常运行，从机会重新建立与主机的连接，并开始从主机同步数据。从机会继续将主机视为其复制源，继续按照复制规则同步数据。

需要注意的是，在主机宕机期间，从机无法从主机获取新的数据更新。当主机恢复后，从机将会努力迎头赶上，并确保与主机的数据保持同步。

薪火相传

"薪火相传"是在主从复制中一种用于构建多层级的复制拓扑结构，以分散主机的负担并实现数据同步。当有大量的从机需要与主机同步数据时，直接将所有从机连接到主机可能会对主机的性能和带宽造成压力。因此，通过构建多级复制关系，可以分散这种负担，但也会引入一些潜在的问题。

例如，如果将从机分为多级，当处于上游的从机（靠近主机）宕机时，会导致下游从机无法获取数据。这是薪火相传模型的一个缺点。以下是详细的操作步骤：

假设我们有一主机（6379）和三个从机（6380、6381、6382）。
将主机（6379）配置为主服务器，允许从机连接和复制数据。
将从机 6380 配置为连接到主机 6379 的从服务器。这样，6380 将直接与主机同步数据。
将从机 6381 配置为连接到从机 6380 的从服务器。在这一级别，6381 作为 6380 的从服务器，而 6380 本身是主机的从服务器。这样，6381 从 6380 获取数据，6380 再从主机获取数据。
同样，可以将从机 6382 配置为连接到从机 6380 的从服务器，形成更深层次的复制结构。

针对从机 6381，可以使用命令 SLAVEOF 127.0.0.1 6380 或者在配置文件 redis6381.conf 中修改 replicaof 127.0.0.1 6380，使其成为从机 6380 的从服务器。
针对从机 6382，同样可以使用类似的命令或配置来连接到 6380。

反客为主

"反客为主"指的是在主从复制中，如果主机宕机，可以让某个从机自动升级为新的主机，以保持系统的可用性。为了实现这种自动切换，引入了哨兵模式（Sentinel Mode），它能够监控主机的健康状态并在必要时自动执行主从切换操作。

哨兵模式

在哨兵模式中，一组哨兵进程负责监控主机和从机的状态。当主机宕机或发生故障时，哨兵会根据一定的规则和投票机制，自动选择一个从机作为新的主机，确保系统的高可用性。

哨兵模型选择从服务器的条件优先顺序依次为：
1、优先级靠前的（redis.conf中replica-priority 的值越小，优先级越高）
2、偏移量最大的（获得原主机数据最全的）
3、runid最小的（每个redis实例启动后都会随机生成一个40位的runid）

哨兵模式的核心目标是监控主服务器的状态并在需要时执行故障转移，其工作流程如下：

配置哨兵：在一组独立的哨兵服务器上，分别创建 sentinel.conf 配置文件，指定要监控的主服务器（mymaster）的IP和端口，配置规则等。
启动哨兵：在每个哨兵服务器上运行 redis-sentinel sentinel.conf 命令，启动哨兵进程。哨兵之间会进行通信，共同监控主服务器的状态。
监控主服务器：哨兵周期性地向主服务器发送PING命令，检测主服务器是否健康。
故障检测：如果主服务器无法响应，哨兵会将主服务器标记为“主观下线”。
投票和选举：哨兵之间进行通信，进行投票并选举出新的主服务器。多数哨兵同意后，新的主服务器被选举出来。
自动切换：哨兵将从服务器中选择一个成为新的主服务器，并更新其他从服务器以从新的主服务器同步数据。
客户端重定向：当主从切换完成后，哨兵会通知客户端进行重定向，使其连接到新的主服务器。

配置步骤：

在redis.conf同级目录下创建 sentinel.conf 配置文件，配置内容如下：

# 设置监控的主服务器名称、IP、端口和投票数
sentinel monitor mymaster 127.0.0.1 6379 2# 设置故障转移的超时时间
sentinel down-after-milliseconds mymaster 5000# 设置故障转移的最小投票数
sentinel failover-timeout mymaster 10000# 设置密码认证（如果有）
sentinel auth-pass mymaster PASSWORD

启动哨兵进程
运行以下命令启动哨兵进程：redis-sentinel sentinel.conf
监控和故障转移
哨兵会周期性地向主服务器发送PING命令，检测主服务器是否健康。如果主服务器无法响应，哨兵会根据配置的规则和投票数自动进行故障转移。一旦新的主服务器选出，其他从服务器会同步到新的主服务器。

反客为主中的故障恢复如图：
在这里插入图片描述