1 集群模式

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

1.1 集群的优点

负载均衡（降低单台Redis服务器的访问压力）
可拓展性（降低单台Redis服务器的存储压力）
容灾处理

1.2 集群模式实现的三种方式

我们一般要实现一个Redis集群，可以有三种方式：客户端实现、Proxy代理层、服务端实现。

1.2.1 客户端实现

　　我们通过代码的实现方式，实现集群访问，如下图所示：

　　这样的访问方式都通过代码来维护集群以及访问路径，可是这样的方式维护难度大，也不支持动态扩容，因为一切都以代码实现访问规划。

1.2.2 Proxy代理层

　　如图所示：

　　我们在Redis和我们的客户端之间新加了一层Proxy，我们通过Proxy去规划访问，这样我们在代码层面以及Redis部署层面就无需处理，而且市面上也提供了这样的中间件，如Codis(国产)、Twemproxy。我们看下Codis的架构图，就可以知道这个插件是如何工作的，如图所示：　　　　

　　可见Codis是一个很完善的集群管理实现，我们可以不关心具体分片规则，程序开发容易简单，可是这样也有它的一些缺点：

相对单机、主从、哨兵可以看到，原先可以直接访问Redis，现在由于多了一层Proxy，所有访问要经过Proxy中转，性能下降。
我们需要依赖以及配置额外的插件(中间件)，增加了系统复杂度。

　　Codis的GitHub地址：https://github.com/CodisLabs/codis

　1.2.3服务端实现

　服务端的实现方式就是标准的集群(分区分片)模式，RedisCluster是Redis在3.0版本后推出的分布式解决方案。

　1.2.3.1 集群结构

　　Cluster模式实现了Redis的分布式存储，即每台节点存储不同的内容，来解决在线扩容的问题。如图：

　　RedisCluster采用无中心结构,它的特点如下：

所有的redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连，不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

1.2.3.2 集群部署架构

为了保证集群的高可用，每个master节点下面还需要添加至少1个slave节点，这样当某个master节点发生故障后，可以从它的slave节点中选举一个作为新的master节点继续提供服务。不过当某个master节点和它下面所有的slave节点都发生故障时，整个集群就不可用了。这样就组成了下图中的结构模式：

为什么需要三主三从?

因为内部存在一个投票机制，节点的有效性是需要靠投票的，一个节点无法给自己投票，两个节点互相都连不上,A=>B,B=>A互相都说对方挂了没有定论.三个节点才能满足投票的需求。

1.3 Redis集群工作机制

1.3.1 具体工作机制

　　Cluster模式的具体工作机制：

Redis集群中引入了哈希槽的概念，在Redis的每个节点上，都有一个插槽（slot），总共16384个哈希槽，取值范围为0-16383。如下图所示，跟前三种模式不同，Redis不再是默认有16(0-15)个库，也没有默认的0库说法，而是采用Slot的设计(一个集群有多个主从节点，一个主从节点上会分配多个Slot槽，每个槽点上存的是Key-Value数据):

当我们存取key的时候，每个key会通过CRC16校验后再对16384取模来决定放置在哪个槽，搭建Redis集群时会先给集群中每个master节点分配一部分哈希槽。比如当前集群有3个master节点，master1节点包含0~5500号哈希槽，master2节点包含5501~11000号哈希槽，master3节点包含11001~16384号哈希槽，当我们执行“set key value”时，假如 CRC16(key) % 16384 = 777，那么这个key就会被分配到master1节点上，如下图：

为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。
当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了

　　Cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。关于集群中的涉及动态选举的机制，请参考地址：Raft

1.3.2 Redis集群中节点的通信

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

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

MEET：当需要向集群中加入新节点时，需要集群中的某个节点发送MEET消息到新节点，通知新节点加入集群。新节点收到MEET消息后，会回复PONG命令给发送者。
PING：集群内每个节点每秒会向其他节点发送PING消息，用来检测其他节点是否正常工作，并交换彼此的状态信息。PING消息中会包括自身节点的状态数据和其他部分节点的状态数据。
PONG：当接收到PING消息和MEET消息时，会向发送发回复PONG消息，PONG消息中包括自身节点的状态数据。节点也可以通过广播的方式发送自身的PONG消息来通知整个集群对自身状态的更新。
FAIL：当一个节点判定另一个节点下线时，会向集群内广播一个FAIL消息，其他节点接收到FAIL消息之后，把对应节点更新为下线状态。

1.3.3 Redis集群的MOVED重定向

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节点。

1.4 集群模式优缺点　　

　　优点：

无中心架构；
数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；
可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除；
高可用性：部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升；
降低运维成本，提高系统的扩展性和可用性。

　　缺点：

Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的。
数据通过异步复制，不保证数据的强一致性。
多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率。
Key批量操作限制，如使用mset、mget目前只支持具有相同slot值的Key执行批量操作。对于映射为不同slot值的Key由于Keys不支持跨slot查询，所以执行mset、mget、sunion等操作支持不友好。
Key事务操作支持有限，只支持多key在同一节点上的事务操作，当多个Key分布于不同的节点上时无法使用事务功能。
Key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点。
不支持多数据库空间，单机下的redis可以支持到16个数据库，集群模式下只能使用1个数据库空间，即db 0。
复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
避免产生hot-key，导致主库节点成为系统的短板。
避免产生big-key，导致网卡撑爆、慢查询等。
重试时间应该大于cluster-node-time时间。