随着业务规模的增长，单机Redis面临着存储容量、计算能力和可用性等方面的瓶颈。Redis集群应运而生，为Redis提供了水平扩展能力和高可用保障。本文将深入探讨Redis集群的架构设计、工作原理及最佳实践。
Redis集群是Redis提供的分布式解决方案，具有以下特点：
- 数据自动分片（Sharding）到多个节点
- 无中心架构，去中心化的节点间通信
- 故障自动检测和自动故障转移
- 可扩展性：支持动态添加/删除节点
| 特性 | 单机Redis | Redis集群 |
|---|
| 存储容量 | 受单机内存限制 | 理论上无限制 |
| 计算能力 | 受单CPU限制 | 随节点增加线性提升 |
| 可用性 | 单点故障 | 部分节点故障不影响整体服务 |
| 部署复杂度 | 简单 | 较复杂 |
| 维护成本 | 低 | 高 |
Redis集群中的节点分为主节点（master）和从节点（replica）：
+-------------+
| Application |
+------+------+
|
+--------v--------+
| Redis Cluster |
| |
+---+---+ +------+ +------+
|Master1| |Master2| |Master3|
+---+---+ +---+--+ +---+--+
| | |
+---v---+ +---v--+ +---v--+
|Replica1| |Replica2| |Replica3|
+-------+ +-------+ +-------+
- 主节点：负责处理槽（slot）的读写请求，每个主节点负责集群槽的一个子集
- 从节点：主节点的备份，主节点故障时提升为新的主节点
- 每个节点：维护集群状态信息，参与集群消息通信
Redis集群使用哈希槽（hash slot）进行数据分片：
总槽位：16384个槽(0-16383)
Master1 <-- 槽 0-5460
Master2 <-- 槽 5461-10922
Master3 <-- 槽 10923-16383
数据映射到槽的过程：
- 对key使用CRC16算法计算哈希值
- 取模16384得到槽位
- 根据槽位确定对应的节点
HASH_SLOT = CRC16(key) mod 16384
Redis集群典型的部署拓扑是"网状结构"：
+------+ +------+ +------+
|Node 1|<-->|Node 2|<-->|Node 3|
+------+ +------+ +------+
^ ^ ^ ^ ^
| \ / | \
| \ / | \
v v v v v
+------+ +------+ +------+
|Node 4|<-->|Node 5|<-->|Node 6|
+------+ +------+ +------+
特点：
- 每个节点都与其他所有节点互联
- 使用gossip协议传播集群状态
- 无中心化设计，无单点故障
Redis集群使用Gossip协议在节点间交换以下信息：
+-------------------+
| 集群状态信息 |
|-------------------|
| 1. 节点状态 |
| 2. 槽分配信息 |
| 3. 主从关系 |
| 4. 故障检测信息 |
+-------------------+
Gossip通信方式：
- 固定间隔（通常100ms）的心跳消息
- 随机选择几个节点进行通信
- 信息在节点间逐步传播
- 最终集群状态在所有节点间达成一致
当客户端发送请求时，路由过程如下：
客户端 --> 任意Redis节点 --> 判断key属于哪个槽 -->
如果是本节点负责的槽 --> 直接处理
如果不是本节点负责的槽 --> MOVED重定向 --> 客户端访问正确节点
关键命令：
MOVED <slot> <ip>:<port> # 槽永久迁移的重定向
ASK <slot> <ip>:<port> # 槽临时迁移的重定向
Redis集群的高可用基于以下机制：
+-------------------+
| 节点A认为节点B故障 |
+-------------------+
|
v
+------------------------+ +------------------------+
| 通过Gossip扩散这个信息 | --> | 超过半数主节点认为B故障 |
+------------------------+ +------------------------+
|
v
+-------------------+
| 标记为FAIL状态 |
+-------------------+
节点标记为pfail（可能失败）和fail（确认失败）的过程：
- 节点间定期PING/PONG检测
- 如果在cluster-node-timeout内未收到PONG，标记为pfail
- 当半数以上主节点都认为某节点pfail，该节点被标记为fail
当主节点被标记为fail后：
1. 从节点发现自己的主节点已经标记为FAIL
2. 从节点向集群申请成为新的主节点(故障选举)
3. 当选的从节点执行SLAVEOF NO ONE命令
4. 新主节点通过Gossip广播自己接管了槽
5. 继续处理槽的请求
选举过程：
- 仅从节点参与投票
- 每个主节点具有一票投票权
- 当从节点获得大多数投票，当选为新主节点
- 如果选举失败，会重新开始新一轮选举
使用redis-cli工具创建集群：
# 创建3主3从的集群
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
--cluster-replicas 1
关键配置参数：
# 集群配置文件示例
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes
# 添加新的主节点
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000
# 添加从节点
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7000 --cluster-slave --cluster-master-id <master-id>
# 重新分配槽
redis-cli --cluster reshard 127.0.0.1:7000
重新分片过程：
- 指定接收槽的目标节点ID
- 指定要迁移的槽数量
- 指定源节点ID（或all）
- 系统执行迁移操作
# 删除节点
redis-cli --cluster del-node 127.0.0.1:7000 <node-id>
注意：删除主节点前需要将其负责的槽迁移出去。
# 查看集群信息
redis-cli -c -p 7000 cluster info
# 查看节点状态
redis-cli -c -p 7000 cluster nodes
# 查看槽分配
redis-cli -c -p 7000 cluster slots
# 手动故障转移
redis-cli -c -p 7000 cluster failover
# 手动设置配置纪元
redis-cli -c -p 7000 cluster set-config-epoch <epoch>
# 强制重新加载集群配置
redis-cli -c -p 7000 cluster reset
Redis集群模式下的多键操作限制：
- 多键操作（如MSET, MGET, DEL多个键）仅在键属于同一个槽时才能操作
- 事务和Lua脚本涉及的键必须在同一个槽
解决方案：使用Hash Tags强制键分配到同一槽：
# 键名中{...}内的内容用于计算槽位
user:{user1}:profile 和 user:{user1}:account
# 这两个键会被分配到同一个槽，因为槽位计算只基于"user1"
Redis集群客户端（如Jedis, Lettuce）采用智能路由：
1. 初始连接任一节点，获取槽与节点映射关系
2. 缓存槽与节点的映射表
3. 根据键计算槽，直接与对应节点通信
4. 如遇MOVED/ASK重定向，更新映射缓存
最佳实践：
- 使用支持Redis集群的客户端库
- 对所有主节点建立连接池
- 处理好重定向和连接异常
Redis集群提供的是"最终一致性"：
- 写操作只在主节点执行，异步复制到从节点
- 可能存在复制延迟，从节点数据可能滞后
- 主从切换时可能丢失最近的写操作
提高一致性的方法：
- 配置
min-replicas-to-write，确保写操作至少复制到一定数量的从节点
- 使用WAIT命令等待复制完成
- 读写分离场景下，重要数据应直接从主节点读取
# 哈希槽的平均分配很重要
Master1: 5461槽
Master2: 5461槽
Master3: 5462槽
- 每个主节点负责的槽数应该接近，避免数据倾斜
- 主节点数量建议为3的倍数，便于均匀分配16384个槽
# 设置合理的maxmemory
maxmemory 4gb
maxmemory-policy volatile-lru
- 预留30%内存给系统和Redis内部开销
- 避免触发系统交换(swap)
- 当使用Redis做缓存时，所有节点的过期策略应一致
# 配置示例
tcp-backlog 511
tcp-keepalive 300
- 调整系统内核参数(如tcp_max_syn_backlog)
- 使用足够带宽的网络，集群节点间通信量较大
- 避免将所有节点部署在单一物理机上
需求：缓存数百万商品信息，高QPS，数据量大
方案：
+-------------------------------+
| 应用层 |
+-------------------------------+
|
+-------------------------------+
| 读写分离代理层 |
+-------------------------------+
|
+-----------+------------+------+
| | | |
v v v v
+-----+ +-----+ +-----+ +-----+
|主节点| |主节点| |主节点| |主节点|
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
+--v--+ +--v--+ +--v--+ +--v--+
|从节点| |从节点| |从节点| |从节点|
+-----+ +-----+ +-----+ +-----+
实现要点：
- 使用hash tags对相关商品数据分组
- 读写分离：写主节点，读从节点
- 热点商品复制到所有节点本地缓存
- 双集群互备，容灾切换
需求：高并发计数需求，如点赞、阅读计数
方案：
# 使用Redis集群的原子递增
HINCRBY user:counters <user_id> 1
实现要点：
- 合理设计key，避免单点热点
- 使用哈希结构减少key数量
- 批量操作减少网络往返
- 定期持久化计数数据到数据库
症状：redis-cli --cluster fix命令无法解决
解决方案：
# 检查迁移状态
redis-cli -c -p 7000 cluster nodes
# 手动修复迁移中的槽
redis-cli --cluster fix <host>:<port>
症状：不同节点的cluster nodes命令输出不同
解决方案：
# 在所有主节点上执行
redis-cli -c -p <port> cluster reset soft
症状：集群分成多个无法互通的部分
解决方案：
# 防脑裂配置
cluster-require-full-coverage no
min-replicas-to-write 1
min-replicas-max-lag 10
# 在从节点上执行手动故障转移
redis-cli -c -p <slave-port> cluster failover
使用RDB文件恢复：
# 停止Redis实例
redis-cli -p <port> shutdown
# 复制备份的RDB文件到工作目录
cp dump.rdb /redis/data/
# 启动Redis实例
redis-server /path/to/redis.conf
Redis集群为大规模Redis应用提供了强大的分布式解决方案，具有以下优势：
- 可扩展性：通过增加节点线性扩展容量和性能
- 高可用性：主从复制和自动故障转移确保服务连续性
- 分布式：去中心化架构，无单点故障
然而，使用Redis集群也需要注意其局限性：
- 事务支持有限，多键操作受限
- 数据一致性模型较弱
- 运维复杂度较高
未来的发展趋势：
- Redis模块系统在集群环境下的应用
- 更强的一致性保证
- 与云原生技术的深度集成
了解Redis集群的工作原理和最佳实践，将帮助开发者构建高性能、可靠的分布式Redis系统，为大规模应用提供强大的数据支撑。