“深入探讨Redis主从复制：原理、配置与优化“

目录

# 概念

1. 配置主从同步步骤

1.1 创建文件夹

1.2 复制配置文件

1.3 配置文件关闭

1.4 查看端口号，发现端口号存在

1.5 连接三个端口号

1.6 查看主机运行情况

1.7 让服务器变成（主机）或（从机）

1.8 实现效果

2. 主从复制（一主二仆）的特点

2.1 从服务器挂掉重启后并没有变成从机而是成为了主机

2.2 主从复制原理

2.3 薪火相传和反客为主

3. 哨兵模式（sentinel）

3.1 创建哨兵文件

3.2 配置哨兵

3.3 启动哨兵

4. 主从复制概念流程

4.1 主从复制的基本概念

4.2 主从复制的工作流程

4.3 主从复制的示例配置

4.4 参考示意图

5. 主从复制的优缺点

6. 主从复制的应用场景

---

# 概念

• 概念

  主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主；

  实现：读写分离；性能扩展；容灾快速恢复；

1. 主从复制：主机挂掉，从机不上位：
   • 这种情况通常说明缺少故障转移机制。仅靠 Redis 主从复制，不会自动进行主从切换。在没有哨兵或其他协调机制的情况下，如果主机（主节点）挂掉，从机（从节点）不会自动升级为主节点。
2. 从机挂掉重启后的行为：
   • 如果 Redis 的从节点挂掉并重启，它会尝试重新连接到当前的主节点。如果主节点仍然是原来的主节点，从节点会继续作为从节点。如果原主节点已挂掉且有故障转移机制（如 Redis Sentinel），新的主节点会替代旧主节点，从节点重启时会连接到新的主节点并同步数据。
   • 从节点（Slave）在挂掉后重启，不会自动变成主节点（Master）。它会继续作为从节点存在，并尝试重新连接并同步主节点的数据。这个行为在 Redis 主从复制和哨兵模式下均为默认行为。
3. 哨兵模式：
   • Redis Sentinel 监控主节点和从节点的状态。哨兵集群可以自动检测主节点的故障，并通过投票机制选举一个从节点作为新的主节点。同时，它们会通知其他从节点和客户端关于新主节点的信息。这实现了自动化的主从切换（即故障转移）。

1. 配置主从同步步骤

1.1 创建文件夹

1.2 复制配置文件

在三个文件中写入内容

直接复制并修改配置文件中的6379分别为6379、6380、6381（三个地方的值都修改）

1.3 配置文件关闭

1.4 查看端口号，发现端口号存在

1.5 连接三个端口号

（三个连接都是同样操作）

通过端口号连接上服务器：redis-cli -p 6379、redis-cli -p 6380 、redis-cli -p 6381

连接成功：

1.6 查看主机运行情况

查看三台主机运行情况（没有设置都是主机，没有从机）；

此时我们并没有配置谁是从服务器，都是主服务器，所以需要配置一下；

info replication ：打印主从复制的相关信息；

可以看到当前的6379服务是一个主机master；

1.7 让服务器变成（主机）或（从机）

使用命令使6380和6381变成从机；

成为某个实例的从服务器：slaveof <ip> <port>

在6380和6381上都执行：slaveof 127.0.0.1 6379 ；

成功后查看 6381 变成了slave从机：

在6379服务中查看，它是master主机：

实现一主二从：

• 此操作完成后，他们就变成了主从关系，主机通过写入时同时主机也会把数据复制到从机中，读取的时候读的是从机的信息。（主机只用写，从机只用读）
• （一主两从）代表的是主机可以写入数据的同时把数据也复制一份到他下面的从机中（从机可以有多个），从机也可以查到主机写入的值

1.8 实现效果

主机写入：

从机读取：

2. 主从复制（一主二仆）的特点

2.1 从服务器挂掉重启后并没有变成从机而是成为了主机

