pong|Redis高可用架构—Redis集群（Redis Cluster）详细介绍( 二 )

Redis集群中节点的通信既然Redis集群中的数据是通过哈希槽的方式分开存储的，那么集群中每个节点都需要知道其他所有节点的状态信息，包括当前集群状态、集群中各节点负责的哈希槽、集群中各节点的master-slave状态、集群中各节点的存活状态等。 Redis集群中，节点之间通过建立TCP连接，使用gossip协议来传播集群的信息。如下图：

所谓gossip协议，指的是一种消息传播的机制，类似人们传递八卦消息似的，一传十，十传百，直至所有人都知道这条八卦内容。 Redis集群中各节点之间传递消息就是基于gossip协议，最终达到所有节点都会知道整个集群完整的信息。 gossip协议有4种常用的消息类型：PING、PONG、MEET、FAIL 。
● MEET：当需要向集群中加入新节点时，需要集群中的某个节点发送MEET消息到新节点，通知新节点加入集群。新节点收到MEET消息后，会回复PONG命令给发送者。
● PING：集群内每个节点每秒会向其他节点发送PING消息，用来检测其他节点是否正常工作，并交换彼此的状态信息。 PING消息中会包括自身节点的状态数据和其他部分节点的状态数据。
● PONG：当接收到PING消息和MEET消息时，会向发送发回复PONG消息， PONG消息中包括自身节点的状态数据。节点也可以通过广播的方式发送自身的PONG消息来通知整个集群对自身状态的更新。
● FAIL：当一个节点判定另一个节点下线时，会向集群内广播一个FAIL消息，其他节点接收到FAIL消息之后，把对应节点更新为下线状态。
Redis集群的MOVED重定向Redis客户端可以向Redis集群中的任意master节点发送操作指令，可以向所有节点（包括slave节点）发送查询指令。当Redis节点接收到相关指令时，会先计算key落在哪个哈希槽上（对key进行CRC16校验后再对16384取模），如果key计算出的哈希槽恰好在自己节点上，那么就直接处理指令并返回结果，如果key计算出的哈希槽不在自己节点上，那么当前节点就会查看它内部维护的哈希槽与节点ID之间的映射关系，然后给客户端返回一个MOVED错误：MOVED [哈希槽
[节点IP:端口
。这个错误包含操作的key所属的哈希槽和能处理这个请求的Redis节点的IP和端口号，例如“MOVED 3999 127.0.0.1:6379” ，客户端需要根据这个信息重新发送查询指令到给定的IP和端口的Redis节点。

Redis集群的搭建及使用要让集群正常运作至少需要3个master节点，为了高可用，每个master节点至少要有一个slave节点，所以我们就用3个master节点+3个slave节点来搭建集群。
首先准备三台虚拟机，并在每台虚拟机上安装好redis 。我本地的三台虚拟机为：192.168. 31.77、192.168. 31.78、192.168. 31.79 。如果本地还未安装过虚拟机，可以根据我之前的教程配置安装： VMware Workstation 14安装教程、虚拟机环境搭建（VMware14+centos7）、 VMware+CentOS7 网络及静态IP配置、 Linux安装Redis 。
以192.168.31.77这台虚拟机操作演示，拷贝出两份单独的redis配置文件，其中一个作为master节点的配置，一个作为slave节点的配置。

修改这两个配置文件，下面是一个集群需要的最少选项配置：

基于这两个配置文件分别启动一个redis实例：

另外两台虚拟机执行同样的步骤启动好各自的两台redis实例。此时，我们就有了6台运行中的redis实例：

接下来我们需要使用这些实例来创建集群。在Redis3.x版本中，只能用redis-trib.rb程序来创建集群， redis-trib.rb是一个Ruby程序，使用前需要先配置Ruby环境。创建集群命令如下：