一、我们要做什么？
今天的目标很明确：在一台服务器（IP地址是192.168.166.9）上，手动搭建一个3主3从的Redis集群。这意味着我们需要启动6个Redis实例：
- 3个主节点（Master）：端口号分别是6379、6381、6383。
- 3个从节点（Sla ve）：端口号分别是6380、6382、6384。
听起来有点复杂？别担心，跟着步骤走，其实就像搭积木一样清晰。
二、准备工作（傻瓜式操作）
1. 先搞一个模板配置文件
万事开头难，但第一步很简单。我们以系统默认的Redis配置文件为基础，创建一个模板：
- 将
/etc/redis.conf复制一份，命名为/etc/redis/6379.conf。 - 这个文件已经包含了端口、日志路径、数据目录等基础参数，是我们后续批量操作的基础。
2. 一键生成6个配置文件
有了模板，剩下的就是复制粘贴。一条命令就能搞定：
for i in {6380..6384}; do cp 6379.conf $i.conf; done
看，是不是瞬间就生成了从6380到6384的5个配置文件，加上原来的6379，正好6个。
3. 批量改配置（用循环搞定）
每个实例的配置不能完全一样，尤其是端口和文件路径。我们可以用一个简单的循环，批量修改每个配置文件中的关键项。下面这张表清晰地列出了需要修改的地方：
| 配置项 | 改成什么 |
|---|---|
| 端口 | 6379 → 6380、6381… |
| 数据目录 | /var/lib/redis/6379 → 各自端口 |
| 日志文件 | /var/log/redis/6379.log → 各自端口 |
| PID 文件 | /var/run/redis/6379.pid → 各自端口 |
| 保护模式 | yes → no |
| 后台运行 | no → yes |
| 监听地址 | 127.0.0.1 → 192.168.166.9 |
这里有几个关键点：关闭保护模式和绑定真实IP是为了让节点间能够互相通信，这是集群组建的前提。
4. 加上集群配置（每个配置文件末尾追加）
要让Redis实例以集群模式运行，还需要在每个配置文件的末尾加上这三行核心配置：
cluster-enabled yes cluster-config-file nodes-端口.conf cluster-node-timeout 15000
这三行的作用分别是：开启集群模式、指定集群节点配置的存储文件、设置节点间心跳超时时间为15秒。超时后，集群会认为该节点可能故障了。
三、启动所有实例
配置妥当，是时候让它们跑起来了。同样，一条命令启动所有6个实例：
for i in {6379..6384}; do redis-server /etc/redis/$i.conf; done
检查一下进程，如果能看到6个`redis-server`在运行，那么恭喜，第一步的“单兵作战”已经完成。
四、组成集群（手动搓）
现在我们有6个独立的Redis服务，但它们彼此还不认识。接下来，我们要把它们组织成一个真正的集群。
1. 让所有节点互相认识
我们需要让其中一个节点作为“介绍人”，去认识其他所有节点。这里选择6379端口这个实例：
for i in {6380..6384}; do redis-cli -h 192.168.166.9 -p 6379 cluster meet 192.168.166.9 $i; done
执行完这条命令，这6个节点就建立起了联系，知道了彼此的存在。但此时，它们还不知道各自在集群里该干什么。
2. 分配槽位（16384个槽，平均分给3个Master）
这是Redis Cluster的核心设计。整个集群有16384个哈希槽（slot），所有数据都通过key的CRC16校验和对16384取模，映射到某个槽上。现在，我们需要把这16384个“货架”平均分配给3个主节点来管理。
| 节点 | 槽位范围 | 槽数量 |
|---|---|---|
| 6379 | 0 ~ 5461 | 5462 |
| 6381 | 5462 ~ 10922 | 5461 |
| 6383 | 10923 ~ 16383 | 5461 |
分配命令如下：
redis-cli -h 192.168.166.9 -p 6379 cluster addslots {0..5461}
redis-cli -h 192.168.166.9 -p 6381 cluster addslots {5462..10922}
redis-cli -h 192.168.166.9 -p 6383 cluster addslots {10923..16383}
切记：必须分配完所有16384个槽，集群才能进入可用状态。
3. 建立主从关系（谁是谁的备胎）
光有主节点还不够，我们需要为每个主节点配一个从节点，以实现高可用。首先，需要获取每个主节点的唯一ID：
redis-cli -h 192.168.166.9 -p 6379 cluster nodes
在输出的信息中找到端口为6379、6381、6383的节点，记下它们长长的ID。然后，执行复制命令：
# 让6380成为6379的从节点 redis-cli -h 192.168.166.9 -p 6380 cluster replicate <6379的ID> # 让6382成为6381的从节点 redis-cli -h 192.168.166.9 -p 6382 cluster replicate <6381的ID> # 让6384成为6383的从节点 redis-cli -h 192.168.166.9 -p 6384 cluster replicate <6383的ID>
至此，一个3主3从的Redis集群就手动搭建完成了。
五、验证集群
搭建完了，怎么知道成不成功？用这两个命令检查一下：
redis-cli -h 192.168.166.9 -p 6379 cluster nodes redis-cli -h 192.168.166.9 -p 6379 cluster info
第一条命令会列出所有节点的详细信息，包括角色（master/sla ve）、状态和负责的槽位范围。第二条命令则展示集群的整体状态，确保`cluster_state`是`ok`。如果一切正常，那么你的集群就已经在健康运行了。
六、故障恢复（自动的）
Redis Cluster最大的魅力之一就是自动故障转移。我们来模拟一下：
模拟故障
kill -9 <某个master的进程ID>
自动发生的事
- 集群会检测到该主节点失联。
- 经过选举，该主节点对应的从节点会自动晋升为新的主节点。
- 集群继续对外提供服务，整个过程对客户端几乎透明。
恢复后
- 当那个宕机的主节点重新启动后，它会发现自己原来的“位置”已经被从节点接替了。
- 于是，它会自动以从节点（Sla ve）的身份重新加入集群，成为新主节点的副本。
- 整个过程无需人工干预，非常智能。
七、常用命令速查表（大白话版）
为了方便后续管理和排查，这里整理了一份集群常用命令指南：
| 命令 | 大白话解释 |
|---|---|
| cluster meet IP 端口 | 把某个节点拉进群 |
| cluster nodes | 看看群里都有谁，谁是什么角色 |
| cluster addslots 槽位 | 把一批槽分给当前节点 |
| cluster replicate 节点ID | 让当前节点给指定节点当备胎 |
| cluster info | 看看集群整体状态好不好 |
| cluster failover | 手动让备胎上位（强制切换） |
| cluster keyslot key | 看这个 key 属于哪个槽 |
| cluster forget 节点ID | 把某个节点踢出群 |
八、核心注意点（避坑指南）
手动搭建集群虽然灵活，但细节决定成败。下面这些坑，前人已经踩过了：
| 坑 | 解决办法 |
|---|---|
| 启动 Redis 不用绝对路径 | 必须用绝对路径，否则 nodes.conf 会乱 |
| 保护模式没关 | 必须设置 protected-mode no |
| 监听 127.0.0.1 | 改成真实 IP，否则其他节点连不上 |
| 槽位没分完 | 16384 个槽必须全部分配，集群才能用 |
| 主节点没有从节点 | 每个 Master 最好配一个 Sla ve，否则挂了就丢数据 |
九、总结一句话
手动搭建Redis Cluster的流程可以高度概括为：准备6份配置 → 启动所有实例 → 节点互相发现 → 分配哈希槽 → 建立主从关系。最终，你得到的是一个具备数据分片和自动故障转移能力的高可用3主3从集群。
这个过程虽然比用`redis-cli --cluster create`一键创建要繁琐，但对于理解Redis Cluster的底层机制非常有帮助。希望这份手把手的指南能为你提供清晰的参考。
您可能感兴趣的文章:- docker实现redis-cluster模式集群部署的示例代码
- Docker-compose部署redis-cluster集群的完整步骤
- 基于Redis6.2.6版本部署Redis Cluster集群的问题
- k8s部署redis cluster集群的实现
- 使用Ruby脚本部署Redis Cluster集群步骤讲解
- 如何用docker部署redis cluster的方法
