Redis - 7 ( 11000 字 Redis 入门级教程 )

一：主从复制

在分布式系统中，为了解决单点故障问题，通常会将数据复制为多个副本，部署到不同的服务器上，以满足故障恢复和负载均衡的需求。Redis 也提供了数据复制功能，实现了多个 Redis 副本的数据同步。复制功能是实现高可用 Redis 的基础，哨兵模式和集群模式都是在复制功能的基础上构建的。

1.1 配置

在 Redis 的复制架构中，实例分为主节点（master）和从节点（slave）。每个从节点只能关联一个主节点，而一个主节点可以同时管理多个从节点。数据复制是单向的，仅从主节点流向从节点。配置复制的方式主要有以下三种：

以下是优化后的表述，并以符合要求的 MD 表格呈现：

1. 接下来，我们将复制 redis.conf 配置文件并重命名为 redis-slave.conf，然后将其中的 daemonize 参数修改为 yes。

# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes

2. 接下来，默认启动的 Redis 实例将作为主节点，我们将通过命令行重新启动一个 Redis 实例，作为从节点。

# ubuntu
redis-server /etc/redis/redis-slave.conf --port 6380 --slaveof 127.0.0.1 6379

3. 通过 netstat -nlpt 确保两个 Redis 均已正确启动。

[root@host ~]# netstat -nlpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      49264/redis-server
tcp        0      0 127.0.0.1:6380          0.0.0.0:*               LISTEN      272418/redis-server

4. 通过 redis-cli 可以连接主 Redis 实例，通过 redis-cli -p 6380 连接从 Redis。并且观察复制关系。

# 在 Redis 服务器 6379 上设置键值对
127.0.0.1:6379> set hello world
OK

# 获取键为 "hello" 的值
127.0.0.1:6379> get hello
"world"

# 在 Redis 服务器 6380 上获取键 "hello" 的值
127.0.0.1:6380> get hello
"world"

可以通过 info replication 命令查看复制相关的状态信息，我们先查看主节点 6379 的复制状态信息：

# 在 Redis 主节点 6379 上执行 info replication 命令，查看复制状态信息
127.0.0.1:6379> info replication

# Replication 相关信息
role:master                       # 当前节点角色为主节点
connected_slaves:1                # 已连接的从节点数量为 1

# 从节点信息 (slave0 为从节点的标识)
slave0:ip=127.0.0.1,port=6380,    # 从节点的 IP 地址和端口号
state=online,                     # 从节点当前状态为在线
offset=100,                       # 主从复制的偏移量
lag=0                             # 主从复制的延迟时间

# 主节点的复制 ID 和偏移量信息
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06   # 当前主节点的复制 ID
master_replid2:0000000000000000000000000000000000000000  # 备用复制 ID，通常未使用
master_repl_offset:100                                  # 主节点当前的复制偏移量
second_repl_offset:-1                                   # 备用复制偏移量，通常为 -1

# 复制积压缓冲区信息
repl_backlog_active:1                                   # 积压缓冲区是否激活（1 为激活）
repl_backlog_size:1048576                               # 积压缓冲区大小（字节）
repl_backlog_first_byte_offset:1                        # 积压缓冲区的第一个字节偏移量
repl_backlog_histlen:100                                # 积压缓冲区的历史长度

从节点 6380 复制状态信息：

# 在 Redis 从节点 6380 上执行 info replication 命令，查看复制状态信息
127.0.0.1:6380> info replication

# Replication 相关信息
role:slave                        # 当前节点角色为从节点
master_host:127.0.0.1             # 主节点的 IP 地址
master_port:6379                  # 主节点的端口号
master_link_status:up             # 与主节点的连接状态（up 表示正常）
master_last_io_seconds_ago:1      # 最近一次与主节点交互的时间（单位：秒）
master_sync_in_progress:0         # 主从同步是否正在进行（0 表示未进行）

# 从节点的复制状态
slave_repl_offset:170             # 从节点的复制偏移量
slave_priority:100                # 从节点的优先级（用于故障转移）
slave_read_only:1                 # 从节点是否为只读（1 表示只读）

# 从节点未连接其他从节点
connected_slaves:0                # 当前从节点未连接其他从节点

# 主节点的复制 ID 和偏移量信息
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06   # 主节点的复制 ID
master_replid2:0000000000000000000000000000000000000000  # 备用复制 ID，通常未使用
master_repl_offset:170                                  # 主节点当前的复制偏移量
second_repl_offset:-1                                   # 备用复制偏移量，通常为 -1

# 复制积压缓冲区信息
repl_backlog_active:1                                   # 积压缓冲区是否激活（1 为激活）
repl_backlog_size:1048576                               # 积压缓冲区大小（字节）
repl_backlog_first_byte_offset:1                        # 积压缓冲区的第一个字节偏移量
repl_backlog_histlen:170                                # 积压缓冲区的历史长度

1.2 断开复制

