Redis 集群的三种模式：一主一从、一主多从和多主多从

---

本文记述了博主在学习 Redis 在大型项目下的使用方式，包括如何设置Redis主从节点，应对突发状况如何处理。在了解了Redis的集群搭建和相关的主从复制以及哨兵模式的知识以后，进而想要了解 Redis 集群如何使用，如何正确使用，在什么场景下使用什么样的集群模式。本文不涉及集群搭建。

---

一、各种 Redis 集群对比

Redis集群一般有以下三种常见分类：一主一从、一主多从和多主多从，其对比如下。

架构	一主一从	一主多从	多主多从
架构复杂度	最简单，一个主节点和一个从节点	较复杂，一个主节点和多个从节点	最复杂，多个主节点和从节点，分片
数据冗余	最低，两份数据	较高，多份数据	最高，多份数据，分片备份
读性能	低，一个从节点分担读请求	高，多个从节点分担读请求	高，多个从节点分担读请求
写性能	低，写操作集中在主节点	低，写操作集中在主节点	高，写操作分散到多个主节点高
可用性	最低，依赖哨兵或集群切换	较高，依赖哨兵或集群切换	最高，分片和哨兵或集群切换
配置与运维	最简单，部署成本低	较复杂，运维难度适中	最复杂，运维难度高
适用场景	小型应用、开发测试环境	读多写少的场景	大型生产环境、高并发场景

搭建集群过程中的必备技巧：

• 配置优化：合理设置复制延迟参数：根据实际业务需求，调整 repl-ping-slave-period 和 repl-timeout 等参数，以平衡复制的实时性和网络资源占用。
• 优化数据同步方式：在从节点首次连接主节点时，主节点会进行全量同步，可以通过设置 repl-diskless-sync 参数为 yes ，启用无磁盘复制，减少磁盘 I/O 操作。
• 监控主从状态：定期使用 info replication 命令查看主从复制的状态，确保从节点与主节点的连接正常，数据同步没有异常。
• 设置延迟报警：当主从复制延迟过高时，可能会对业务产生影响，可以通过监控工具设置延迟报警阈值，及时发现并解决问题。
• 定期备份主节点数据：除了依赖主从复制进行数据备份外，还应定期对主节点的数据进行全量备份，以便在出现严重故障时能够快速恢复。
• 测试备份恢复流程：定期测试备份数据的恢复流程，确保在需要时能够顺利恢复数据，避免因备份数据损坏或恢复流程不熟悉而导致数据丢失。

二、一主一从

这种集群架构较为简单，只有一个主节点和一个从节点。

• 主节点负责写操作，从节点通过复制主节点的数据来保持数据一致性。
• 数据冗余较低，只有主节点和从节点两份数据，如果主节点和从节点同时出现故障，可能会导致数据丢失。适合对数据可靠性要求不高的场景。
• 写性能主要依赖于主节点，从节点主要用于读操作，可以分担部分读负载，在高并发写操作时，可能会成为性能瓶颈。
• 如果主节点故障，从节点可以通过故障转移机制自动切换为主节点，但切换过程可能会有一定读延迟，并且在切换过程中，可能会出现短暂的服务不可用。
• 资源消耗相对较少，只需要两台服务器即可，适合资源有限的环境，部署和维护成本较低，适合小型应用或测试环境。

1、集群网络配置

主节点配置：

# redis-master.conf
bind 0.0.0.0
port 6379
daemonize yes

从节点配置：

# redis-slave.conf
bind 0.0.0.0
port 6380
daemonize yes
replicaof 127.0.0.1 6379  # 指定主节点地址
# 如果使用Redis 5.0及以上版本，slaveof 已被替换为 replicaof 。

验证主从状态：

# 在主节点查看复制信息
redis-cli -p 6379 info replication

2、主从复制原理

Redis主从复制通过异步复制实现数据的冗余备份和读写分离：

