准备工作

redis集群一般由多个节点组成，节点数至少为6个才能保证组成完整高可用的集群。建议为集群所有的节点配置统一的目录，我一般习惯按照端口号区分节点，如：/opt/redis/6379/conf/redis-6379.conf，/opt/redis/6380/conf/redis-6380.conf，所有的数据包括日志都存放在/opt/redis/{port}下。节点配置文件格式为redis-{port}.port，集群配置文件为node-{port}.conf。

bind 0.0.0.0

pidfile /var/run/redis_6379.pid

port 6379

logfile "6379.log"

dbfilename dump-6379.rdb

dir "/opt/redis/6379/"

appendfilename "appendonly-6379.aof"

daemonize yes

maxmemory 30m

cluster-enabled yes

cluster-config-file nodes-6379.conf

---

启动所有节点

redis-servier /opt/redis/6379/conf/redis-6379.conf

redis-servier /opt/redis/6380/conf/redis-6380.conf

redis-servier /opt/redis/6381/conf/redis-6381.conf

redis-servier /opt/redis/6382/conf/redis-6382.conf

redis-servier /opt/redis/6383/conf/redis-6383.conf

redis-servier /opt/redis/6384/conf/redis-6384.conf

第一次启动时，如果没有集群配置文件，它会自动创建一份，文件名称由cluster-config-file参数项控制。启动过程如下图所示：

集群模式的redis除了原有的配置文件之外又加了一份集群配置文件。当集群内节点信息发生变化，如添加节点，节点下线，故障转移等。节点会自动保存集群状态到配置文件中。需要注意的是，redis自动维护集群配置文件，不要手动修改，防止节点重启时产生集群信息错乱。

如节点6379首次启动后生成集群配置如下：

cat /opt/redis/6379/nodes-6379.conf

04583d74493aed49e97973c84109a0bfe5ba63da :0@0 myself,master - 0 0 0 connected

vars currentEpoch 0 lastVoteEpoch 0

文件内容纪录集群初始状态，这里最重要的是节点ID，他是一个40位16进制字符串，用于唯一标识集群内的一个节点，之后很多集群操作都要借助于节点ID来完成。节点ID不同于运行ID。节点ID在集群初始化时只创建一次，节点重启时会加载集群配置文件进行重用。每个节点目前只能识别出自己的节点信息。我们启动6个节点，但每个节点彼此并不知道对方的存在，下面通过节点握手让6个节点彼此建立联系从而组成一个集群。

---

节点握手

节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信，达到感知对方的过程。

客户端(假设现在是在6379上的客户端)发起命令:

cluster meet {ip} {port}

假设命令为：cluster meet 127.0.0.1 6380

即是让节点6379和6380节点进行握手通信。cluster meet命令是一个异步命令，执行之后立即返回。内部发起与目标节点进行握手通信，如下图：

cluster meet命令进行节点握手的过程

1>节点6379本地创建6380节点信息对象，并发送meet消息。

2>节点6380接受到meet消息后，保存6379节点信息并回复pong消息。

3>之后节点彼此定期通过ping/pong消息进行正常的节点通信。

下面分别执行meet命令让其他的节点加入到集群当中，我们只需要在集群内任意节点上执行cluster meet命令加入新节点，握手状态会通过消息在集群内传播，这样其他节点会自动发现新节点并发起握手流程。

建立握手后集群还不能正常工作，这时集群处于下线状态，所有的数据读写都被禁止。

通过cluster info命令可以获取集群当前状态：

127.0.0.1:6379> cluster info

cluster_state:fail

cluster_slots_assigned:0

cluster_slots_ok:0

cluster_slots_pfail:0

cluster_slots_fail:0

cluster_known_nodes:6

cluster_size:0

cluster_current_epoch:5

cluster_my_epoch:1

cluster_stats_messages_ping_sent:897

cluster_stats_messages_pong_sent:736

cluster_stats_messages_meet_sent:6

cluster_stats_messages_sent:1639

cluster_stats_messages_ping_received:736

cluster_stats_messages_pong_received:753

cluster_stats_messages_received:1489

从输出内容可以看到，被分配的槽（cluster_slots_assigned）是0，由于目前所有的槽没有分配到节点，因此集群无法完成槽道节点的映射。只有当16384个槽全部分配给节点后，集群才会进入在线状态。

---

分配槽

redis集群把所有的数据映射到16384个槽中。每个key会映射为一个固定的槽，只有当节点分配了槽，才能响应和这些槽关联的键命令。通过cluster addslots命令为节点分配槽。

redis-cli -h 127.0.0.1 -p 6379 cluster addslots {0..5461}

redis-cli -h 127.0.0.1 -p 6380 cluster addslots {5462..10922}

redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923..16383}

注：6379分配了5462个槽，6380分配了5461个槽，6381分配了5461个槽，注意区间中的点只有两个。

基本平均分配后，查看集群信息：

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:5

cluster_my_epoch:1

cluster_stats_messages_ping_sent:2253

cluster_stats_messages_pong_sent:2017

cluster_stats_messages_meet_sent:6

cluster_stats_messages_sent:4276

cluster_stats_messages_ping_received:2017

cluster_stats_messages_pong_received:2109

cluster_stats_messages_received:4126

当前集群状态是ok，集群进入在线状态。所有的槽都已经分配给节点，执行cluster nodes命令可以看到节点和槽的分配关系：

可以看到目前还有3个节点没有被使用，作为一个完整的集群，每个负责处理槽的节点应该具有从节点，保证当它出现故障时可以自动进行故障转移。集群模式下，redis节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关数据。

使用命令可以让一个节点成为从节点。

127.0.0.1:6382> cluster replicate 04583d74493aed49e97973c84109a0bfe5ba63da

127.0.0.1:6383> cluster replicate ae87f095caf8168fd300ee92dec28dfa09706141

127.0.0.1:6384> cluster replicate 3668135fd6acb06319299cd28e8705cb40eb38d5

redis集群模式下的主从复制支持全量复制和部分复制。

复制完成后集群关系如下：

6379(主)  <--- 6382(从)

6380(主)  <--- 6383(从)

6381(主)  <--- 6384(从)

到目前为止，我们依照redis协议手动建立了一个集群。它由6个节点构成，3个主节点负责处理槽和相关的数据，3个从节点负责故障转移。步骤繁杂，因此redis官方提供redis-trib.rb工具方便我们快速搭建集群。