Redis集群搭建及选举原理

03/17 00:03
阅读数 25

redis集群简述

哨兵模式中如果主从中master宕机了,是通过哨兵来选举出新的master,在这个选举切换主从的过程,整个redis服务是不可用的。而且哨兵模式中只有一个主节点对外提供服务,因此没法支持更高的并发。而且当个主节点的内存设置也不宜过大。否则会导致持久化文件过大,影响数据恢复或主从同步的效率。

 

redis集群是由一系列的主从节点群组成的分布式服务器群,它具有复制、高可用和分片特性。Redis集群不需要 sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式,这种集群模式没有中心节点,客户端通过CRC16算法对key进行hash

得到一个值,来判断该key存储在哪个主从服务上面,因此就算是某一个主从整个宕机,redis集群也是部分可用的。方便水平扩展,可以根据业务规模可以随时加减配置。据官方文档称可以线性扩展到上万个节点(但是官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于哨兵模式

 

 

 

Redis集群搭建

 

 

 

1.修改redis.conf配置文件

  1. daemonize yes                    后台启动   
  2. cluster-enabled yes                开启集群模式
  3. cluster-config-file nodes-6379.conf   集群配置信息存放文件名
  4. cluster-node-timeout 5000          节点离线时间限制,到达此值时发起某个主从重新选举master
  5. protected-mode no                关闭保护模式
  6. requirepass xxx                   设置本机密码
  7. masterauth xxx                    设置访问别的机器的密码

2.注意关闭服务器的防火墙,否则可能造成节点之间无法通信,无法搭建集群

使用修改好的配置文件启动redis服务,我这里使用三个一主一从来搭建。因此先将6redis服务使用指定的配置文件redis-master.conf启动起来:src/redis-server redis-master.conf

3.搭建集群服务

为了保险起见最好先检查下每台机器的redis服务是否正常启动了ps -ef|grep redis

可以看见redis服务进程后面有个cluster的标志,普通启动的redis服务是没有这个标志的

 

 

5.0版本可以直接使用C语言客户端提供的指令去构建集群:

src/redis-cli -a xxx --cluster create --cluster-replicas 1 192.168.0.67:6379 192.168.0.68:6379 192.168.0.69:6379 192.168.0.70:6379 192.168.0.71:6379 192.168.0.72:6379

-a  配置的密码

--cluster create  表示集群创建

--cluster-replicas   表示每个master几个slave,上面一共6redis节点,因此会构建三个一主一从。

 

执行命令之前,如果你的redis环境以前搭建过主从或者哨兵之类的,数据不干净可能会报错,最好将持久化文件删掉,然后flushdb,将以前脏数据清理掉,否则可能出现如下错误:

 

 

 正常执行会返回一个集群分配计划,我们按照它的计划即可:

 

 

 

 

 

 然后节点之间就开始通信构建集群,最后会看见16384slots分配完毕,可以看见构建计划中有三个master,每个master都是有指定槽位的。意思就是存入的key经过crc16 hash算法之后得到的值,在哪个范围内,就存储到那个redis主从上面去,这就是redis的分片集群模式。

 

 至此集群搭建完毕

4.集群操作

以集群方式连接redis客户端通过cluster info查看集群信息,通过cluster nodes查看节点信息

src/redis-cli -a 密码 -c   集群方式连接

 

 我们设置set abc 123一个值 会看见客户点会计算abcslot7638, 然后重定向到对应的主从的master上面去写数据

 

 现在我看下java客户端的jedis里面的key值计算redis.clients.util.JedisClusterCRC16#getSlot(java.lang.String)

 

 

 

最后计算结果就会落到0-16383之间去。

Redis Cluster 的客户端来连接集群时,它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户 端要查找某个 key 时,可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况,还需 要纠正机制来实现槽位信息的校验调整。

 

 

集中式集群和分片式集群

Redis节点之间使用的是gossip协议进行通信,每个节点之间都会互相通信。

 

gossip协议包含多种消息,包括pingpongmeetfail等等。

 

ping:每个节点都会频繁给其他节点发送ping,其中包含自己的状态还有自己维护的集群元数据,互相通过ping交换元数据;

 

pong: 返回pingmeet,包含自己的状态和其他信息,也可以用于信息广播和更新;

 

fail: 某个节点判断另一个节点fail之后,就发送fail给其他节点,通知其他节点,指定的节点宕机了。

 

meet:某个节点发送meet给新加入的节点,让新节点加入集群中,然后新节点就会开始与其他节点进行通信,不需要发送形成网络的所需的所有CLUSTER MEET命令。发送CLUSTER MEET消息以便每个节点能够达到其他每个节点只需通 过一条已知的节点链就够了。由于在心跳包中会交换gossip信息,将会创建节点间缺失的链接。

 

 

 

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

 

就是自己提供服务的端口号+10000,比如6379,那么用于节点间通信 的就是16379端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息,同时其他几点接收到ping消息之后返回pong消息。

 

 

 

还有就是集中式的,比如ZK集群

 

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

 

 

 

 

Redis集群选举机制

 

slave发现自己的master变为FAIL状态时,便尝试发起选举,以期成为新的master。由于挂掉的master可能会有多个slave,从而存在多个slave竞争成为master节点的过程, 其过程如下:

 

1.slave发现自己的master变为FAIL

 

2.将自己记录的集群currentEpoch(选举轮次标记)加1,并广播信息给集群中其他节点

 

3.其他节点收到该信息,只有master响应,判断请求者的合法性,并发送结果

 

4.尝试选举的slave收集master返回的结果,收到超过半数master的统一后变成新Master

 

5.广播Pong消息通知其他集群节点。

 

如果这次选举不成功,比如三个小的主从A,B,C组成的集群,A的master挂了,A的两个小弟发起选举,结果B的master投给A的小弟A1,C的master投给了A的小弟A2,这样就会发起第二次选举,选举轮次标记+1继续上面的流程。事实上从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举,而是有一定延迟,一定的延迟确保我们等待FAIL状态在集群中传播,slave如果立即尝试选举,其它masters或许尚未意识到FAIL状态,可能会拒绝投票。 同时下面公式里面的随机数,也可以有效避免slave同时发起选举,导致的平票情况。

 

•延迟计算公式:

 

DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

 

•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下,持有最新数据的slave将会首先发起选举(理论上)。

 

 

 

前面说到这种分片的集群模式的集群可以部分提供服务,redis.conf的配置cluster-require-full-coverage为no时,表示当一个小主从整体挂掉的时候集群也可以用,也是说0-16383个槽位中,落在该主从对应的slots上面的key是用不了的,但是如果key落在其他的范围是仍然可用的。

 

 

 

 

 

 

原文出处:https://www.cnblogs.com/nijunyang/p/12508098.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部