• 主节点（Master）：负责处理所有写操作，并将写命令异步传播给从节点。
• 从节点（Slave）：接收主节点的数据副本，处理读请求，支持横向扩展读性能。
• 全量同步（Full Sync）：从节点首次连接主节点时，主节点生成RDB快照并发送给从节点，从节点加载数据。
• 增量同步（Partial Sync）：后续主节点的写操作通过 replication buffer 实时同步到从节点。

3、故障转移机制（哨兵）

在Redis一主一从集群中，故障转移通常需要借助哨兵（Sentinel）机制来实现。

1、哨兵模式常见的三大步骤：

• 监控：哨兵节点定期检查主从节点的健康状态。
• 通知：当主节点故障时，哨兵节点会通过 Raft 算法选举一个领导者哨兵。
• 故障转移：领导者哨兵会选择一个从节点提升为主节点，并通知其他从节点切换到新的主节点。

2、哨兵的工作机制

• 每个哨兵节点会定期向主从节点发送心跳命令（PING）以检测其健康状态。
• 如果超过配置的 down-after-milliseconds 时间，主节点仍未响应，则哨兵会认为主节点主观下线。
• 当超过 quorum 数量的哨兵节点都认为主节点下线时，会触发故障转移。
• 哨兵节点通过 Raft 算法选举一个领导者哨兵，由领导者负责故障转移。

哨兵会监控主从节点的状态，当主节点故障时，哨兵会触发故障转移，即哨兵会根据一定的规则选举一个新的从节点晋升为主节点。

3、哨兵的选举规则

• 优先选择优先级最高的从节点（可通过slave-priority配置）。
• 若优先级相同，选择复制偏移量最大的从节点（数据最完整）。
• 若仍相同，根据节点的runID选择，runID越小说明重启次数越少。
• 最后，哨兵会更新所有从节点的配置文件，使其指向新的主节点，并通知客户端新的主节点地址。

三、一主多从

一主多从集群架构常见于大型网站的缓存服务，有一个主节点和多个从节点。这种集群的配置方式和一主一从差不多，区别就在于多了些从节点，而我们知道，从节点主要是用于读操作，主节点是用于写操作。所以这种集群方式不难看出适用于读多写少的情境中。

• 主节点负责写操作，多个从节点通过复制主节点的数据来提供读服务，可以有效分担读负载，所以适用读操作较多、写操作较少的场景。
• 数据冗余较高，主节点和多个从节点都有数据副本，即使某个从节点故障，其他从节点仍然可以提供服务，但主节点故障仍可能影响写操作，在高并发写操作时，可能会成为性能瓶颈，但不会影响到读操作。
• 哨兵或集群模式可以自动切换主节点，多个从节点提供更好的冗余，切换过程可能会有一定读延迟，短暂的切换过程可能会影响到写操作，但是不影响服务的读操作，适合对高可用性有一定要求的场景。
• 配置稍复杂，需要配置多个从节点，运维难度适中，需要监控多个从节点的状态。

1、集群网络配置

主节点配置：

# redis-master.conf
port 6379
bind 0.0.0.0
requirepass your_password  # 如果需要密码认证，设置密码

从节点1配置：

# redis-slave.conf
port 6380
bind 0.0.0.0
replicaof 127.0.0.1 6379  # 指定主节点地址
masterauth your_password      # 如果主节点设置了密码，需要配置

从节点2配置：

# redis-slave.conf
port 6381
bind 0.0.0.0
replicaof 127.0.0.1 6379  # 指定主节点地址
masterauth your_password      # 如果主节点设置了密码，需要配置

2、主从复制原理（并行机制）

Redis主从复制通过数据同步实现读写分离和数据备份，主从复制的主要方式和一主一从集群类似，例如全量同步和增量同步，有一点不同的是关于主从复制的并行机制，主节点要同时向多个从节点发送同步信息。