• 从服务器在重启后有可能会成为主服务器的情况：
  • 哨兵（Sentinel）故障转移：当主服务器（Master）宕机时，Redis Sentinel 进行故障转移（Failover），选举一个从服务器（Slave）为新的主服务器。如果该从服务器重新启动，可能会继续作为新的主服务器，尤其是在它已经被选为主服务器之前。
  • 没有正确配置从服务器：如果从服务器重启后没有正确配置为从服务器（Replica），或者在重启时无法连接到指定的主服务器，它可能会以独立的主服务器启动。

特点一：

如果又继续把他变成6379的从服务器，那么他会把他挂掉之前的数据全部一个个的复制过来。

所以当他又变成从服务器的时候，他又会有了主机复制的数据；

特点二：

当主服务器挂掉的时候，从服务器并不会上位，还是原来的从服务器；

2.2 主从复制原理

1. 当从连接上主服务器之后，从服务器向主服务发送进行数据同步消息；
2. 主服务器接到从服务器发送过来同步消息，把主服务器数据进行持久化rdb文件，把rdb文件发送从服务器，从服务器拿到rdb进行读取；
3. 每次主服务器进行写操作之后，和从服务器进行数据同步；
   • 不过从服务器只会在第一次连接主服务器的时候发起同步消息，当连接后，都是主服务器主动发起请求给从服务器，进行复制同步rbd数据；

2.3 薪火相传和反客为主

1. 薪火相传概念及缺点：

缺点：当从服务器挂掉之后，主服务器无法直接连接从机下的从机；

类似管理层职位划分，当人的数量变多了，这会变得不好管理，这时就会分出小组长去管理其他人，以此类推；

2. 反客为主：

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改；

slaveof no one ：将从机变为主机；

• 场景：

  当发布上线的服务器挂掉之后，我们程序员需要手动的去操作，执行命令，这个也需要一段时间；

• 缺点：

  手动操作；

  耗时；

3. 哨兵模式（sentinel）

• （哨兵模式与主从复制关联：当配置了哨兵之后，那么当主服务器挂掉之后，哨兵立马顶上，且哨兵也可以配置多个）

• 概念

  反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库；

3.1 创建哨兵文件

myredis是创建服务器的时候，自己创建的一个文件，里面放的是redis配置文件；

进入myredis文件，创建sentinel.conf；

3.2 配置哨兵

• 在哨兵文件中写入sentinel monitor mymaster 127.0.0.1 6379 1
• 其中mymaster为监控对象起的服务器名称，1为至少有多少个哨兵同意迁移的数据；
• 1数量代表有1个哨兵同意切换，为2就是有两个哨兵同意切换才能切换。

我如何知道哨兵有几个同意我迁移的？

        在Redis的哨兵模式中，当主节点出现故障时，哨兵会选举一个新的主节点并进行迁移。在迁移过程中，哨兵需要确保有足够的从节点同意迁移才能进行。

在默认情况下，哨兵模式中至少需要有一半以上的从节点同意迁移才能进行。这个比例可以通过配置文件中的quorum参数进行设置，默认值为2（即至少需要2个从节点同意迁移）。

如果你想要知道当前哨兵模式中有多少个从节点同意迁移，可以使用Redis的命令SENTINEL sentinels <master-name>来获取哨兵的信息。其中<master-name>是主节点的名称。

命令的返回结果中会包含一个num-slaves字段，表示有多少个从节点，以及一个num-other-sentinels字段，表示有多少个其他哨兵节点。通过计算num-slaves和num-other-sentinels的和，再与quorum进行比较，就可以知道有多少个从节点同意迁移。

3.3 启动哨兵

• 当我们的主机挂掉之后，这时候从机就可以自动上位了，这时候之前的主机，就变成了当前主机的从机了；（老主机就变成了新上位主机的从机了）
• 其它从机也隶属于当前新主机了；

• redis-sentinel sentinel.conf ：Sentinel 的启动与使用；

