redis的cluster

1.我们的哨兵模式中,当主节点挂掉以后,此时哨兵会重新进行选举,选举出新的主节点去对外提供写服务
在选举的过程中,他redis整个集群是不提供写服务的 (因为此时我们哨兵对外提供写服务的只有Master)
2.我们单节点的redis的内存不能过大,可能8G,10G 如果过大的话,他持久化的以及数据同步的时候就会有压力
所以这个就是哨兵的弊端,基于哨兵的弊端 我们有了cluster模式
他的数据是分片的

redis的cluster_第1张图片

我们此时搭建这么一个redis集群,redisCluster 他的数据是进行分片存储的

redis的cluster_第2张图片
在这里插入图片描述

不同的微服务搞一个小的redis集群  比如说用户用用户的redis集群
redis集群中至少要有3个主节点,每个主节点配置3个从节点,33从,6台机器
主节点会分配槽位

redis的cluster_第3张图片
在这里插入图片描述

一共分配16384个槽位,此时是基于CRC16算法定位数据,我们可以用cluster Info 来查看redis集群的信息  目前来看 他的cluster_size 长度是3

redis的cluster_第4张图片

集群关键信息  clusterNodes  这个是集群的6台信息

在这里插入图片描述

主从架构我们集群的信息 他会写进配置文件中

在这里插入图片描述

集群搭建好了,他会根据你的key计算 用crc16算法来计算 看这个key会在那个节点上
分片定位算法

redis的cluster_第5张图片

元数据信息  比如说我新加一个机器 或者说主节点挂了 在redis中这些信息是通过goosp告诉其他节点的
对于元数据的维护 我们还可以通过zk来进行管理  比如说dubbo kafka之列的
他吧元数据信息维护在zk中,把我们的客户端信息注册在zk中
只要存储元数据的地方发生变化 所有客户端都能够访问到最新的

goosp点对点 慢慢通知的这种情况 通知是要花费时间的
如果你的集群节点搞的太多 内网集群变动的话 内部心跳通知什么的 会很耗时

现在都是微服务架构,一个为微服务或者几个微服务公用一个redis集群,每个redis集群可能就几个主节点  每个主节点配置呢么12个从节点。他不会搞太多机器,因为集群的变动的话,redis内部是通过goosp协议点对点的通知的, 他会很耗时

redis 默认是一个Ap架构 更多的是保证你的可用性
Zk保证是绝对的一致性

redis的集群选举分析原理 当master挂掉以后,会进行多个slave进行选举,选举就会有过半机制

redis的cluster_第6张图片

集群脑裂问题的解决方案 (过半机制)

redis的cluster_第7张图片

你可能感兴趣的:(redis,java,数据库)