Redis（六）Redis的高可用方案【集群】

大佬教程收集整理的这篇文章主要介绍了Redis（六）Redis的高可用方案【集群】，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

一、集群架构

架构图

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

构建步骤

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

2、给对应端口创建目录
cd cluster    
@H_506_2@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访问密码
@H_506_2@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：因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

槽位定位算法

跳转重定位

redis集群节点间的通信机制

集中式

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

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

gossip

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

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

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

gossip通信的10000端口

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

　　举个🌰：比如8000，那么用于节点间通信的就是18000端口。

网络抖动

三、redis集群选举原理分析【重点理解哈~】

　　当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。

　　由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程，其过程如下：

• 1、slave发现自己的master变为FAIL
• 2、将自己记录的集群currentEpoch【当前分代】加1，并广播FAILOVER_AUTH_requEST信息
• 3、其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK【相当于投票】。PS：对每一个epoch只发送一次ack。
• 4、尝试Failover【期待上位~】的slave收集master返回的FAILOVER_AUTH_ACK【投的票数】
• 5、slave收到超过半数master的ack后变成新Master【半数选举机制】(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)
• 6、slave广播Pong消息通知其他集群节点。

四、redis集群脑裂问题

问题的产生

规避的方法

@H_675_69@@H_506_2@min‐replicas‐to‐write 1 #这个配置的意思是主节点写数据完成后，最少需要同步的slave数量【举个🌰：比如1主2从的机制，原来的主节点因为网络波动被判定为挂了，此时新的从节点想上位，那么它必须要能给另外1个从节点进行redis写的同步，它才能成为主节点。此时对于这个从节点除了自己以外他还有一个从节点对其进行数据同步，那么1+1>2/3符合半数选举机制】

五、redis集群和哨兵的区别

六、小问答

Q：redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

小结

• 为什么至少需要3个master节点：半数选举机制
• 为什么推荐节点数为奇数：从节省机器资源角度出发考虑的

Q：集群是否完整才能对外提供服务？

@H_675_69@#表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用，如果为yes则集群不可用。
cluster-require-full-coverage no