redis集群实战（3主3从）-程序员充电站

redis集群实战（3主3从）

Redis 集群（Cluster）是 Redis 3.0+ 官方推出的分布式解决方案，核心是数据分片（Sharding）+ 主从复制 + 去中心化故障转移，解决单机 Redis 的容量、性能、单点故障瓶颈，实现水平扩展、高可用、高并发。

一、核心概念

基本定义
Redis 集群是无中心架构的分布式系统，数据自动分散到多个节点，每个节点只存部分数据；节点间通过 Gossip 协议通信，自带故障转移，无需 Sentinel。
关键角色

主节点（Master）：处理读写、管理哈希槽、参与故障投票，是核心节点。从节点（Replica/Slave）：异步复制主节点数据，默认只读；主节点宕机时自动选举晋升为主。哈希槽（Hash Slot）：集群固定 16384 个槽（0~16383），是数据分片的最小单位。

节点 ID：每个节点唯一标识，用于集群内识别与通信。

核心特性

数据分片：突破单机内存限制，总容量 = 所有主节点内存之和。

高可用：部分节点故障不影响整体，自动故障转移。

线性扩展：加节点即可提升容量与并发。

去中心化：无中心节点，避免单点瓶颈。自动路由：客户端连接任意节点，自动重定向到目标节点。

二、工作原理

数据分片（哈希槽机制）

槽位总数：16384（2¹⁴）。键 → 槽映射

节点通信（Gossip 协议）

节点间通过集群总线（独立端口，默认 + 10000）通信。消息类型：

PING/PONG：心跳检测、状态同步。 FAIL：广播节点失效。 UPDATE：槽位映射、集群拓扑更新。

请求路由流程

客户端连接任意节点，发送命令。

节点计算 key 所属槽位。
槽位归属本节点 → 直接处理；否则 → 返回 MOVED 重定向。
1. 智能客户端缓存槽位映射，减少重定向。
故障转移（高可用）

故障检测：某主节点超时无响应，多数主节点标记为 FAIL 。

从节点选举：该主节点的从节点发起 FAILOVER 请求。

投票晋升：主节点投票通过，从节点升级为主，接管槽位。
拓扑更新：Gossip 同步新状态，集群恢复。
数据一致性

异步复制：主从复制异步，存在短暂数据不一致。

最终一致性：故障转移后数据最终一致，不保证强一致。

写安全：多数主节点可达时，写操作尽量保留。

操作步骤（3 主 3 从实战）

cluster集群是Redis从3.0版本开始支持，自带的一种集群方式。它的原理使用了分布的思想，其数据会均分到所有的主节点上。此部署方式，当数据量过大时，会让服务器均摊压力。在各个主节点上分配的数据都不是全量的。是分片存储的。目前此种部署方式在生产环境的较多。至少六台，三台主，三台从。

目的：同时解决高可用、海量数据存储和高并发读写的问题，即分布式扩展。

原理：Redis Cluster 是 Redis 官方提供的分布式数据库解决方案。它通过数据分片 (Sharding) 进行数据存储，并通过多主多从架构来实现高可用。

准备6台安装了redis的虚拟机同时操作：关闭防火墙，修改配置文件

系统 IP地址主机名 Centos7.9 192.168.108.21 redis1 Centos7.9 192.168.108.22 redis2 Centos7.9 192.168.108.23 redis3 Centos7.9 192.168.108.24 redis4 Centos7.9 192.168.108.25 redis5 Centos7.9 192.168.108.26 redis6

配置

所有主机操作

#安装依赖包 [root@localhost ~]# yum install tcl gcc gcc-c++ -y #解压redis安装包 [root@localhost ~]# tar zxvf redis-6.2.14.tar.gz -C /usr/local/ #编译安装 [root@localhost ~]# cd /usr/local/redis-6.2.14/ [root@localhost redis-6.2.14]# make && make install #修改配置文件 [root@redis1 ~]# cd /usr/local/redis-6.2.14/ [root@localhost redis-6.2.14]# vim redis.conf #监听地址 75 bind 0.0.0.0 -::1 #启动cluster集群 1387 cluster-enabled yes #启动Redis [root@localhost redis-6.2.14]# redis-server redis.conf & #查看启动端口 [root@redis1 redis-6.2.14]# netstat -anpt | grep redis tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 55036/redis-server tcp 0 0 0.0.0.0:16379 0.0.0.0:* LISTEN 55036/redis-server tcp6 0 0 ::1:6379 :::* LISTEN 55036/redis-server tcp6 0 0 ::1:16379 :::* LISTEN 55036/redis-server

任意一台即可

