前言

在《Redis进阶篇05 — 复制技术（二）Redis主从复制》这篇文章中，我们特别提到了一条：

除了可以将所有的 replica 连接到一个 master 之外，replica 与 replica 之间也是可以采用一种叫做级联式的结构进行连接，此时所有的 sub-replica 将接受与 replica 相同的数据流

经典的主从复制如下图：

当 replica 数量特别多的时候，为了减轻 master 的复制压力，replica 与 replica 之间同样可以进行复制并同步，变成类似这样的：

在《Redis进阶篇05 — 复制技术（二）Redis主从复制》这篇文章中，一主一从的相关信息如下表所示：

现在我们需要将 10.1.1.4/24 的 master 指向 10.1.1.3/24，相关信息如下表所示：

配置 Master（192.168.100.3）

Master 的 Redis 配置文件不改变，还是沿用以前修改过的配置，直接启动即可。

Shell > /usr/local/redis/bin/redis-server /usr/local/redis/config/redis.conf

Shell > /usr/local/redis/bin/redis-cli -h 192.168.100.3 -p 6379 -a MyPassword
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.100.3:6379> keys *
1) "name"
2) "product"
192.168.100.3:6379> mget name product
1) "PC"
2) "redis"

配置 Replica1（10.1.1.3）

Replica1 的 Redis 配置文件不改变，还是沿用以前修改过的配置，直接启动即可。

Shell > /usr/local/redis/bin/redis-server /usr/local/redis/config/redis.conf

Shell > /usr/local/redis/bin/redis-cli -h 10.1.1.3 -p 6379 -a "Replica1Password"
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.1.1.3:6379> keys *
1) "name"
2) "product"
10.1.1.3:6379> mget name product
1) "PC"
2) "redis"

配置 Sub-replica1（10.1.1.4）

相关操作如下所示：

# 修改主机名
Shell > hostnamectl set-hostname Sub-replica1
# 断开连接会话，使修改的主机名生效
Shell > logout

# 重新连接后查阅主机名的信息
Shell > hostnamectl
   Static hostname: Sub-replica1
         Icon name: computer-vm
           Chassis: vm
        Machine ID: f99e041b0b484d1f93b355cccd8f27a1
           Boot ID: 98326503b50045c7b4506396a23be64a
    Virtualization: vmware
  Operating System: Rocky Linux 8.9 (Green Obsidian)
       CPE OS Name: cpe:/o:rocky:rocky:8:GA
            Kernel: Linux 4.18.0-513.9.1.el8_9.x86_64
      Architecture: x86-64

# 修改配置文件
Shell > vim /usr/local/redis/config/redis.conf
...
bind 10.1.1.4
...
protected-mode no
...
daemonize yes
...
pidfile /var/run/sub-replica1_6379.pid
...
loglevel notice
logfile /usr/local/redis/logs/sub-replica1-redis.log
...
dbfilename sub-replica1-dump.rdb
...
dir /usr/local/redis/DB/
...
replicaof 10.1.1.3 6379    ← 指定 master 的ip和端口
...
masterauth Replica1Password         ← 指定认证密码
...
requirepass Sub-Replica1-Password
...
rename-command flushall ""
rename-command flushdb ""
...
appendonly yes
appendfilename "sub-replica1-appendonly.aof"
appenddirname "sub-replica1-appendonlydir"
...
aof-use-rdb-preamble yes
...

# 启动
Shell > /usr/local/redis/bin/redis-server /usr/local/redis/config/redis.conf
# 查阅日志，执行的是全量同步
Shell > cat /usr/local/redis/logs/sub-replica1-redis.log
...
1496:S 13 Dec 2023 17:55:07.816 * Connecting to MASTER 10.1.1.3:6379
1496:S 13 Dec 2023 17:55:07.818 * MASTER <-> REPLICA sync started
...
1496:S 13 Dec 2023 17:55:12.905 * Full resync from master: d7c444c91a60cf32ac6a2d3809c907c7bb13ce4b:1078
...
1496:S 13 Dec 2023 17:55:12.907 * MASTER <-> REPLICA sync: Finished with success
...

Q&A

Q：此时的 Replica1（10.1.1.3）和 Sub-replica1（10.1.1.4）能否可以写数据？

不能。

10.1.1.3:6379> set class docs
(error) READONLY You can't write against a read only replica.

10.1.1.4:6379> set version 4
(error) READONLY You can't write against a read only replica.

Q：在 Master 中写入新数据后，Sub-replica1 能否可以正常同步数据？

能。

# 在 Master 写入数据
192.168.100.3:6379> set number 100
OK

# 同步成功
10.1.1.4:6379> keys *
1) "name"
2) "number"
3) "product"

10.1.1.4:6379> info replication
# Replication
role:slave
master_host:10.1.1.3
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_read_repl_offset:2255
slave_repl_offset:2255
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:d7c444c91a60cf32ac6a2d3809c907c7bb13ce4b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2255
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1079
repl_backlog_histlen:1177

总结

在主从复制的架构中，其工作流程大致如下：

1. 各个 replica 向 master 发送 PSYNC 命令，表示要进行同步， master 校验并通过了各个 replica 的密码请求，此时就开始了复制同步的工作；
2. 在第一次初始同步时，各个 replica 需要执行全量同步，当后续的 master 写入新数据时，各个 replica 会以增量同步的方式同步数据；
3. 当整个主从同步架构正常运行时，master 会定期发送心跳 ping 数据包（默认 10 秒发送一次），以探测各个 replica 是否还是存活的状态；
4. 当某个 replica 因不可抗拒的因素导致了宕机，后续在 master 写入的数据则会在宕机 replica 恢复时重新同步；
5. 当 master 宕机后，各个 replica 需要一直等待 master 的恢复。

主从复制的优缺点总结：

优点：

• 采用异步复制，使用较低的经济成本实现部分高可用；
• 容灾备份；
• 复制是非阻塞式；
• 配置简单，实现容易。

缺点：

• 中心架构，由于所有的写操作都在 master 上，因此 replica 的机器数量不宜过多；
• 在线扩容较复杂，集群才能做到在线扩容；
• 不管是 master 故障还是 replica 故障，主从复制没有自动恢复机制，需要运维人员人工干预；
• 无数据分片机制，因此针对海量数据的存储显得有些乏力。

赞赏