Redis集群架构

知识点回顾

Redis主从架构

Redis主从架构的工作模式为提供多台Redis服务,选择其中的一台作为master节点向外提供读写服务,剩下的作为slave节点从master节点复制数据,只向外提供读服务。

Redis哨兵架构

Redis哨兵架构实现了对所有Redis节点的监控和Master的自动故障转移。

集群架构概述

一般情况下来说,上面两种方式结合起来使用已经可以满足大部分的Redis高可用场景,但它有一个很明显的缺点:只有一台Master节点向外提供写服务,其他的Slave节点只能提供读服务。所以,当写操作并发量很大的,无法缓解写操作的压力。针对这种场景,Redis在3.0版本中引入了Redis集群的部署架构。

Redis集群架构(Redis Cluster)是Redis 3.0开始引入的一种分布式存储架构,该架构由多个Redis节点组成,所有的数据分布在不同的节点中。

Redis集群架构中的节点可以分为主节点和从节点:
(1)主节点负责读写请求和集群信息的维护。
(2)从节点只进行主节点数据和状态的复制。

集群架构特性

Redis集群是一个提供在多个Redis节点之间共享数据的程序集。它并不像Redis主从复制模式那样只提供一个Master节点提供写服务,而是会提供多个Master节点提供写服务,每个Master节点中存储的数据都不一样,这些数据通过数据分片的方式被自动分割到不同的Master节点上。

为了保证集群的高可用,每个Master节点下面还需要添加至少1个Slave节点,这样当某个Master节点发生故障后,可以从它的Slave节点中选举一个作为新的Master节点继续提供服务。这样就组成了下图中的结构模式:


Redis集群架构

Redis集群架构示意图


集群架构哈希槽

Redis集群中引入了哈希槽的概念,Redis集群有16384个哈希槽,进行set操作时,每个key会通过CRC16校验后再对16384取模来决定放置在哪个槽,搭建Redis集群时会先给集群中每个Master节点分配一部分哈希槽。比如当前集群有3个Master节点,master1节点包含05500号哈希槽,master2节点包含550111000号哈希槽,master3节点包含11001~16384号哈希槽,当我们执行“set key value”时,假如 CRC16(key) % 16384 = 777,那么这个key就会被分配到master1节点上,如下图:


Redis集群架构

Redis集群架构哈希槽示意图


集群架构通信

既然Redis集群中的数据是通过哈希槽的方式分开存储的,那么集群中每个节点都需要知道其他所有节点的状态信息,包括当前集群状态、集群中各节点负责的哈希槽、集群中各节点的master-slave状态、集群中各节点的存活状态等。Redis集群中,节点之间通过建立TCP连接,使用gossip协议来传播集群的信息。如下图:


Redis集群架构

Redis集群架构通信示意图


所谓gossip协议,指的是一种消息传播的机制,类似人们传递八卦消息似的,一传十,十传百,直至所有人都知道这条八卦内容。Redis集群中各节点之间传递消息就是基于gossip协议,最终达到所有节点都会知道整个集群完整的信息。gossip协议有4种常用的消息类型:PING、PONG、MEET、FAIL。

(1)PING:集群内每个节点每秒会向其他节点发送PING消息,用来检测其他节点是否正常工作,并交换彼此的状态信息。PING消息中会包括自身节点的状态数据和其他部分节点的状态数据。
(2)PONG:当接收到PING消息和MEET消息时,会向发送方回复PONG消息,PONG消息中包括自身节点的状态数据。节点也可以通过广播的方式发送自身的PONG消息来通知整个集群对自身状态的更新。
(3)MEET:Redis CLUSTER MEET 命令被用来连接不同的开启集群支持的 Redis 节点,以进入工作集群。其基本的思想是每个节点默认都是相互不信任的,并且被认为是未知的节点,以便万一因为系统管理错误或地址被修改,而不太可能将多个不同的集群节点混成一个集群。
(4)FAIL:当一个节点判定另一个节点下线时,会向集群内广播一个FAIL消息,其他节点接收到FAIL消息之后,把对应节点更新为下线状态。

集群重定向

Redis客户端可以向Redis集群中的任意master节点发送操作指令,可以向所有节点(包括slave节点)发送查询指令。当Redis节点接收到相关指令时,会先计算key落在哪个哈希槽上(对key进行CRC16校验后再对16384取模),如果key计算出的哈希槽恰好在自己节点上,那么就直接处理指令并返回结果,如果key计算出的哈希槽不在自己节点上,那么当前节点就会查看它内部维护的哈希槽与节点ID之间的映射关系,然后给客户端返回一个MOVED错误:MOVED [哈希槽] [节点IP:端口]。这个错误包含操作的key所属的哈希槽和能处理这个请求的Redis节点的IP和端口号,例如“MOVED 3999 127.0.0.1:6379”,客户端需要根据这个信息重新发送查询指令到给定的IP和端口的Redis节点。


Redis集群架构

Redis MOVED重定向示意图



原文始发于微信公众号(落叶飞翔的蜗牛):Redis集群架构

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/20720.html

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!