Redis集群怎么搭建，还有那些依赖得先弄明白才能顺利搞定

要顺利搭建一个Redis集群,你不能上来就直接敲命令，那样大概率会遇到各种莫名其妙的问题，你得先当个“建筑师”，把地基和图纸想清楚，这主要涉及两大块：一是你必须先弄明白的几个核心依赖和概念，二是具体的搭建步骤，我们先花大篇幅把依赖讲透，因为这才是能“顺利搞定”的关键。

第一部分：必须事先弄明白的依赖和核心概念

（依据Redis官方文档对集群的说明和分布式系统的基本原理）

你得知道Redis集群是个什么东西,简单说，它就是把你很多个（至少6个）Redis实例组合在一起，变成一个整体对外服务，这样做主要有两个目的：一是为了存更多数据（数据分片），二是为了保证服务不中断（高可用），理解了这两个目标，你就能理解它为什么这么设计了。

理解数据分片和哈希槽（Hash Slot） 这是Redis集群最核心的概念，你必须吃透，Redis集群不是像某些数据库那样靠记录存在哪个节点来分片，而是引入了一个叫“哈希槽”的中间层，集群一共有16384个槽，你可以把它想象成一个大数组，有16384个格子，当你存一个数据（比如一个键值对）时，Redis会用一个公式（CRC16算法）算一下这个键（key）的名字，然后对16384取模，算出来一个介于0到16363之间的数字，这个数字就决定了你的这个数据应该放在哪个“格子”里。 这些“格子”是怎么分配的呢？集群中的每个主节点（Master Node）都会负责管理一部分哈希槽，比如你有三个主节点，可能就会这样分配：节点A管0-5460号槽，节点B管5461-10922号槽，节点C管10923-16383号槽，这样一来，当你要查询某个key时，客户端会先算出它属于哪个槽，然后直接去管理这个槽的节点上操作。搭建前你得决定好：你的集群要设置多少个主节点？这16384个槽如何分配给它们？ 通常为了均衡，会尽量平均分配。

理解高可用和主从复制（Master-Slave Replication） 光有分片还不够，如果某个主节点宕机了，它负责的那部分数据就访问不了了，所以需要高可用，Redis集群的高可用机制和单机的Redis哨兵模式类似，但集成在了集群内部。对于每一个主节点，你都需要给它配置一个或多个从节点（Slave Node），从节点会实时复制主节点的数据，当主节点宕机时，集群中的其他主节点会投票选举一个从节点“升职”成为新的主节点，接管原来主节点负责的所有哈希槽，从而继续提供服务。 这就决定了你的集群规模。Redis集群至少需要三个主节点才能实现故障转移时的投票仲裁（因为要保证多数派），而每个主节点至少建议配一个从节点，一个能抗故障的最小Redis集群需要6个Redis实例（3主3从），你必须提前规划好服务器资源，准备好这6个（或更多）实例的运行环境。

网络和端口要求 集群内的节点需要频繁地通信，比如互相探测健康状态、同步数据、传播槽信息、故障转移协商等。网络通畅是底线，你需要确保：

1. 所有节点之间的网络都是互通的，这意味着你打算运行Redis实例的服务器之间不能有防火墙阻挡集群通信的端口。
2. 端口要开放两个：一个是客户端连接用的端口（默认6379），另一个是集群总线端口（Cluster Bus Port），通常是客户端端口加10000（比如16379），集群总线用于节点间的心跳、故障检测、配置更新等，这个端口必须开放，否则集群无法正常工作，很多人在防火墙上只开了6379，导致集群组建失败，就是栽在这里。

客户端要求 不是所有Redis客户端都能直接连接集群，你的应用程序使用的客户端必须支持Redis集群协议，像常见的Redis客户端库（如Java的Jedis、Lettuce，Python的redis-py等）都有支持集群的版本，一个支持集群的客户端能帮你做一件事：缓存“槽位映射表”，当它第一次连接集群时，会获取一份“哪个槽由哪个节点负责”的映射表缓存在本地，当你要访问一个key时，客户端会先在本地算出槽位，然后直接发请求到正确的节点，如果节点返回“MOVED”错误（意思是这个槽已经不归我管了，你去找XXX节点），客户端会更新本地缓存并重定向到新节点，这一切对程序员来说是透明的，但你必须确保用的是正确的客户端库。

第二部分：Redis集群的搭建步骤

（基于Redis官方提供的redis-trib.rb工具以及新版集成的redis-cli工具的使用方法）

当你把上面的概念和依赖都搞清楚之后,搭建过程反而相对直接，这里以Redis 5.0之后版本自带的redis-cli集群管理功能为例（更简单，不需要Ruby环境）。

准备多个Redis实例 你不是要6个节点吗？那就在你的服务器上（可以是6台不同的机器，也可以是一台机器上用不同端口模拟）启动6个Redis实例，关键是每个实例的配置文件（redis.conf）需要开启集群模式并做相应配置：

port 6379  # 每个实例的端口要不同，比如6379, 6380, 6381...
daemonize yes  # 后台运行
pidfile /var/run/redis_6379.pid
logfile "6379.log"
dir /your/data/path/  # 数据目录，每个实例最好不同
cluster-enabled yes  # 这是关键，开启集群模式
cluster-config-file nodes-6379.conf  # 集群自动生成的配置文件，每个实例不同
cluster-node-timeout 15000  # 节点超时时间

用类似的配置,启动你的6个Redis实例。

组建集群 使用redis-cli命令，一行命令就能将6个实例组建成一个3主3从的集群：

redis-cli --cluster create \
192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 \
192.168.1.10:6380 192.168.1.11:6380 192.168.1.12:6380 \
--cluster-replicas 1

这条命令的意思是：前面跟6个实例的地址，--cluster-replicas 1表示每个主节点配1个从节点，工具会自动帮你把前三个节点分配为主节点，并平均分配16384个槽，同时将后三个节点分别设置为前三个节点的从节点。

验证集群 组建完成后，用redis-cli连接上任意一个节点，检查集群状态：

redis-cli -c -p 6379  # -c 表示以集群模式连接，支持自动重定向
cluster info  # 查看集群整体状态，看cluster_state是否为ok
cluster nodes # 查看节点列表和主从关系、槽分配情况

还可以尝试set/get一些数据，观察是否能在不同节点间自动跳转。

顺利搭建Redis集群的秘诀是“七分准备，三分执行”，你必须花时间彻底理解数据分片（哈希槽）、高可用（主从复制）的原理，并确保网络、端口、客户端等依赖条件万无一失，当这些基础打牢后，实际的搭建命令反而非常简单和机械，忽略前置的依赖理解，直接照搬步骤，是很多人失败的主要原因。