Redis（三）Redis集群的三种模式

---

好的，我已经为您将提供的文档整理成一篇结构清晰、带有前言和总结的博客。

---

前言

在现代分布式系统中，缓存和数据库的高可用性是保障业务稳定运行的关键。Redis 作为一款高性能的键值数据库，提供了多种集群与高可用方案来满足不同场景下的需求。了解和掌握这些模式，对于构建稳定、可扩展的应用程序至关重要。本文将系统地介绍 Redis 的三种核心服务架构：主从复制、哨兵模式以及 Cluster 集群模式，并辅以关键的搭建步骤，帮助读者深入理解其原理与实战应用。

---

一、Redis三种模式概述

Redis 群集有三种主要模式，用于实现数据冗余、高可用和分布式存储。

• 主从复制 (Replication)：这是高可用 Redis 的基础，哨兵和集群都基于此实现。它主要实现了数据的多机备份、读操作的负载均衡和简单的故障恢复。
  • 缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受单机限制。
• 哨兵模式 (Sentinel)：在主从复制的基础上，增加了自动化的故障恢复功能。
  • 缺陷：写操作无法负载均衡；存储能力受单机限制；需额外处理从节点的故障。
• 集群模式 (Cluster)：通过分布式方案，解决了写操作负载均衡和单机存储限制的问题，实现了较为完善的高可用方案。

二、Redis 主从复制模式

主从复制将一台 Redis 服务器（主节点，Master）的数据，复制到其他 Redis 服务器（从节点，Slave）。数据复制是单向的，只能从主节点到从节点。

2.1 主从复制的作用

1. 数据冗余：实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速故障恢复。
3. 负载均衡：在主从复制的基础上，配合读写分离，由主节点提供写服务，由从节点提供读服务，分担服务器负载。
4. 高可用基石：是哨兵和集群模式能够实施的基础。

2.2 主从复制流程

1. 从节点启动后，向主节点发送 SYNC 命令，请求同步连接。
2. 主节点收到命令后，启动后台进程执行 RDB 快照操作，并缓存期间的写命令。
3. 后台进程完成后，主节点将 RDB 数据文件发送给从节点。从节点将其保存到硬盘并加载到内存。
4. 主节点再将缓存的写命令发送给从节点，从节点执行这些命令以保持数据最终一致。
5. 如果从节点宕机后恢复，会自动重新连接并尝试同步。

2.3 搭建Redis主从复制

环境准备

• Master节点：192.168.10.123
• Slave1节点：192.168.10.124
• Slave2节点：192.168.10.125

操作步骤

