一、集群架构

架构图

• Redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。
• Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。
• 需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展。PS：官方推荐不超过1000个节点。
• redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。

构建步骤

1、创建用于演示的集群文件夹
mkdir cluster

2、给对应端口创建目录
cd cluster    
mkdir 8000 8001 8002 8003 8004 8005

3、复制redis.conf文件到对应的目录下
cp redis.conf zhRedisDemo/cluster/8000
cp redis.conf zhRedisDemo/cluster/8001
cp redis.conf zhRedisDemo/cluster/8002
cp redis.conf zhRedisDemo/cluster/8003
cp redis.conf zhRedisDemo/cluster/8004
cp redis.conf zhRedisDemo/cluster/8005

4、修改配置文件的值【6台机器的都要修改】
daemonize yes #守护线程方式启动【后台运行】
port 8000 #端口
pidfile /var/run/redis_8000.pid #把pid进程号写入pidfile配置的文件
dir /usr/local/redis‐cluster/8000/ #指定数据文件存放位置，必须要指定不同的目录位置，不然会丢失数据
cluster‐enabled yes #启动集群模式
cluster‐config‐file nodes‐8000.conf #集群节点信息文件，这里800x最好和port对应上
cluster‐node‐timeout 10000 #集群连接超时时间
#bind 127.0.0.1 #bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可 
protected‐mode no #关闭保护模式
appendonly yes #打开AOF持久化
equirepass xxxxxxx #设置redis访问密码
masterauth xxxxxxx #设置集群节点间访问密码，跟上面一致

5、分别启动6台实例

6、使用redis‐cli创建整个redis集群【Redis5.0+版本】
redis-cli -a 密码 --cluster create --cluster-replicas 1 120.24.58.161:8000 120.24.58.161:8001 120.24.58.161:8002 120.24.58.161:8003 120.24.58.161:8004 120.24.58.161:8005

二、Redis集群原理的一些概念

　　Redis Cluster 将所有数据划分为16384slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。

　　当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个key时，可以直接定位到目标节点。

　　PS：因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

槽位定位算法

　　Cluster 默认会对key值使用crc16算法进行hash得到一个整数值，然后用这个整数值对16384进行取模来得到具体槽位。

　　HASH_SLOT = CRC16(key) mod 16384

　　PS：新节点加入集群中时是无法写数据的（没有slot槽位），需要从新分配槽位后才可以访问

　　PS：迁移槽位会把对应的数据也迁移过去

　　PS：新节点加入集群时都是master节点

跳转重定位

　　当客户端向一个错误的节点发出了指令，该节点会发现指令的key所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。

　　客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有key将使用新的槽位映射表。

Redis集群节点间的通信机制

　　Redis cluster节点间采取gossip协议进行通信，有两种方式：

集中式

• 优点：元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到。
• 缺点：所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储压力。

　　PS：很多中间件都会借助zookeeper集中式存储元数据。

gossip

• 优点：元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力。
• 缺点：元数据更新有延时可能导致集群的一些操作会有一些滞后。

　　gossip协议包含多种消息，包括ping，pong，meet，fail等等。

• meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信。
• ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据【类似自己感知到的集群节点增加和移除，hash slot信息等】。
• pong：对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新。
• fail：某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

gossip通信的10000端口

　　每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，

　　举个