并行机制：当多个从节点连接到主节点时，主节点会为每个从节点维护一个独立的复制连接和状态。主节点会将写命令同时发送给所有从节点，而不是逐一发送。这种机制确保了主节点可以高效地处理多个从节点的复制请求，而不会因为从节点数量的增加而显著降低性能。

过程可以分为以下几个关键步骤，这些步骤对每个从节点都是独立进行的。

• 连接建立：从节点启动时，会根据配置文件中的 replicaof 指令连接到主节点。主节点会为每个从节点分配一个独立的复制连接。
• 全量同步和增量同步：
  • 当从节点首次连接到主节点时，主节点会生成一个RDB快照文件，并将其发送给从节点。
  • 在发送RDB文件期间，主节点会将新产生的写命令记录在复制积压缓冲区中。
  • 从节点加载RDB文件后，主节点会将复制积压缓冲区中的命令发送给从节点。
• 部分同步：
  • 如果从节点与主节点的连接短暂中断后重新连接，主节点会检查从节点的复制偏移量。
  • 如果从节点的偏移量在复制积压缓冲区的范围内，主节点会通过部分同步的方式，仅发送从节点缺失的命令，而无需重新发送整个RDB文件。
• 命令同步：主节点在处理写命令时，会将这些命令实时发送给所有从节点，从节点接收到命令后，会立即执行这些命令，以确保数据的一致性。

这里延伸到主节点如何做到同时处理多个从节点的复制请求？

• 多路复用（I/O多路复用）：Redis 使用 I/O 多路复用技术（如epoll、kqueue等），能够同时监听和处理多个从节点的连接。主节点通过事件循环机制，高效地处理来自多个从节点的复制请求。
• 复制缓冲区：主节点为每个从节点维护一个独立的复制缓冲区，用于存储发送给从节点的命令。主节点会将写命令写入每个从节点的复制缓冲区，然后通过网络发送给从节点。
• 并行发送：主节点会将写命令同时发送给所有从节点，而不是逐一发送。这种并行机制确保了主从复制的高效性，即使有多个从节点，也不会显著增加主节点的负载。

主从复制的并行机制使得主节点能够高效地处理多个从节点的复制请求。主节点的性能主要受限于网络带宽和磁盘I/O（在全量同步时）。主节点可以同时支持多个从节点，但随着从节点数量的增加，主节点的网络带宽和CPU资源可能会成为瓶颈。

实际场景中的注意事项：

• 网络延迟：如果从节点分布在不同的地理位置，网络延迟可能会影响复制的实时性。在这种情况下，可以考虑使用靠近主节点的从节点作为中间节点，进一步扩展从节点。
• 复制积压缓冲区大小：复制积压缓冲区的大小需要根据实际场景进行调整。如果缓冲区过小，可能会导致部分同步失败，从而触发全量同步。
• 故障切换：在使用哨兵模式时，哨兵会自动处理主节点故障切换。从节点会自动切换到新的主节点，继续进行复制。

3、故障转移机制（哨兵）

Redis哨兵模式是一种高可用解决方案，用于监控主从复制集群的健康状态，并在主节点故障时自动切换主节点。

哨兵节点配置文件（sentinel.conf）

# 哨兵节点配置
port 16379
sentinel monitor mymaster 127.0.0.1 6379 2      # 配置监控的主节点
sentinel down-after-milliseconds mymaster 5000  # 主节点无响应时间
sentinel failover-timeout mymaster 180000       # 故障转移超时时间
sentinel parallel-syncs mymaster 1              # 同步新主节点的从节点数量
sentinel auth-pass mymaster your_password       # 主节点密码

启动哨兵节点

redis-server /path/to/sentinel.conf --sentinel

哨兵节点会自动发现其他哨兵节点，并通过 Raft 算法进行选举，通过监控和故障转移确保集群的高可用性。

四、多主多从

多主多从集群架构常见于大型生产环境、高并发读写场景、对高可用性要求极高的场景。