slaveof 命令不仅可以建立主从复制关系，还可以通过在从节点执行 slaveof no one 来断开与主节点的复制关系，例如在 6380 节点执行该命令后，从节点会断开与主节点的复制关系并自动晋升为主节点，同时保留原有数据，但无法再获取主节点的数据变化。此外，slaveof 命令还可用于切换数据源，通过执行 slaveof {newMasterIp} {newMasterPort}，可以将当前从节点切换到另一个主节点，完成切主操作。

1.3 拓补

Redis 的复制拓扑结构可以是单层或多层，根据复杂程度可分为以下三种类型：一主一从、一主多从以及树状主从结构。

1.3.1 ⼀主⼀从结构

一主一从结构是最简单的复制拓扑结构，主要用于在主节点宕机时由从节点提供故障转移支持。当应用写命令的并发量较高且需要数据持久化时，可仅在从节点开启 AOF，这既能保证数据安全性，又能避免持久化对主节点性能的影响。但需要注意的是，如果主节点关闭了持久化功能，为防止主节点宕机后数据丢失，应避免设置自动重启操作。

1.3.2 ⼀主多从结构

一主多从结构（星形结构）支持应用端利用多个从节点实现读写分离，适用于读占比较大的场景。通过将读命令负载均衡到不同的从节点，可以有效分担压力，同时可指定某个从节点处理耗时的读命令，以避免影响整体稳定性。然而，在写并发量较高的场景中，多个从节点会导致主节点需要多次发送写命令，从而增加主节点的负载。

1.3.3 树形主从结构

树形主从结构（分层结构）允许从节点不仅复制主节点数据，还能作为下层从节点的主节点进行进一步复制。通过引入复制中间层，可以有效降低主节点的负载和传输给从节点的数据量。例如，数据写入节点 A 后会同步到节点 B 和 C，节点 B 再将数据同步给节点 D 和 E。当主节点需要挂载多个从节点时，为避免对主节点性能的过多影响，可以采用这种分层的拓扑结构。

1.4 原理

1.4.1 复制过程

1.4.2 数据同步 psync

Redis 使用 psync 命令完成主从数据同步，分为全量复制和部分复制两种模式。命令格式为 PSYNC replicationid offset ，如果 replicationid 为 “?” 且 offset 为 -1，则表示尝试进行全量复制；如果 replicationid 和 offset 为具体数值，则表示尝试进行部分复制，replid 和 offset 共同标识一个数据集。如果两个节点的 replid 和 offset 都相同，则可以确定这两个节点上的数据完全一致。

1.4.3 psync 运行流程

从节点会发送 psync 命令给主节点，默认情况下 replid 和 offset 的值分别为 “?” 和 -1。主节点根据 psync 的参数和自身数据状态决定响应结果：如果回复 “+FULLRESYNC replid offset”，从节点需进行全量复制；如果回复 “+CONTINUE”，从节点可进行部分复制；如果回复 “-ERR”，说明主节点 Redis 版本过低，不支持 psync 命令，此时从节点需改用 sync 命令进行全量复制。需要注意的是，psync 命令无需手动执行，Redis 会在主从复制模式下自动调用，而 sync 命令会阻塞 Redis 服务器处理其他请求，但 psync 命令不会。

1.4.4 全量复制

全量复制是 Redis 最早支持的复制方式，也是主从节点首次建立复制关系时必经的阶段，但其代价较高，包括主节点执行 bgsave 的时间、RDB 文件在网络上传输的时间、从节点清空旧数据的时间以及加载 RDB 的时间。因此，对于已经拥有大量数据集的 Redis，应该尽量避免触发全量复制操作。

1.4.5 部分复制

部分复制是 Redis 为降低全量复制高开销而设计的一种优化措施，通过 psync replicationId offset 命令实现。当从节点在复制主节点时遇到网络闪断或命令丢失等异常情况时，从节点会请求主节点补发丢失的命令数据。如果主节点的复制积压缓冲区中存在这些数据，就会直接发送给从节点，从而保持主从复制的一致性。由于补发的数据通常远小于全量数据，开销也相对较小。

1.4.6 复制积压缓冲区

复制积压缓冲区是主节点上一个固定长度的队列，默认大小为 1MB。当主节点有连接的从节点时，缓冲区会被创建。主节点在响应写命令时，除了将命令发送给从节点，还会将命令写入复制积压缓冲区。由于缓冲区是一个先进先出的定长队列，它能够保存最近已复制的数据，用于支持部分复制以及补救因复制命令丢失导致的数据不一致问题。相关的缓冲区统计信息可以通过主节点的 info replication 查看。复制积压缓冲区本质上是一个基于数组实现的环形队列，缓冲区中的值相当于数组的下标。如果从节点所需的数据已经超出了主节点积压缓冲区的范围，则无法进行部分复制，只能退回到全量复制。

