脚本宝典收集整理的这篇文章主要介绍了Redis-集群核心原理,脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
Redis Cluster将所有数据划分为16384个slot(槽位),每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。 当Redis Cluster的客户端来连接集群时,它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个key时,可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况,还需要纠正机制来实现槽位信息的校验调整。
Cluster默认会对key值使用crc16算法进行hash得到一个整数值,然后用这个整数值对16384进行取模来得到具体槽位。
HASH_SLOT = CRC16(key) mod 16384
当客户端向一个错误的节点发出了指令,该节点会发现指令的key所在的槽位并不贵归自己管理,这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址,告诉客户端去连接这个节点获取数据。客户端接收到指令后除了跳转到正确的节点上操作,还会同步更新纠正本地的槽位映射表缓存,后续所有key将使用新的槽位映射表。
redis cluster 节点采用gossip协议进行通信
优点在于元数据更新和读取的时效性非常好,一旦元数据出现变更立即就会更新到集群的存储中,其他节点读取的时候立即就可以感知到; 不足在于所有的元数据的更新压力全部集中在一个地方,可能导致元数据的存储压力。 很多中间件都会借助zookeePEr集中式存储元数据。
gossip协议的优点在于元数据的更新比较分散,不是集中在一个地方,更新请求会陆陆续续,打到所有节点上去更新,有一定的延时,降低了压力; 缺点在于元数据更新有延时可能导致集群的一些操作会有一些之后。
每个节点都有一个专门用于节点间gossip通信的端口,就是自己提供服务的端口好+10000,比如7001,那么用于节点间通信的就是17001端口。每个节点每个一段时间都会往另外几个几点发送ping消息,同时其他节点接收到ping消息后返回pong消息。
真实世界的机房网络往往不是风平浪静的,它们经常会发生各种各样的额小问题。比如网络抖动就是非常常见的现象,突然之间部分连接变得不可访问,然后很快又恢复正常。
为解决这个问题,Redis Cluster提供了一种cluster-node-timeout
,表示当某个节点持续timeout的时间失联时,才可以认定该节点出现故障,需要进行主从切换。如果没有这个选项,网络抖动会导致主从切换频繁(数据的重新复制)。
当slave发现自己的master变为FAIL状态时,便尝试进行Failover,以期成为新的master。由于挂掉的master可能会由多个slave,从而存在多个slave竞争成为master节点的过程,其过程如下:
从节点并不是在主节点一进去FAIL状态就马上尝试发起选举,而是有一定延迟,一定的延迟确保我们等待FAIL状态在集群中传播,slave如果立即尝试选举,其他master或许尚未意识到FAIL状态,可能会拒绝投票。
DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
redis集群没有过半机制会有脑裂问题,网络分区导致脑裂后多个主节点对外提供写服务,一旦网络分区恢复,会将其中一个主节点变为从节点,这是会有大量数据丢失。规避方法可以在redis配置里加上参数(这种方法不呢能百分百避免数据丢失,参考集群leader选举机制)
min-slaves-to-wrITe 1 // 写数据成功最少同步的slave数量,这个数量可以模仿大于半数机制配置,比如集群总共三个节点可以配置1,加上leader就是2,超过了半数
注意:这个配置在一定程度上会影响集群的可用性,比如slave要是少于1个,这个集群就算leader正常也不能提供服务了,需要具体场景权衡选择。
当redis.conf的配置cluster-full-coverage为no时,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时,集群仍然可用,如果为yes则集群不可用。
因为新master的选举需要大于半数的集群master节点同意才能选举成功,如果只有两个master节点,当其中一个挂了,是达不到选举新master的条件的。 奇数个master节点可以在满足选举该条件的基础上节省一个节点。比如三个master节点和四个master节点的集群相比,大家如果都挂了一个master节点都能选举新master节点,如果都挂了两个master节点都没法选举新master节点了,所以奇数的master节点更多的是从节省机器资源角度出发说的。
对于类似mset,mget这样的多个key的原生批量操作命令,redis集群只支持所有key落在同一slot的情况,如果多个key一定要用Mset命令在redis集群上操作,则可以在key的前面加上{XX},这样参数数据分片hash计算的只会是大括号里的值,这样能确保不同的key能落到同一slot里去,示例如下:
mset {user1}:name pidan {user1}:age 28
假设name和age计算的hash slot值不一样,但是这条命令在集群下执行,redis只会用大括号里的user1做hash slot计算,所以算出来的slot值肯定相同,最后能落到同一slot。
当一个master服务器被某个sentinel视为下线状态后,该sentinel会与其他snetinel协商选出sentinel的leader进行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader,选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期),每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后的主从也能正常运行以及选举master,如果master挂了,那唯一的那个哨兵节点就是哨兵leader了,可以正常选举新master。 不过为了高可用,一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似。
以上是脚本宝典为你收集整理的Redis-集群核心原理全部内容,希望文章能够帮你解决Redis-集群核心原理所遇到的问题。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。