1. Redis Cluster 集群概述Redis Cluster 是 Redis 官方提供的分布式解决方案它通过数据分片Sharding的方式将数据分散存储在多个节点上同时提供复制和故障转移功能。这种架构能够突破单机 Redis 的内存限制实现水平扩展满足大数据量和高并发场景的需求。在实际生产环境中我们经常遇到单机 Redis 无法满足业务需求的情况。比如数据量超过单机内存容量读写请求量超过单机处理能力需要更高的可用性保障Redis Cluster 通过将数据划分为 16384 个哈希槽slot并将这些槽分配给不同的节点来解决问题。每个节点负责一部分槽位客户端可以通过计算 key 的 CRC16 值来确定数据存储在哪个槽位进而找到对应的节点。提示Redis Cluster 最小需要 3 个主节点才能正常工作这是为了保证集群在部分节点故障时仍能正常运作。2. 6 节点集群搭建实战2.1 环境准备我们先准备 6 台服务器或 6 个 Redis 实例规划如下节点角色端口槽位分配范围主节点170010-5460主节点270025461-10922主节点3700310923-16383从节点17004复制主节点1从节点27005复制主节点2从节点37006复制主节点3每个 Redis 实例需要修改配置文件 redis.confport 7001 cluster-enabled yes cluster-config-file nodes-7001.conf cluster-node-timeout 5000 appendonly yes2.2 集群初始化启动所有 Redis 实例后使用 redis-cli 创建集群redis-cli --cluster create \ 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 127.0.0.1:7006 \ --cluster-replicas 1这个命令会自动将 16384 个槽平均分配给 3 个主节点并为每个主节点分配一个从节点。2.3 集群验证检查集群状态redis-cli -p 7001 cluster nodes正常输出应该显示 6 个节点包含主从关系和槽位分配信息。测试数据读写redis-cli -c -p 7001 set foo bar get foo-c 参数表示以集群模式连接客户端会自动重定向到正确的节点。3. 集群核心机制解析3.1 数据分片原理Redis Cluster 采用哈希槽slot的方式实现数据分片计算 key 的 CRC16 校验和对校验和取模 16384 得到槽位号根据槽位映射表找到对应节点这种设计有几个优势解耦数据与节点关系便于集群扩容缩容槽位数量固定重新分配成本低支持 hash tag可将相关 key 强制分配到同一节点3.2 节点通信机制集群节点间通过 Gossip 协议进行通信主要交换以下信息节点状态在线/下线槽位分配情况集群配置变化每个节点会随机选择几个其他节点定期发送 PING 消息接收方回复 PONG。这种去中心化的通信方式保证了集群信息最终一致性。3.3 故障检测与恢复Redis Cluster 的故障转移过程多个节点标记某节点为主观下线PFAIL当多数主节点确认后标记为客观下线FAIL从节点发起选举成为新主节点槽位重新分配集群恢复服务选举过程基于 Raft 算法确保只有一个从节点能升级为主节点。4. 生产环境优化建议4.1 性能调优适当增大 cluster-node-timeout默认15秒避免网络波动导致误判使用 pipeline 减少网络往返合理设置 hash tag 减少跨节点操作4.2 运维实践监控每个节点的内存使用、命中率和延迟定期执行 cluster meet 维护节点关系使用 redis-cli --cluster check 定期检查集群健康状态4.3 常见问题处理槽位分配不均redis-cli --cluster reshard 127.0.0.1:7001节点扩容redis-cli --cluster add-node 新节点IP:端口 现有节点IP:端口 redis-cli --cluster reshard 现有节点IP:端口节点下线redis-cli --cluster del-node 现有节点IP:端口 节点ID5. 集群限制与解决方案Redis Cluster 虽然强大但也有以下限制不支持多键操作除非所有 key 在同一个节点解决方案使用 hash tag 或 Lua 脚本事务仅限于单节点解决方案设计业务逻辑时考虑数据分布数据库只能使用 0 号库解决方案使用 key 前缀区分业务在实际使用中我们发现合理设计 key 的命名规则非常重要。比如使用业务前缀hash tag 的方式order:{user123}:1001 order:{user123}:1002这样可以确保同一个用户的所有订单数据都存储在同一个节点上方便进行聚合操作。 Redis Cluster集群搭建与核心机制解析
1. Redis Cluster 集群概述Redis Cluster 是 Redis 官方提供的分布式解决方案它通过数据分片Sharding的方式将数据分散存储在多个节点上同时提供复制和故障转移功能。这种架构能够突破单机 Redis 的内存限制实现水平扩展满足大数据量和高并发场景的需求。在实际生产环境中我们经常遇到单机 Redis 无法满足业务需求的情况。比如数据量超过单机内存容量读写请求量超过单机处理能力需要更高的可用性保障Redis Cluster 通过将数据划分为 16384 个哈希槽slot并将这些槽分配给不同的节点来解决问题。每个节点负责一部分槽位客户端可以通过计算 key 的 CRC16 值来确定数据存储在哪个槽位进而找到对应的节点。提示Redis Cluster 最小需要 3 个主节点才能正常工作这是为了保证集群在部分节点故障时仍能正常运作。2. 6 节点集群搭建实战2.1 环境准备我们先准备 6 台服务器或 6 个 Redis 实例规划如下节点角色端口槽位分配范围主节点170010-5460主节点270025461-10922主节点3700310923-16383从节点17004复制主节点1从节点27005复制主节点2从节点37006复制主节点3每个 Redis 实例需要修改配置文件 redis.confport 7001 cluster-enabled yes cluster-config-file nodes-7001.conf cluster-node-timeout 5000 appendonly yes2.2 集群初始化启动所有 Redis 实例后使用 redis-cli 创建集群redis-cli --cluster create \ 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 127.0.0.1:7006 \ --cluster-replicas 1这个命令会自动将 16384 个槽平均分配给 3 个主节点并为每个主节点分配一个从节点。2.3 集群验证检查集群状态redis-cli -p 7001 cluster nodes正常输出应该显示 6 个节点包含主从关系和槽位分配信息。测试数据读写redis-cli -c -p 7001 set foo bar get foo-c 参数表示以集群模式连接客户端会自动重定向到正确的节点。3. 集群核心机制解析3.1 数据分片原理Redis Cluster 采用哈希槽slot的方式实现数据分片计算 key 的 CRC16 校验和对校验和取模 16384 得到槽位号根据槽位映射表找到对应节点这种设计有几个优势解耦数据与节点关系便于集群扩容缩容槽位数量固定重新分配成本低支持 hash tag可将相关 key 强制分配到同一节点3.2 节点通信机制集群节点间通过 Gossip 协议进行通信主要交换以下信息节点状态在线/下线槽位分配情况集群配置变化每个节点会随机选择几个其他节点定期发送 PING 消息接收方回复 PONG。这种去中心化的通信方式保证了集群信息最终一致性。3.3 故障检测与恢复Redis Cluster 的故障转移过程多个节点标记某节点为主观下线PFAIL当多数主节点确认后标记为客观下线FAIL从节点发起选举成为新主节点槽位重新分配集群恢复服务选举过程基于 Raft 算法确保只有一个从节点能升级为主节点。4. 生产环境优化建议4.1 性能调优适当增大 cluster-node-timeout默认15秒避免网络波动导致误判使用 pipeline 减少网络往返合理设置 hash tag 减少跨节点操作4.2 运维实践监控每个节点的内存使用、命中率和延迟定期执行 cluster meet 维护节点关系使用 redis-cli --cluster check 定期检查集群健康状态4.3 常见问题处理槽位分配不均redis-cli --cluster reshard 127.0.0.1:7001节点扩容redis-cli --cluster add-node 新节点IP:端口 现有节点IP:端口 redis-cli --cluster reshard 现有节点IP:端口节点下线redis-cli --cluster del-node 现有节点IP:端口 节点ID5. 集群限制与解决方案Redis Cluster 虽然强大但也有以下限制不支持多键操作除非所有 key 在同一个节点解决方案使用 hash tag 或 Lua 脚本事务仅限于单节点解决方案设计业务逻辑时考虑数据分布数据库只能使用 0 号库解决方案使用 key 前缀区分业务在实际使用中我们发现合理设计 key 的命名规则非常重要。比如使用业务前缀hash tag 的方式order:{user123}:1001 order:{user123}:1002这样可以确保同一个用户的所有订单数据都存储在同一个节点上方便进行聚合操作。