Redis 集群

目录

简介

一、Redis 集群模式

1.1 三种集群模式对比分析

1.2 Redis Cluster 特性

二、数据分片与负载均衡原理

2.1 哈希槽分片机制

2.2 三种分片方案对比

三、实战部署

3.1 环境规划与准备

3.2 安装 Redis 服务

3.3 配置集群参数

3.4 启动服务并创建集群

四、集群管理与运维操作

4.1 基本操作与状态检查

4.2 动态扩容

4.3 节点删除与主从关系调整

五、故障处理与高可用机制

5.1 故障转移流程

5.2 多从节点选举机制

5.3 模拟主节点故障

六、常见问题与解决方案

6.1 集群创建失败：Slot 已被占用

6.2 服务启动失败：连接127.0.0.1失败

6.3 集群搭建卡住：等待节点加入

七、生产环境实践

八、总结

简介

在当今互联网高并发、海量数据的场景下，单机 Redis 已无法满足系统对性能、存储和高可用性的需求。Redis 集群作为分布式缓存的终极解决方案，通过巧妙的架构设计实现了数据分片、自动故障转移和动态扩容。本文将从原理出发，深入剖析 Redis 集群的核心机制，并通过完整的实战部署流程，带您掌握这一强大的分布式技术。

一、Redis 集群模式

1.1 三种集群模式对比分析

Redis 发展至今形成了三种典型的集群模式，每种模式都针对不同的业务需求进行了优化：

1.2 Redis Cluster 特性

Redis Cluster 作为官方推荐的分布式方案，具有以下革命性突破：

• 无中心化架构：所有节点通过 PING-PONG 机制互联，不存在单点故障
• 哈希槽分片：将数据映射到 16384 个槽位，实现自动数据分片
• 智能故障转移：基于 Raft 协议的选举机制，超过半数节点投票确认故障
• 动态扩容：支持节点在线添加与删除，自动迁移数据槽位
• 高可用性：主从复制结合自动故障转移，保证服务持续可用

二、数据分片与负载均衡原理

2.1 哈希槽分片机制

Redis Cluster 采用哈希槽（Hash Slot） 实现数据分片，这是其区别于传统分片方案的关键：

1. 槽位分配：16384 个槽位均匀分配给集群中的主节点
2. 数据路由：通过 ​​HASH_SLOT = CRC16(key) mod 16384​​ 计算目标槽位
3. 透明转发：当客户端请求非本节点槽位时，节点会返回正确节点地址

# 槽位计算示例
def calculate_slot(key):
    """计算Key对应的Redis槽位"""
    crc16 = 0
    for c in key:
        crc16 = ((crc16 >> 8) | (crc16 << 8)) & 0xffff
        crc16 ^= ord(c)
        crc16 ^= (crc16 & 0xff) >> 4
        crc16 ^= (crc16 << 12) & 0xffff
        crc16 ^= ((crc16 & 0xff) << 5) & 0xffff
    return crc16 % 16384

2.2 三种分片方案对比

Redis 支持三种分片实现方式，各有适用场景：

客户端分片

• 原理：在业务代码中实现分片逻辑，直接连接多个 Redis 实例
• 典型工具：无成熟开源方案
• 优势：无中间层开销，性能最佳
• 缺点：代码侵入性强，运维复杂，不适合中小团队

代理分片

• 原理：通过代理层接收请求并转发至目标节点
• 典型工具：Twemproxy、Codis
• 优势：业务无感知，运维方便
• 缺点：引入代理层性能损耗（约20%）

服务器端分片（Redis Cluster）

• 原理：节点自身管理分片逻辑，客户端直接连接
• 优势：官方支持，无中间层，自动故障转移
• 缺点：多Key命令限制，需要客户端支持

三、实战部署

3.1 环境规划与准备

本次部署采用 3 主 3 从的经典架构，节点规划如下：

3.2 安装 Redis 服务

在所有节点执行以下操作：

# 关闭防火墙与SELinux（生产环境建议配置安全组）
systemctl stop firewalld
setenforce 0

# 安装编译依赖
dnf -y install gcc zlib-devel tar

# 解压并编译Redis
tar xvzf redis-5.0.14.tar.gz
cd redis-5.0.14
make
make PREFIX=/usr/local/redis install