• 多个主节点和多个从节点，每个主节点有一个或多个对应的从节点。每个主节点独立处理一部分数据，通过分片机制实现数据分布，从节点作为备份，提供高可用性。
• 数据冗余最高，每个主节点都有一个从节点备份，且主节点之间通过分片机制进一步提升冗余，即使某个主节点或从节点故障，其他节点仍然可以正常工作，整体可靠性最高。
• 多个从节点可以分担读请求，读性能高，写操作分散到多个主节点，适合高并发读写场景。
• 哨兵或集群模式可以自动切换主节点，且主节点之间通过分片机制进一步提升高可用性。
• 配置复杂，需要配置多个主节点和从节点，以及分片策略。
• 运维难度高，需要监控多个节点的状态，确保数据分片和故障转移的正确性。

1、集群网络配置

主节点配置：为每个主节点创建独立的配置文件，例如 redis-master1.conf 和 redis-master2.conf ，根据需要修改端口、日志路径和数据目录等配置。

port 6379  # 主节点监听端口
daemonize yes  # 后台运行
pidfile /var/run/redis-master1.pid  # 进程ID文件
logfile /var/log/redis-master1.log  # 日志文件
dir /var/lib/redis-master1  # 数据存放目录
requirepass your_password  # 设置访问密码（可选）
masterauth your_password  # 设置主从复制时的密码（如果需要）

从节点配置：为每个从节点创建独立的配置文件，例如 redis-slave1.conf 和 redis-slave2.conf ，根据需要修改端口、主节点IP、日志路径和数据目录等配置。

port 6380  # 从节点监听端口
daemonize yes  # 后台运行
pidfile /var/run/redis-slave1.pid  # 进程ID文件
logfile /var/log/redis-slave1.log  # 日志文件
dir /var/lib/redis-slave1  # 数据存放目录
replicaof <master_ip> 6379  # 指定主节点的IP和端口
requirepass your_password  # 设置访问密码（如果需要）
masterauth your_password  # 设置主从复制时的密码（如果需要）

根据配置文件启动主节点和从节点，重复命令以启动其他主节点和从节点。

redis-server /path/to/redis-master1.conf
redis-server /path/to/redis-slave1.conf

使用 redis-cli 验证主从复制关系是否成功：

redis-cli -p 6379 info replication  # 查看主节点状态
redis-cli -p 6380 info replication  # 查看从节点状态

主节点应显示为 master ，从节点应显示为 slave 。

2、主从复制原理（异步机制）

Redis多主多从架构允许多个主节点和多个从节点同时工作。每个主节点可以有多个从节点进行数据备份，同时主节点之间也可以通过配置相互同步数据。其中，多个主节点（master）和从节点（slave）之间的复制机制是实现数据一致性和高可用性的关键。

Redis 的主从复制是异步的，主节点将数据同步到从节点，从节点可以作为备份或分担读负载。在多主多从架构中，每个主节点可以有多个从节点，主节点负责写操作，从节点通过复制主节点的数据来保持数据一致性。

在多主多从架构中，每个主节点独立运行，互不干扰。主节点之间的写操作不会直接同步，每个主节点只负责将数据同步到自己的从节点。

从节点通过以下步骤进行主从复制：

• 全量同步：从节点首次连接主节点时，主节点会生成一个 RDB 快照文件并发送给从节点，从节点加载快照文件以获取主节点的完整数据。
• 增量同步：在全量同步完成后，主节点会将后续的写操作命令通过复制缓冲区实时发送给从节点，从节点根据这些命令更新本地数据。

在多主多从架构中，从节点可以作为主节点的备份。如果主节点故障，从节点可以通过哨兵（Sentinel）或集群（Cluster）模式自动切换为主节点。哨兵模式可以监控主节点的健康状态，并在主节点故障时自动从从节点中选择一个作为新的主节点。