• 作用：

  高可用性：在 Redis 主节点失效时，自动将一个从节点提升为新的主节点，确保服务可用性。

  监控：监控 Redis 主从结构的健康状态，并在问题发生时通知管理员。

  自动修复：执行自动故障转移和配置修复，减少手动干预。

从机的优先级：

        在 Redis Sentinel 进行故障转移时，从机（slave，或 replica）的优先级影响它们被提升为主机（master）的顺序。Redis 使用一个叫做replica-priority的参数来决定哪个从机有更高的优先级。了解和配置这个优先级参数可以帮助控制从机在故障转移中的选择顺序......

4. 主从复制概念流程

        Redis 主从复制（Master-Slave Replication）是 Redis 用于实现数据分发和高可用性的核心机制。它允许一个 Redis 实例（主机，Master）自动将数据复制到一个或多个 Redis 实例（从机，Slave），从而实现读写分离和数据冗余。下面是主从复制的概念和流程的详细说明。

4.1 主从复制的基本概念

1. 主机（Master）:
   • 处理所有的写请求和修改数据的操作。
   • 将数据变更传播给从机。
2. 从机（Slave）:
   • 从主机同步数据。
   • 通常处理只读请求，减轻主机的负载。
   • 可以被配置为其他从机的主机，形成级联复制。
3. 全量复制:
   • 从机第一次连接主机或与主机数据差异过大时进行。
   • 发送整个数据快照（RDB 文件）给从机。
4. 部分复制:
   • 用于同步期间的增量数据变化。
   • 通过复制流（replication stream）将新命令发送给从机。

4.2 主从复制的工作流程

1. 配置从机:

   • 在从机的配置文件 redis.conf 中指定主机的 IP 和端口，或者使用 SLAVEOF 命令动态配置。
   • 配置文件方式: 

     replicaof 192.168.1.1 6379

   • 命令方式:

     redis-cli SLAVEOF 192.168.1.1 6379

2. 初次同步（全量复制）:

   • 从机连接主机，发送 PSYNC 命令。
   • 如果是第一次同步或主从数据差异过大，主机生成 RDB 快照。
   • 主机将 RDB 文件发送给从机。
   • 从机载入 RDB 文件以获得主机的完整数据快照。

3. 增量复制（部分复制）:

   • 主机发送从 PSYNC 开始以来的所有写操作命令（即复制流）给从机。
   • 从机将这些命令应用到本地数据中，保持与主机数据一致。

4. 复制流和心跳机制:

   • 主机持续向从机发送命令流保持数据同步。
   • 主机和从机之间定期发送 PING/PONG 命令确保连接健康。

5. 故障恢复:

   • 如果从机断开连接，在重新连接后会尝试部分同步，尽量恢复增量数据。
   • 如果部分同步失败（例如，主机的复制缓冲区数据丢失），将重新进行全量同步。

4.3 主从复制的示例配置

主机配置（master.conf）:

port 6379
# 其他主机配置

从机配置（slave.conf）:

port 6380
replicaof 127.0.0.1 6379

4.4 参考示意图

基本架构图：

5. 主从复制的优缺点

优点:

• 读写分离: 减轻主机负载，提高读性能。
• 数据冗余: 提高数据的可靠性。
• 扩展性: 通过增加从机进行水平扩展。

缺点:

• 一致性问题: 复制过程中存在延迟，可能导致短暂的不一致。
• 故障处理: 如果主机故障，需要手动或借助 Sentinel 执行故障转移。
• 复制延迟: 由于所有的写操作都是先在 Master 上操作，然后同步更新到 slave 上，所以从 Master同步到 slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。

6. 主从复制的应用场景

• 分布式缓存: 在大型分布式系统中，通过增加从机来处理高并发读请求。
• 数据备份: 通过从机进行数据异地备份，提高数据可靠性。
• 读写分离架构: 实现读写分离，提高系统整体性能和可用性。