# 创建软链接方便调用
ln -s /usr/local/redis/bin/* /usr/local/bin/

# 安装服务脚本（生成配置文件与启动脚本）
cd /root/redis-5.0.14/utils
./install_server.sh

关键步骤解释：

• ​​make PREFIX​​ 指定安装路径，避免污染系统目录
• 服务脚本会在 ​​/etc/redis/​​​ 生成配置文件，在 ​​/etc/init.d/​​ 生成启动脚本
• 编译过程会优化 Redis 内核，确保最佳性能

3.3 配置集群参数

修改每个节点的 ​​/etc/redis/6379.conf​​ 配置文件：

vim /etc/redis/6379.conf

# 允许所有网络访问
bind 0.0.0.0

# 启用守护进程模式
daemonize yes

# 启用AOF持久化（根据需求选择）
appendonly yes

# 启用集群模式
cluster-enabled yes

# 集群配置文件（自动生成，无需手动修改）
cluster-config-file nodes-6379.conf

# 节点超时时间（毫秒），超过此时间认为节点宕机
cluster-node-timeout 15000

# 允许部分槽不可用（生产环境必改）
cluster-require-full-coverage no

核心参数说明：

• ​​bind 0.0.0.0​​ 允许其他节点连接，是集群通信的基础
• ​​cluster-enabled yes​​ 开启集群模式，Redis 会切换到分布式工作状态
• ​​cluster-require-full-coverage no​​ 至关重要：若设为 yes，当任一槽不可用时整个集群停止服务
• ​​cluster-node-timeout​​ 决定故障检测的灵敏度，需根据网络环境调整

3.4 启动服务并创建集群

# 重启Redis服务使配置生效
/etc/init.d/redis_6379 restart

# 检查服务启动状态
netstat -anpt | grep 6379

# 创建集群（--cluster-replicas 1 表示每个主节点配1个从节点）
redis-cli --cluster create \
  --cluster-replicas 1 \
  192.168.10.101:6379 192.168.10.102:6379 192.168.10.103:6379 \
  192.168.10.104:6379 192.168.10.105:6379 192.168.10.106:6379

集群创建原理：

1. 命令会自动分配槽位：3个主节点各负责约5461个槽
2. 从节点自动关联到主节点，形成主从复制关系
3. 节点间通过 Gossip 协议交换状态信息，构建集群拓扑

四、集群管理与运维操作

4.1 基本操作与状态检查

# 连接集群（-c 开启集群模式，支持自动重定向）
redis-cli -h 192.168.10.101 -p 6379 -c

# 查看集群节点状态
192.168.10.101:6379> cluster nodes

# 检查集群健康状态
redis-cli --cluster check 192.168.10.101:6379

# 简单读写测试
192.168.10.101:6379> set key1 value1
-> Redirected to slot [15495] at 192.168.10.103:6379
OK
192.168.10.103:6379> get key1
"value1"

4.2 动态扩容

# 假设新节点IP为192.168.10.107（已配置好集群参数）

# 方式一：通过meet命令添加（需手动指定主从关系）
redis-cli -c -p 6379 cluster meet 192.168.10.107 6379

# 方式二：使用cluster add-node（自动识别主从）
redis-cli --cluster add-node 192.168.10.107:6379 192.168.10.101:6379

# 重新分配槽位（自动均衡到新节点）
redis-cli --cluster rebalance \
  --cluster-threshold 1 \
  --cluster-use-empty-masters \
  192.168.10.101:6379

扩容关键点：

• ​​--cluster-threshold 1​​ 表示允许节点间槽位差异不超过1个
• ​​--cluster-use-empty-masters​​ 优先使用空主节点接收槽位
• 重新分片过程中数据持续可用，无需停机

4.3 节点删除与主从关系调整

# 删除节点前需先清空槽位（以192.168.10.108为例）
redis-cli -h 192.168.10.108 -p 6379
192.168.10.108:6379> flushall  # 清空数据
192.168.10.108:6379> cluster reset  # 重置集群状态

# 删除节点（需获取节点ID）
redis-cli --cluster del-node 192.168.10.108:6379 <node-id>

# 修改从节点关系（让10.108成为10.107的从节点）
redis-cli -h 192.168.10.108 -p 6379
192.168.10.108:6379> cluster replicate <10.107-node-id>

注意事项：

• 删除主节点前必须先迁移其槽位，否则会导致集群不可用
• 从节点可直接删除，主节点删除需先清空槽位
• 节点ID可通过 ​​cluster nodes​​ 命令获取

五、故障处理与高可用机制

5.1 故障转移流程

当主节点故障时，集群会按以下步骤完成故障转移：

1. 故障检测：超过半数节点认为主节点下线（FAIL状态）
2. 从节点选举：基于Raft协议，获得N/2+1票的从节点胜出
3. 角色切换：新主节点执行 ​​SLAVEOF NO ONE​​ 成为主节点
4. 槽位迁移：新主节点接管原主节点的所有槽位
5. 集群广播：通过PONG消息通知所有节点状态变更

5.2 多从节点选举机制

在多从场景下，选举过程遵循以下规则：

1. 从节点发现主节点下线，广播 CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST
2. 其他主节点收到请求后，若未投票则返回 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK
3. 从节点收集投票，当票数 ≥ (N/2 + 1) 时当选新主（N为主节点总数）
4. 若选举周期内无节点获足够票数，进入下一轮选举

5.3 模拟主节点故障

# 假设192.168.10.101主节点故障

# 模拟主节点下线（生产环境请勿直接操作）
redis-cli -h 192.168.10.101 -p 6379 shutdown

# 观察集群状态（约30秒后完成故障转移）
redis-cli --cluster check 192.168.10.102:6379

# 查看新主节点（原从节点192.168.10.104应已升级为主）
192.168.10.102:6379> cluster nodes | grep 192.168.10.104

六、常见问题与解决方案

6.1 集群创建失败：Slot 已被占用

# 错误提示
ERR Slot 0 is already busy (Redis::CommandError)

# 解决方案
# 1. 登录所有节点清空数据与集群状态
redis-cli -h <node-ip> -p 6379 flushall
redis-cli -h <node-ip> -p 6379 cluster reset

# 2. 删除集群配置文件
rm -f /var/lib/redis/6379/nodes-6379.conf

# 3. 重启服务并重新创建集群
/etc/init.d/redis_6379 restart
redis-cli --cluster create ...

6.2 服务启动失败：连接127.0.0.1失败

# 问题原因：配置文件未监听127.0.0.1，但启动脚本默认连接此地址

# 正确启动方式（使用绝对路径指定配置文件）
redis-server /etc/redis/6379.conf

# 正确关闭方式
redis-cli -h 192.168.10.101 -p 6379 shutdown

6.3 集群搭建卡住：等待节点加入

# 问题现象：创建集群时停留在 "Waiting for the cluster to join.."
# 原因：节点未正确互联

# 解决方案：在从节点手动执行meet命令
redis-cli -h 192.168.10.104 -p 6379
192.168.10.104:6379> cluster meet 192.168.10.101 6379

七、生产环境实践

1. 节点规划：

• 至少3个主节点，满足半数投票机制
• 主从节点分布在不同物理机或可用区
• 建议配置2-3个从节点提高容灾能力

1. 资源配置：

• 每个节点内存控制在10GB以内，避免大数据迁移
• CPU选择高频单核，Redis为单线程模型
• 网络带宽至少1Gbps，保障节点间通信

1. 监控告警：

• 监控指标：节点状态、内存使用率、网络延迟、槽位分布
• 告警规则：节点下线、内存使用率超80%、网络超时
• 推荐工具：Prometheus + Grafana + Redis exporter

1. 运维规范：

• 扩容/缩容前做好数据备份
• 深夜进行重大操作，减少业务影响
• 维护节点ID与IP的映射关系表

八、总结

Redis Cluster 通过哈希槽分片与自动故障转移，完美解决了单机 Redis 的三大痛点：存储限制、写操作瓶颈和手动运维成本。其无中心化架构与动态扩容能力，使其成为以下场景的首选方案：

• 高并发读写：电商秒杀、社交平台 feed 流
• 海量数据存储：用户行为分析、实时统计系统
• 高可用要求：核心业务缓存、分布式会话存储
• 弹性扩展场景：流量波动大的互联网应用

随着云原生技术的发展，Redis Cluster 与容器编排工具（如 Kubernetes）的结合将更加紧密，未来将在混合云、边缘计算等场景中发挥更大价值。掌握这一技术，不仅能提升系统架构的稳定性，更能为业务的快速发展提供坚实的底层支撑。