1. 所有节点安装 Redis

   yum install -y gcc gcc-c++ make
   tar zxvf redis-5.0.7.tar.gz -C /opt/
   cd /opt/redis-5.0.7/
   make && make PREFIX=/usr/local/redis install
   cd /opt/redis-5.0.7/utils
   ./install_server.sh
   #（提示时指定可执行文件路径为 /usr/local/redis/bin/redis-server）
   ln -s /usr/local/redis/bin/* /usr/local/bin/
   

2. 配置主节点 (Master: 192.168.10.123)
   修改 /etc/redis/6379.conf：

   bind 0.0.0.0
   daemonize yes
   logfile /var/log/redis_6379.log
   dir /var/lib/redis/6379
   appendonly yes
   

   重启服务：/etc/init.d/redis_6379 restart

3. 配置从节点 (Slave1 & Slave2)
   修改 /etc/redis/6379.conf，在配置文件中添加：

   bind 0.0.0.0
   daemonize yes
   logfile /var/log/redis_6379.log
   dir /var/lib/redis/6379
   replicaof 192.168.10.123 6379  # 关键配置，指向主节点
   appendonly yes
   

   重启服务：/etc/init.d/redis_6379 restart

4. 验证主从效果
   在主节点上执行：

   tail -f /var/log/redis_6379.log # 查看日志，确认从节点连接请求
   redis-cli info replication     # 查看复制信息，应显示 connected_slaves:2
   

5. 主从复制验证

三、Redis 哨兵模式 (Sentinel)

哨兵模式在主从复制的基础上，引入了主节点的自动故障转移，解决了高可用问题。

3.1 工作原理

哨兵是一个分布式系统，用于监控主从结构中的每个服务器，并在主节点故障时通过投票机制自动选举新的主节点，并让所有从节点切换到新主节点。

3.2 哨兵的作用

1. 监控：检查主从节点是否运作正常。
2. 自动故障转移：主节点故障时，自动将一个从节点提升为新主节点。
3. 通知：将故障转移的结果告知客户端。

哨兵结构由两部分组成，哨兵节点和数据节点：节点，不存储数据。

• 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis
• 数据节点：主节点和从节点都是数据节点。

3.3 故障转移机制

每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息，那么这个哨兵就会认为这个主节点主观下线了（单方面的）。当超过半数哨兵节点认为该主节点主观下线了，这样就客观下线了。

1. 主观下线 (SDOWN)：单个哨兵认为主节点不可用。
2. 客观下线 (ODOWN)：当超过半数的哨兵节点都认为主节点不可用时，则判定为客观下线。
3. 选举Leader哨兵：当主节点出现故障，此时哨兵节点会通过Raft算法（选举算法）实现选举机制共同选举出一个哨兵节点为leader，来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。
4. 故障转移：由Leader哨兵执行：
   • 将某个从节点提升为新主节点。
   • 让其他从节点指向新主节点。
   • 通知客户端主节点已更换。
     需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

3.4 搭建Redis哨兵模式

环境：基于上文的主从复制环境。

1. 所有节点修改哨兵配置
   修改 /opt/redis-5.0.7/sentinel.conf：

   protected-mode no #17行，关闭保护模式
   port 26379 #21行，Redis哨兵默认的监听端口
   daemonize yes #26行，指定sentinel为后台启动
   logfile "/var/log/sentinel.log" #36行，指定日志存放路径
   dir "/var/lib/redis/6379" #65行，指定数据库存放路径
   sentinel monitor mymaster 192.168.10.123 6379 2 #84行，修改 指定该哨兵节点监控192.168.10.123:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
   sentinel down-after-milliseconds mymaster 30000 #113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
   sentinel failover-timeout mymaster 180000 #146行，故障节点的最大超时时间为180000（180秒）
   

2. 启动哨兵服务

   cd /opt/redis-5.0.7/
   redis-sentinel sentinel.conf &
   

3. 查看哨兵信息

   redis-cli -p 26379 info Sentinel
   

   

4. 模拟故障测试
   手动停止主节点的 Redis 进程，观察哨兵日志 /var/log/sentinel.log，会记录故障转移的全过程。再次查看哨兵信息，可以看到新的主节点地址。
   
   

四、Redis 集群模式 (Cluster)

Cluster 是 Redis 的分布式解决方案，解决了写负载均衡和单机存储限制的问题。

4.1 集群的作用

1. 数据分区：将数据分散到多个节点，突破单机内存限制，容量和并发能力大幅提升。
2. 高可用：集群支持主从复制和主节点的自动故障转移。

4.2 数据分片与哈希槽

Redis 集群通过哈希槽（Hash Slot）进行数据分片。

• 集群共有 16384 个哈希槽（0-16383）。
• 每个键通过 CRC16 校验后，对 16384 取余来决定放入哪个槽。
• 集群将哈希槽分配给不同的主节点。例如，一个三主节点的集群：
  • 节点 A： 0 - 5460
  • 节点 B：5461 - 10922
  • 节点 C：10923 - 16383

4.3 搭建Redis集群

目标：在三台机器上模拟 6 个节点（3主3从），端口号为 主6666从7777。

1. 准备节点目录和配置文件

   cd /etc/redis/
   mkdir -p redis-cluster/redis6666
   mkdir -p redis-cluster/redis7777cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6666
   cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6666cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis7777
   cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis7777
   

2. 修改每个节点的配置文件
   以 redis6666/redis.conf 为例，以下为关键配置：

   #bind 0.0.0.0  #69行，注释掉bind 项，默认监听所有网卡
   protected-mode no  #88行，修改，关闭保护模式
   port 6666  # 每个节点需改为对应端口
   daemonize yes
   cluster-enabled yes #832行，取消注释，开启群集功能
   cluster-config-file nodes-6666.conf # 每个节点不同
   cluster-node-timeout 15000 #846行，取消注释群集超时时间设置
   appendonly yes #700行，修改，开启AOF持久化
   

3. 启动所有节点

   cd /etc/redis/redis-cluster/redis6666
   redis-server redis.conf
   cd /etc/redis/redis-cluster/redis7777
   redis-server redis.conf
   

4. 组建集群
   使用 redis-cli 命令将六个节点组建为一个三主三从的集群：

   redis-cli --cluster create 192.168.10.123:6666 192.168.10.124:6666 192.168.10.125:6666 192.168.10.123:7777 192.168.10.124:7777 192.168.10.125:7777 --cluster-replicas 1
   

   输入 yes 接受最终的集群配置。
   

5. 测试集群
   

cluster keyslot 键名 #查看键名的哈希槽编号

redis-cli -h 192.168.10.123 -p 6666 CLUSTER NODES #查看集群节点的状态

---

总结

Redis 的三种集群架构各有侧重，构成了一个功能逐步增强的体系：

1. 主从复制 (Replication)：是数据冗余、读写分离和故障手动恢复的基础。它是构建更高级模式的基石，但不能实现自动化高可用。
2. 哨兵模式 (Sentinel)：在主从复制的基础上，引入了自动故障转移，解决了主节点的高可用问题。它适用于读多写少、数据量不是极大的场景，但写操作和存储容量仍然受限于单节点。
3. 集群模式 (Cluster)：是真正的分布式解决方案。它通过数据分片（Sharding）不仅实现了高可用，还解决了写负载均衡和海量数据存储的问题，是应对大数据量、高并发场景的最终方案。

在选择时，应根据业务的数据量、并发需求和可用性要求来决定：

• 若仅需数据备份和读扩展，主从复制即可。
• 若需自动化故障转移且数据量不大，哨兵模式是合适的选择。
• 若面临海量数据、高并发读写，则必须采用 Cluster 集群模式。

掌握这三种模式，意味着能够为不同规模的业务需求选择并搭建最合适的 Redis 高可用架构，从而确保服务的稳定性和高性能。