[root@redis1 redis-6.2.14]# redis-cli --cluster create 192.168.108.21:6379 192.168.108.22:6379 192.168.108.23:6379 192.168.108.24:6379 192.168.108.25:6379 192.168.108.26:6379 --cluster-replicas 1 >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 192.168.108.25:6379 to 192.168.108.21:6379 Adding replica 192.168.108.26:6379 to 192.168.108.22:6379 Adding replica 192.168.108.24:6379 to 192.168.108.23:6379 M: fcbf04a3649f4e9e6b381861a94393c31eb67e67 192.168.108.21:6379 slots:[0-5460] (5461 slots) master #[0-5460]是负责槽位0-5064, (5461 slots) 是共5461个槽位 M: f3cb00b07a7836666bd3fd391040ff308ad35685 192.168.108.22:6379 slots:[5461-10922] (5462 slots) master M: 90507dea1ca425cfe6ca993f8c453b2377ded5f0 192.168.108.23:6379 slots:[10923-16383] (5461 slots) master S: 95fd02ecaf3fb34822fd56ed7ae61b05d782d892 192.168.108.24:6379 replicates 90507dea1ca425cfe6ca993f8c453b2377ded5f0 S: 18b45e542ebbf318fd9a92cfe2adcde4c255c72b 192.168.108.25:6379 replicates fcbf04a3649f4e9e6b381861a94393c31eb67e67 S: 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624 192.168.108.26:6379 replicates f3cb00b07a7836666bd3fd391040ff308ad35685 Can I set the above configuration? (type 'yes' to accept): yes >>> Nodes configuration updated >>> Assign a different config epoch to each node 55036:M 03 Feb 2026 11:35:48.414 # configEpoch set to 1 via CLUSTER SET-CONFIGEPOCH >>> Sending CLUSTER MEET messages to join the cluster 55036:M 03 Feb 2026 11:35:48.445 # IP address for this node updated to 192.168.108.21 Waiting for the cluster to join 55036:M 03 Feb 2026 11:35:49.510 * Replica 192.168.108.25:6379 asks for synchronization 55036:M 03 Feb 2026 11:35:49.510 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '5ada9eaab85561721d9411eee29d9e15bf2b87b1', my replication IDs are '868d3acb992f408196b2367647b0cf6c3e02912a' and '0000000000000000000000000000000000000000') 55036:M 03 Feb 2026 11:35:49.510 * Replication backlog created, my new replication IDs are 'cef440df5f9f0706ac9ab7e60a450839e702f045' and '0000000000000000000000000000000000000000' 55036:M 03 Feb 2026 11:35:49.510 * Starting BGSAVE for SYNC with target: disk 55036:M 03 Feb 2026 11:35:49.606 * Background saving started by pid 55327 >>> Performing Cluster Check (using node 192.168.108.21:6379) M: fcbf04a3649f4e9e6b381861a94393c31eb67e67 192.168.108.21:6379 slots:[0-5460] (5461 slots) master 1 additional replica(s) S: 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624 192.168.108.26:6379 slots: (0 slots) slave replicates f3cb00b07a7836666bd3fd391040ff308ad35685 S: 95fd02ecaf3fb34822fd56ed7ae61b05d782d892 192.168.108.24:6379 slots: (0 slots) slave replicates 90507dea1ca425cfe6ca993f8c453b2377ded5f0 M: 90507dea1ca425cfe6ca993f8c453b2377ded5f0 192.168.108.23:6379 slots:[10923-16383] (5461 slots) master 1 additional replica(s) S: 18b45e542ebbf318fd9a92cfe2adcde4c255c72b 192.168.108.25:6379 slots: (0 slots) slave replicates fcbf04a3649f4e9e6b381861a94393c31eb67e67 M: f3cb00b07a7836666bd3fd391040ff308ad35685 192.168.108.22:6379 slots:[5461-10922] (5462 slots) master 1 additional replica(s) 55327:C 03 Feb 2026 11:35:49.733 * DB saved on disk 55327:C 03 Feb 2026 11:35:49.733 * RDB: 4 MB of memory used by copy-on-write 55036:M 03 Feb 2026 11:35:49.736 * Background saving terminated with success 55036:M 03 Feb 2026 11:35:49.737 * Synchronization with replica 192.168.108.25:6379 succeeded [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered. [root@redis1 redis-6.2.14]# 55036:M 03 Feb 2026 11:35:53.476 # Cluster state changed: ok

查看集群状态

[root@redis1 redis-6.2.14]# redis-cli 127.0.0.1:6379> cluster nodes 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624 192.168.108.26:6379@16379 slave f3cb00b07a7836666bd3fd391040ff308ad35685 0 1770089897000 2 connected 95fd02ecaf3fb34822fd56ed7ae61b05d782d892 192.168.108.24:6379@16379 slave 90507dea1ca425cfe6ca993f8c453b2377ded5f0 0 1770089900314 3 connected 90507dea1ca425cfe6ca993f8c453b2377ded5f0 192.168.108.23:6379@16379 master - 0 1770089898000 3 connected 10923-16383 18b45e542ebbf318fd9a92cfe2adcde4c255c72b 192.168.108.25:6379@16379 slave fcbf04a3649f4e9e6b381861a94393c31eb67e67 0 1770089899000 1 connected f3cb00b07a7836666bd3fd391040ff308ad35685 192.168.108.22:6379@16379 master - 0 1770089899267 2 connected 5461-10922 fcbf04a3649f4e9e6b381861a94393c31eb67e67 192.168.108.21:6379@16379 myself,master - 0 1770089899000 1 connected 0-5460 127.0.0.1:6379> cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:6 cluster_my_epoch:1 cluster_stats_messages_ping_sent:1134 cluster_stats_messages_pong_sent:1172 cluster_stats_messages_sent:2306 cluster_stats_messages_ping_received:1167 cluster_stats_messages_pong_received:1134 cluster_stats_messages_meet_received:5 cluster_stats_messages_received:2306

