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那样的性能,在高负载的情况下可能会导致不可预料的错误。