首页

本章讲解 redis 配置主从复制和哨兵模式

# 主从复制

主从赋值是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点 (Master)，后者称为从节点 (Slave)，数据的复制是单向的，只能由主节点到从节点。Master 以写为主，Slave 以读为主。

优点：

  • 读写分离，提高性能。
  • 主要是读多写少的场景下，可以为一个主节点安排很多个从节点，这样就能分担压力，即使挂掉一个，其他的也可以使用。

首先要启动两个 Redis 服务器，修改以下配置文件，注意这两个配置文件的端口不能一样（因为是放在一个虚拟机上跑的），我这里是 port1 = 6890 port2 = 6891 。为了方便辨认，建议把文件夹名字加上端口。

我们这里还是写一个启动脚本 start.sh ：

#!/bin/bash
./redis-master-6890/src/redis-server ./redis-master-6890/redis.conf
./redis-slave-6891/src/redis-server ./redis-slave-6891/redis.conf

修改一下执行权限： chmod u+x start.sh ，执行文件 ./start.sh 。

启动成功后连接一下：

./redis-slave-6890/src/redis-cli -p 6891

用 info replication 查看当前主从状态：

127.0.0.1:6891> info replication
# Replication
role:master		# 现在还没有指定主从服务器，两个 redis 其实都是 master
connected_slaves:0
master_replid:41fc9e87973d2d96832d3abe8485a4b13b718d00
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

我们现在登陆的就是我们希望作为从服务器的 redis，已知主服务器是 127.0.0.1 6890 ，执行以下命令：

127.0.0.1:6891> replicaof 127.0.0.1 6890
# 旧版本使用的命令是 slaveof，replicaof 是新版本

现在再用 info replication 查看试试。

127.0.0.1:6891> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6890
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
# ....

现在测试一下，在主服务器上写入，在从服务器上读取：

从节点压根就没办法进行数据插入，节点的模式为只读模式。如果从服务器想变回主服务器，执行 replicaof no one 命令。

在主节点写入一些数据后，用新的服务器作为从服务器连接，从服务器会同步主节点的数据，流程为：

  1. 从节点执行 slave ip port 命令后，从节点会保存主节点相关的地址信息。
  2. 从节点通过每秒运行的定时任务发现配置了新的主节点后，会尝试与该节点建立网络连接，专门用于接收主节点发送的复制命令。
  3. 连接成功后，第一次会将主节点的数据进行全量复制，之后采用增量复制，持续将新来的写命令同步给从节点。

当我们的主节点关闭后，从节点依然可以读取数据，但是从节点会疯狂报错。

如果不想每次都在从节点启动后使用 replicaof 配置主节点，可以在配置文件中写好主服务器是哪个，需要加入一行：

replicaof ip port
# replicaof 127.0.0.1 6890
# 你可以在配置文件里找到replica-read-only yes，表示从节点为读模式

此外，从节点也可以有从节点：

采用这种方式，优点肯定是显而易见的，但是缺点也很明显，整个传播链路一旦中途出现问题，那么就会导致后面的从节点无法及时同步。

# 哨兵模式

经过之前的学习，我们发现，实际上最关键的还是主节点，因为一旦主节点出现问题，那么整个主从系统将无法写入，因此，我们得想一个办法，处理一下主节点故障的情况。

类似 Nacos 和 Eureka，所有的服务都会被实时监控，那么只要出现问题，肯定是可以及时发现的，并且能够采取响应的补救措施，这就是我们即将介绍的哨兵：

哨兵会对所有的节点进行监控，如果发现主节点出现问题，那么会立即让从节点进行投票，选举一个新的主节点出来，这样就不会由于主节点的故障导致整个系统不可写（注意要实现这样的功能最小的系统必须是一主一从，再小的话就没有意义了）

配置时需要修改一下配置文件 (主节点）：

sentinel monitor cyan-monitor 127.0.0.1 6890 1

第一个和第二个是固定，第三个是为监控对象名称，随意，后面就是主节点的相关信息，包括 IP 地址和端口，最后一个数 x 表示 x 个哨兵（可以设置多个哨兵）认为主节点挂了，主节点就真的挂了。

服务器启动时需要加上 xx/src/redis-server xx/reids.conf --sentinel 。

在哨兵模式下，从节点连接到主节点，哨兵也能检测到这一行为。当主节点挂掉了，会选择新的主节点，所有节点的主从关系会被重新分配，就连挂掉的节点也会变成新的主节点的从节点（尽管挂掉的节点还没启动），当挂掉的节点重启时，就会自动变成从节点（如果没变，估计式卡了，等一会）。

选举规则：

  1. 首先会根据优先级进行选择，可以在配置文件中进行配置，添加 replica-priority 配置项（默认是 100），越小表示优先级越高。
  2. 如果优先级一样，那就选择偏移量最大的
  3. 要是还选不出来，那就选择 runid（启动时随机生成的）最小的。

为了避免哨兵也挂了，可以多安排几个哨兵（一个哨兵就要多启动一个 redis 服务），只需要把哨兵的配置复制一下，然后修改端口，这样就可以同时启动多个哨兵了

# 参考

https://www.cnblogs.com/fanshuyao/p/14156208.html

https://www.yuque.com/qingkongxiaguang/spring/xoapq5#002f719c