redis cluster集群架构详解(八)-redis cluster设计目标

redis 具备Cluster功能后,Redis从一个单纯的NoSQL内存数据库变成了分布式NoSQL数据库,CAP模型也从CP变成了AP。也就是说,通过自动分片和冗余数据,Redis具有了真正的分布式能力。某个结点挂了,因为数据在其他结点上有备份,所以其他结点可以继续提供服务,保证了Availability。然而,也正因为这一点,Redis无法保证曾经的强一致性了。这也是CAP理论要求的,三者只能取其二。

5.1. redis cluster设计目标

在官方文档Cluster Spec中,作者详细介绍了Redis集群为什么要设计成现在的样子。最核心的目标有三个:

1、性能:这是Redis赖以生存的看家本领,增加集群功能后当然不能对性能产生太大影响,所以Redis采取了P2P,而非Proxy方式,客户端重定向,异步复制,即Master与slave之间使用异步replication,且不存在操作的merge(即操作不能跨多个nodes,不存在merge层)等设计。牺牲了部分的一致性。
2、水平扩展:集群的最重要能力当然是扩展,redis cluster 文档描述可以线性扩展到1000结点。
3、数据一致性:一定程度上保证writes的安全性,需要客户端容忍一定程度的数据丢失。集群将会尽可能(best-effort)保存客户端write操作的数据;通常在failover期间,会有短暂时间内的数据丢失(因为异步replication引起);当客户端与少数派的节点处于网络分区时(network partition),丢失数据的可能性会更高。(因为节点有效性检测、failover需要更长的时间)。

4、可用性

(1)具备监控和自动Failover能力:在Cluster推出之前,可用性要靠Sentinel保证。有了集群之后也自动具有了Sentinel的监控和自动Failover能力。

(2)将slaves的分布在整个集群相对平衡。:“replicas migration”可以将那些拥有多个slaves的master的某个slave,迁移到没有slave的master下,即将slaves的分布在整个集群相对平衡,尽力确保每个master都有一定数量的slave备份。

(3)高可用:只要集群中大多数master可达、且失效的master至少有一个slave可达时,集群都可以继续提供服务。

Redis Cluster功能特点如下:

1、节点自动发现:所有的节点相互连接。

2、集群消息通信通过集群总线通信,集群总线端口大小为客户端服务端口+10000,这个10000是固定值。

3、节点与节点之间通过二进制协议进行通信。

4、客户端和集群节点之间通信和通常一样,通过文本协议进行。

5、集群节点不会代理查询。

6、数据按照Slot存储分布在多个Redis实例上。

7、集群节点挂掉会自动故障转移。

8、可以相对平滑扩/缩容节点。
9、Cluster不能进行跨Nodes操作,也没有nodes提供merge层代理。

10、Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误。

发布了155 篇原创文章 · 获赞 23 · 访问量 11万+

猜你喜欢

转载自blog.csdn.net/makyan/article/details/104798317