127.0.0.1:6379> info replication
# Replication
role:master
...
...
...
repl_backlog_active:1                // 开启复制缓冲区
repl_backlog_size:1048576            // 缓冲区最⼤⻓度
repl_backlog_first_byte_offset:7479  // 起始偏移量，计算当前缓冲区可⽤范围
repl_backlog_histlen:1048576         // 已保存数据的有效⻓度

1.4.7 实时复制

从节点在建立复制连接后，主节点会通过 TCP 长连接将接收到的修改操作持续传输给从节点，从节点根据这些操作同步修改自身数据，从而保持与主节点的数据一致性。这种长连接通过应用层实现的心跳包机制来维护连接状态。如果主节点发现从节点的通信延迟超过 repl-timeout（默认 60 秒），则会判定从节点下线并断开复制客户端连接。当从节点恢复连接后，心跳机制将继续正常运行。

二： 哨兵 Sentinel

在 Redis 的主从复制模式下，如果主节点因故障无法提供服务，需要人工进行主从切换，并通知大量客户端切换到新的主节点。这种方案对于规模较大的应用来说难以接受。为了解决这一问题，Redis 从 2.8 版本开始引入了 Redis Sentinel（哨兵）机制，用于自动化处理主从切换和故障恢复。

2.1 基本概念

2.2 主从复制的问题

Redis 的主从复制模式可以将主节点的数据变化同步到从节点，这使从节点具备两种功能。第一，从节点作为主节点的备份，当主节点因故障不可用时，从节点可以作为后备节点接替主节点，并尽量保证数据不丢失（主从复制表现为最终一致性）。第二，从节点可以分担主节点的读压力，使主节点专注于处理写请求，而将所有的读请求通过负载均衡分配到各个从节点。其中，高可用性问题（第一点）是 Redis 哨兵解决的核心问题，而存储分布式问题（第二点）则由 Redis 集群解决。

在 Redis 主从复制模式下，当主节点发生故障时，手动处理主从切换的过程较为繁琐。为了解决这一问题，Redis 提供了 Sentinel 哨兵机制，我们通过图示展示了主从复制和故障切换的整体流程。

2.3 哨兵自动恢复主节点故障

当主节点发生故障时，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用性。Redis Sentinel 采用分布式架构，由若干个 Sentinel 节点和 Redis 数据节点组成。每个 Sentinel 节点会监控数据节点和其他 Sentinel 节点的状态，当检测到某个节点不可达时，将标记为下线。如果下线的是主节点，Sentinel 节点会相互“协商”，在多数 Sentinel 节点对主节点不可达达成共识后，内部选举出一个领导节点，负责执行自动故障转移，同时将变化实时通知应用方。整个过程完全自动化，无需人工干预，Redis Sentinel 具有以下几个功能：

与主从复制模式相比，Redis Sentinel 增加了若干（建议为奇数个）Sentinel 节点，用于监控数据节点和其他 Sentinel 节点的状态。哨兵节点会定期检查所有节点的运行情况（包括数据节点和其他哨兵节点）。当主节点发生故障时，Redis Sentinel 会自动触发故障转移，其具体流程如下：

2.4 选举原理

假设当前环境包含三个哨兵节点（sentinel1、sentinel2、sentinel3）、一个主节点（redis-master）以及两个从节点（redis-slave1 和 redis-slave2）。当主节点（redis-master）发生故障时，Redis Sentinel 会自动触发一系列故障转移过程，以恢复系统的正常运行。

2.4.1 主观下线

当 redis-master 宕机时，redis-master 与三个哨兵之间的心跳包通信中断。从三个哨兵的角度来看，此时 redis-master 被认为出现了严重故障，因此三个哨兵都会将 redis-master 判定为主观下线（SDown）。

2.4.2 客观下线

当 redis-master 宕机时，哨兵节点 sentinel1、sentinel2 和 sentinel3 会通过投票对主节点的故障进行确认，当投票数达到或超过配置的法定票数 2时，redis-master 的故障被正式确认，触发客观下线（ODown）状态。

sentinel monitor redis-master 172.22.0.4 6379 2

2.4.3 选举出哨兵的 leader

当 redis-master 宕机后，哨兵需要从剩余的从节点中选出一个新的主节点。这项工作并不需要所有哨兵参与，而是通过选举产生一个领导者（leader），由该领导者负责将一个从节点升级为主节点。选举过程采用 Raft 算法，其核心原则是“先下手为强”，即率先发出拉票请求的节点更有可能成为 leader，而这一过程受网络延时的随机性影响。具体哪个哨兵节点被选为 leader 并不重要，关键是确保能顺利选出一个领导者完成任务，假定一共有三个哨兵节点 S1 S2 S3:

以下是优化后的表述，并转为 MD 表格：

2.4.4 leader 挑选出合适的 slave 成为新的 master

当某个从节点被选定为新的主节点后，leader 哨兵会指示该节点执行 slave no one 命令，将其提升为主节点，并同时指示其余的从节点重新配置，依附于这个新主节点，完成主从关系的更新。