本文会对Redis分布式集群方案做一个介绍，有关主从复制和哨兵机制详解参考：http://zrkworld.com/archives/redis-zhu-cong-fu-zhi-sentinel-xiang-jie
概述
在 Redis 3.0 之前，集群方案一般为两种：
-
客户端分区方案
-
代理方案
3.0 之后官方提供了专有的集群方案 Redis Cluster
将数据集分散到多个节点上，每个节点负责整体的一部分，即为数据分区。分区就会涉及到分区规则，Redis 常用的是哈希分区规则，哈希分区规则比较常见的有
- 节点取余分区
- 一致性 hash 算法
- 虚拟槽分区
客户端分区
也叫客户端分片（Smart Client）如下图所示，为一个客户端分区方案。
通过 sentinel 实现集群高可用，分区逻辑在客户端实现
- 优点是：分区逻辑可控。
- 缺点是：需要自己处理数据路由、高可用、故障转移等问题。
分区规则可用 节点取余 hash
节点取余 hash
节点取余方式优点
- 配置简单：对数据进行哈希，然后取余
节点取余方式缺点：
-
数据节点伸缩时，导致数据迁移
-
迁移数量和添加节点数据有关，建议翻倍扩容
代理方案
代理分区方案一般由中间件实现 例如早已开源的 Codis，下图是 Codis 的架构图：
codis-proxy 是无状态的，可以比较容易的搭多个实例，达到高可用性和横向扩展。
对 Java 用户来说，可以使用基于 Jedis 的实现 Jodis ，来实现 proxy 层的 HA：
-
它会通过监控 zookeeper 上的注册信息来实时获得当前可用的 proxy 列表，既可以保证高可用性；
-
也可以通过轮流请求所有的 proxy 实现负载均衡。
这种方案有很多优点，因为支持原生 redis 协议，所以客户端不需要升级，对业务比较友好。并且升级相对平滑，可以起多个 Proxy 后，逐个进行升级。
Codis 是一个分布式 Redis 解决方案，对于上层的应用来说，连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别 （不支持的命令列表）, 上层应用可以像使用单机的 Redis 一样使用，Codis 底层会处理请求的转发，不停机的数据迁移等工作，所有后边的一切事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的 Redis 服务。
但是缺点是，因为会多一次跳转，会有性能开销。
这里我们再讨论另外一种 分区规则：一致性 hash 算法
一致性 hash 算法
上面讨论的节点取余分区方式的主要缺点是：数据节点伸缩时，导致数据迁移，换句话说，当缓存服务器数量发生变化时，可能会导致大量缓存同一时间失效，几乎所有缓存的位置都会发生改变。 所以 迁移数量和添加节点数据有关，建议翻倍扩容
一致性 hash 算法在一定程度上解决了这个问题，它的实现思路是：为系统中每个节点分配一个 token, 范围是 0 到 2 的 32 次方，这些 token 构成一个哈希环，如下图所示。
每一个数据节点分配一个 token 范围值，这个节点就负责保存这个范围内的数据。数据读写执行节点查找操作时，先根据 key 计算 hash 值，然后顺时针找到第一个大于等于该哈希值的 token 节点（沿顺时针方向遇到的第一个服务器）。
优点：
- 服务器的数量如果发生改变，并不是所有缓存都会失效，而是只有部分缓存会失效
缺点：
-
加减节点会造成哈希环中部分数据 无法命中，需要手动处理或者忽略这分部数据。
-
当使用少量节点 时，节点变化将大范围影响哈希环 中数据映射，不适合少量数据节点 的分布式方案。
-
普通的 一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡。
上述缺点中第二、三点尤其重要，原因是缓存分布的极度不均匀（负载不均衡），这种情况被称之为 hash 环的偏斜
应该怎样防止 hash 环的偏斜呢？一致性 hash 算法中使用“虚拟节点”解决了这个问题。
“虚拟节点”是”实际节点”（实际的物理服务器）在 hash 环上的复制品，一个实际节点可以对应多个虚拟节点。
例如：我们以 2 个副本 NodeA、NodeB 为例，为每台服务器计算三个虚拟节点，于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值，于是形成六个虚拟节点：
当然，如果你需要，也可以虚拟出更多的虚拟节点。引入虚拟节点的概念后，缓存的分布就均衡多了。hash 环上的节点就越多，缓存被均匀分布的概率就越大。
Redis Cluster
Redis Cluster 集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。自动将数据进行分片，每个 master 上放一部分数据，提供内置的高可用支持，部分 master 不可用时，还是可以继续工作的
集群由 N 组主从 Redis Instance 组成。主可以没有从，但是没有从 意味着主宕机后主负责的 Slot 读写服务不可用。一个主可以有多个从，主宕机时，某个从会被提升为主，具体哪个从被提升为主，协议类似于 Raft。
如何检测主宕机？
Redis Cluster 采用 quorum+心跳的机制。从节点的角度看，节点会定期给其他所有的节点发送 Ping，cluster-node-timeout（可配置，秒级）时间内没有收到对方的回复，则单方面认为对端节点宕机，将该节点标为 PFAIL 状态。通过节点之间交换信息收集到 quorum 个节点都认为这个节点为 PFAIL，则将该节点标记为 FAIL，并且将其发送给其他所有节点，其他所有节点收到后立即认为该节点宕机。从这里可以看出，主宕机后，至少 cluster-node-timeout 时间内该主所负责的 Slot 的读写服务不可用。
与 Sentinal 的区别？
Redis Sentinal 着眼于高可用，在 master 宕机时会自动将 slave 提升为 master，继续提供服务。
Redis Cluster 着眼于扩展性，在单个 redis 内存不足时，使用 Cluster 进行分片存储。
详情参考文章：
http://zrkworld.com/archives/fen-bu-shi-redis-jie-jue-fang-an--gai-shu-ban-
虚拟槽分区
Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，计算公式 slot = CRC16(key) & 16383，每个节点负责维护一部分槽以及槽所映射的键值数据。采用大范围槽的主要目的是为了方便数据拆分和集群扩展
当前集群有 5 个节点，每个节点平均大约负责 3276 个槽。由于采用高质量的哈希算法，每个槽所映射的数据通常比较均匀，将数据平均划分到 5 个节点进行数据分区。
虚拟槽分区特点：
- 解耦数据和节点之间的关系，简化了节点扩容和收缩难度
- 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据。
- 可以对数据打散，又可以保证数据分布均匀