Redus Cluster

前言

我们知道Redis官方给出Redis的QPS能达到10W/s，这是一个非常快的速度，但是如果这样的数据还无法满足我们的需求，比如100W/s。其次，我们业务需要很大的内存存储用户数据，这样我们Redis在单机模式也是无法满足的。我们需要如何解决？

在单机器无法满足需求的时候，我们就会想到多机器来管理，Reids为我们提供了Cluster去能让我们能管理我们的机器，也就是集群管理。

Cluster 在 Redis 3.0 提供

数据分布

当我们单机器无法满足需求时我们就可以使用多机器，数据存在不同的机器这就引出了一个问题，我们数据如何分区才能使效率更高。这有点像HashMap里的hash函数，都是为了解决数据操作效率。

• 1、顺序分布
  假设我们有三个节点，我们就平均的将节点分成三份

• 2、哈希分布
  同样三个节点，我们取hash(key)%3来存取

• 3 对比

  分布方式	特点	典型产品
  哈希分布	数据分散度高、键值分布业务无关、无法顺序访问、支持批量操作	一致性哈希Memccache、Redis Cluster
  顺序分布	数据分散度易倾斜、键值业务相关、可顺序访问、支持批量操作	Big Table、Hbase

因为Redis Cluster是哈希分布的，所以我们下面对其做详细说明。
哈希分布主要有三种方式：

• 节点取余分区
  
  虽然节点取余方法比较简单，但是也有很大的一个缺点，就是如果我们这是需要添加一个节点，那么我们就需要数据就会做很多的偏移。所以为来缓解这个缺点，我们可以参考HashMap的一个扩容机制，节点控制在2^n并且每次扩容扩大两倍，这样节点的迁移能把迁移量控制在50%。

• 一致性哈希分区
  
  我们把节点数据想象成一个环，每个节点管理环的一个部分。比如说我们对键取hash之后落到图中的黄色位置，这是将按照顺时针方式寻找第一个节点，也就是图中黄色位置的节点就归n2节点管理。
  这样有什么好处呢，它有效的避免了节点取余的缺点，比如这时我们添加一个节点。
  
  我们添加节点之后只需要迁移n2的数据，并不会影响到其他节点的数据！
  当然这样也还是会有问题，看图就知道这样添加节点会影响数据的分布了，所以还是建议翻倍伸缩，这样才能保证数据的均衡分布。

• 虚拟槽分区（Redis Cluster使用）
  使用预设虚拟槽的方式，每个槽映射一个数据子集。这是什么意思？
  比如说我有100W个数据，Redis提供给我们默认16384个槽，我们会把100W对16383取余得到每个槽管理的数据，之后当数据进来时使用hash函数CRC16进行hash处理分配到对应的槽。

  虚拟槽分区是服务端控制管理节点，而其他两种方式都是通过客户端进行管理

  
  上面就是虚拟槽分配的工作原理，分配规则我们上面已经讲过了。现在讲讲具体存储过程。
  当keys进来时，我们通过hash函数CRC16进行处理，在对16383取余就可以知道这个keys是属于哪个槽了，之后我们将数据发给Redis Cluster的任意一个节点，首先发送的节点会进行判断这个keys是不是属于我管理的槽，如果是就存下来，如果不是，则会通知你是哪个槽管理的，之后在去寻找对应的槽即可。

  Redis Cluster使用消息共享的模式，所以每个节点都知道其他节点所管理的槽

集群搭建

我们先看看Redis Cluster的架构

在上图中，我们看到每个节点都是可以相互通信的，所以我们客户端存储的时候对其中一个节点进行请求，都可以得到相应节点的回复。

搭建Redis Cluster

• 1 分配节点
• 2 meet操作（使各个节点能相互通信）
  
• 3 指派槽
• 4 复制（提供高可用）

集群伸缩

• 伸缩原理
  
  集群的伸缩通过Redis Cluster管理，比如图右侧，我们添加了一个节点，Redis Cluster就会帮我们进行meet，和槽的转移等等操作。

  集群伸缩 = 槽和数据在节点之间的移动

• 扩容集群
  • 准备节点
  • 加入集群（进行meet操作）
  • 迁移数据
    
• 缩容集群
  

客户端操作

• moved重定向

  • 槽未命中
    
  • 槽命中
    

• ask重定向
  当访问数据节点时发现数据已经迁移了
  
  同样的原理
  

• moved 和 ask

  • 两者都是客户单重定向
  • moved：槽以确定迁移
  • ask：槽还在迁移中

• smart客户端
  我们客户端可以缓存节点信息，这样就不用每次都需要到服务端进行计算节点了，具体的过程如下：