Redis 原生并不支持多主节点之间的直接写操作同步。多主架构通常需要第三方解决方案或自定义逻辑来处理跨主节点的数据同步问题。例如，Redis Enterprise 提供了冲突无关的复制数据类型（CRDTs），允许跨地理分布的多主部署。

注意事项：

• 数据一致性：在多主架构中，需要特别注意数据一致性问题，尤其是在跨主节点同步数据时。
• 冲突处理：多主架构中可能会出现写冲突，需要通过冲突解决机制（如 CRDTs）来处理。
• 配置管理：确保主从节点的配置正确，并定期检查复制状态以确保数据同步正常。

3、故障转移机制（哨兵）

哨兵模式用于监控主从节点的状态，并在主节点故障时自动进行故障转移。

哨兵节点配置文件（sentinel.conf）

port 16379  # 哨兵节点监听端口
sentinel monitor mymaster <master_ip> 6379 2  # 监控主节点
sentinel down-after-milliseconds mymaster 5000  # 判定主节点失联的毫秒数
sentinel failover-timeout mymaster 60000  # 故障转移超时时间
sentinel parallel-syncs mymaster 1  # 同步新主节点的从节点数量
sentinel auth-pass mymaster your_password  # 主节点密码（如果需要）

根据需要配置多个主节点的监控。

启动哨兵节点：

redis-sentinel /path/to/sentinel.conf

在多主多从集群中，每个主节点都需要一个哨兵监控配置。

4、多主多从注意事项

在大型项目中使用 Redis 多主多从架构时，需要注意以下关键点，以确保系统的高可用性、性能和可扩展性。

1、数据一致性与冲突管理：在多主架构中，多个主节点可以同时写入数据，这可能导致数据冲突。

• 分布式锁：在写操作前获取分布式锁，确保同一时间只有一个主节点可以修改特定数据。
• 数据分片策略：通过合理的分片策略（如一致性哈希）将数据分散到不同的主节点上，减少冲突的可能性。

2、故障转移与高可用性

• 哨兵模式（Sentinel）：使用哨兵监控主节点的健康状态，当主节点故障时自动切换到从节点。
• 确保哨兵的配置正确，避免脑裂（split-brain）问题。
• 集群模式（Cluster）：在集群模式下，Redis会自动处理故障转移。确保每个主节点至少有一个从节点，并且集群的配置正确。

3、性能优化

• 读写分离：将读操作分发到从节点，减轻主节点的负载，提升整体性能。
• 合理配置TTL：为临时数据设置合理的TTL（生存时间），避免内存浪费。
• 内存管理：监控Redis的内存使用情况，确保数据集能够完全放入内存中。
• 如果需要，可以配置数据淘汰策略。

4、部署与运维

• 节点数量与配置：至少部署三个主节点以防止网络分区问题。每个主节点应配置至少一个从节点。
• 监控与日志：使用工具如 Redis INFO 命令、Prometheus 等监控 Redis 实例的性能和健康状态。
• 网络带宽：确保网络带宽足以处理 Redis 节点之间的通信，特别是在数据同步和故障转移时。

5、数据持久化

• 根据应用需求选择合适的持久化策略（RDB、AOF或两者结合）。
• RDB适合快速恢复，但可能丢失部分数据。
• AOF更安全，但占用更多资源。

6、容量规划

• 了解数据特性：分析数据类型、大小和生命周期，合理规划内存容量。
• 负载预估：评估平均和峰值读写负载，选择合适大小的 Redis 实例，并预留扩展空间。
• 冗余与备份：通过哨兵或集群模式实现数据冗余，确保在节点故障时数据安全。

7、安全与访问控制

• SSL/TLS 加密：在节点间通信时使用 SSL/TLS 加密，确保数据传输安全。
• 访问控制：限制Redis实例的访问权限，仅允许必要的用户和服务访问。

通过遵循这些最佳实践，可以有效提升 Redis 多主多从架构在大型项目中的稳定性和性能表现。