redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。 Redis-Cluster采用无中心结构,它的特点如下：
- 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
- 节点的fail是通过集群中超过半数的节点检测失效时才生效。
- 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
工作方式
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。
因为在集群模式下，redis各个节点保存不同的数据，如若当任何一个节点宕机，redis集群便无法提供完整的数据，redis集群停止服务，为提高redis集群的高可用，可以在redis集群模式中增加主从模式，为所有的redis节点配置从节点，备份数据，在redis主节点异常情况，从节点升级为主节点，继续提供服务
集群模式心跳
集群模式的redis各个节点之间的消息通信主要由下面方式
- ping：集群每个节点每秒向其它节点发ping，检测节点的状态信息；
- pong，作为响应消息返回给发送方，用来确认正常通信，pong消息也封闭自身状态数据；
- meet：用于通知新节点加入，发送者通知接收者加入到集群，通信完后，接收节点会加入到集群中，并进行周期性ping pong交换
- fail消息：当节点判定另一节点下线时，会向集群内广播一个fail消息，确认是否下线。需要半数的认可。
redis集群路由实现方式
redis集群模式中由于每个redis节点保存的数据不一致，这样客户端在访问存取数据时需要进行路由才能精确在节点进行操作，目前由三种方案实现。
| 集群路由方式 | 优点 | 缺点 |
|---|---|---|
| 客户自主路由 | 不使用第三方中间件，实现方法和代码可以自己掌控并且可随时调整。这种分片性能比代理式更好(因为少了分发环节)，分发压力在客户端，无服务端压力增加 | 不能平滑地水平扩容，扩容/缩容时，必须手动调整分片程序，出现故障不能自动转移，难以运维 |
| 代理路由 | 运维成本低。业务方不用关心后端 Redis 实例，跟操作单点 Redis 实例一样。Proxy 的逻辑和存储的逻辑是隔离的 | 代理层多了一次转发，性能有所损耗；进行扩容/缩容时候，部分数据可能会失效，需要手动进行迁移，对运维要求较高，而且难以做到平滑的扩缩容；出现故障，不能自动转移，运维性很差。Codis 做了诸多改进，相比于 Twemproxy 可用性和性能都好得多 |
| 集群自主路由 | 无中心节点，数据按照 slot 存储分布在多个 Redis 实例上，平滑的进行扩容/缩容节点，自动故障转移（节点之间通过 Gossip 协议交换状态信息,进行投票机制完成 slave 到 master 角色的提升）降低运维成本，提高了系统的可扩展性和高可用性 | 开源版本缺乏监控管理，原生客户端太过简陋，failover 节点的检测过慢，维护 Membership 的 Gossip 消息协议开销大，无法根据统计区分冷热数据，并且存在二次连接的风险。 |
客户自主路由
实现方式是客户端自行进行CRC16(KEY)%16384，计算对应的槽位信息，并且需要维护redis节点和槽位的对应关系。
代理路由
在客户端和redis节点之间设置代理节点，由代理节点完成槽位计算以及对应关系映射
redis自主路由
Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个Redis 节点转发到另一个 Redis节点，而是当你发送连接到某个redis节点后，节点判断对应的槽位不在本地时，返回给客户端一个move指令，告诉客户端正确的redis节点信息，在客户端的帮助下直接重定向（redirected）到正确的redis节点。客户端存在二次连接的风险。
redis集群的状态监测和故障切换
redis集群中各个节点的状态监测和故障切换如下图所示