创建数据

创建数据需要到提示的地方创建；或者在redis-cli -c的命令创建数据

# redis1 127.0.0.1:6379> set name gqd (error) MOVED 5798 192.168.108.22:6379 #提示在redis2操作 # redis2 127.0.0.1:6379> set name 'gqd' OK 127.0.0.1:6379> get name "gqd" # redis1 127.0.0.1:6379> get name #创建，查看都只能在redis2 (error) MOVED 5798 192.168.108.22:6379 #如何创建集群能够看到的 [root@redis1 redis-6.2.14]# redis-cli -c 127.0.0.1:6379> set age 18 OK 127.0.0.1:6379> get age "18" [root@redis3 redis-6.2.14]# redis-cli -c 127.0.0.1:6379> get age -> Redirected to slot [741] located at 192.168.108.21:6379 "18"

模拟故障

关掉redis1节点，

再次查看集群信息

[root@redis1 redis-6.2.14]# init 0

# redis 2 127.0.0.1:6379> cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:7 cluster_my_epoch:2 cluster_stats_messages_ping_sent:1486 cluster_stats_messages_pong_sent:1419 cluster_stats_messages_meet_sent:1 cluster_stats_messages_fail_sent:5 cluster_stats_messages_auth-ack_sent:1 cluster_stats_messages_sent:2912 cluster_stats_messages_ping_received:1419 cluster_stats_messages_pong_received:1487 cluster_stats_messages_fail_received:1 cluster_stats_messages_auth-req_received:1 cluster_stats_messages_received:2908

查看节点信息

结果可知，仍保持3台master，原来的redis5节点被选举为新master节点

# redis2 127.0.0.1:6379> cluster nodes 90507dea1ca425cfe6ca993f8c453b2377ded5f0 192.168.108.23:6379@16379 master - 0 1770091176000 3 connected 10923-16383 18b45e542ebbf318fd9a92cfe2adcde4c255c72b 192.168.108.25:6379@16379 master - 0 1770091177432 7 connected 0-5460 f3cb00b07a7836666bd3fd391040ff308ad35685 192.168.108.22:6379@16379 myself,master - 0 1770091175000 2 connected 5461-10922 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624 192.168.108.26:6379@16379 slave f3cb00b07a7836666bd3fd391040ff308ad35685 0 1770091174000 2 connected 95fd02ecaf3fb34822fd56ed7ae61b05d782d892 192.168.108.24:6379@16379 slave 90507dea1ca425cfe6ca993f8c453b2377ded5f0 0 1770091176422 3 connected fcbf04a3649f4e9e6b381861a94393c31eb67e67 192.168.108.21:6379@16379 master,fail - 1770091143695 1770091140000 1 connected

完整过程

如果你的 Redis Cluster 中 192.168.108.21:6379 （Master 1）挂掉，而它的从节点 192.168.108.25:6379 仍然存活，那么整个集群会自动完成故障转移（failover），服务不会中断，数据也不会丢失。下面详细说明会发生什么：

第 1 步：故障检测（约 15 秒内）

其他 master 节点（ .22 和 .23 ）通过 Gossip 协议发现 .21 无响应。

经过 cluster-node-timeout （默认 15 秒）后：

多数 master（≥2/3）将其标记为 FAIL（客观下线）。

第 2 步：Slave .25 自动发起选

.25 （原 .21 的 slave）检测到 master 已 FAIL。

等待一个短暂随机延迟（通常 < 1 秒），然后向其他 master 节点（ .22 和 .23 ）请求投票。

第 3 步：获得多数票，晋升为新 Master

.22 和 .23 收到请求后，验证 .25 是合法副本。

因为有 2 个 master 投票（超过半数）， .25 成功当选

.25 执行

SLAVEOF NO ONE

并接管槽 0–5460。

第 4 步：集群拓扑更新，恢复服务

所有节点收到通知，更新集群视图：

.25 变为 master

槽 0–5460 的 owner 变为 .25

集群状态重新变为：

cluster_state: ok cluster_slots_fail: 0

客户端再次写入 key（如 SET user:1001 “Alice” ，假设其槽在 0–5460）：

自动重定向到 192.168.108.25:6379

操作成功！

redis集群实战（3主3从）