Redis分布式集群实战（四）——Redis cluster高可用集群的搭建部署

在前面的文章中，我们介绍了redis的主从和哨兵两种集群方案，redis从3.0版本开始引入了redis-cluster(集群)。
从 主从-哨兵-集群可以看到redis的不断完善； 主从复制是最简单的节点同步方案，但无法自动故障转移。 哨兵可以同时管理多个主从同步方案同时也可以处理主从自动故障转移，通过配置多个哨兵节点可以解决单点网络故障问题，但是单个节点的性能压力问题无法解决。 集群解决了前面两个方案的所有问题，下面我们就学习redis cluster。

一、redis集群之redis cluster

对于Redis集群方案有好多种，基本常用的就是twemproxy，codis，redis cluster这三种解决方案。Redis Cluster是Redis官方提供的Redis集群功能

1.1为什么要用Redis Cluster

除了主从复制无法自动故障转移和哨兵无法解决单个节点的性能压力问题外，还有数据量的增加，当现有服务器内存不能满足业务数据的需要时，单纯向服务器添加内存不能达到要求，此时就需要考虑分布式需求，把数据分布到不同服务器上，还有就是网络流量需求，当业务的流量已经超过服务器的网卡的上限值，就需要使用分布式来进行分流。

1.2数据分布

1、 数据分布的目的

全量数据，单机Redis节点无法满足要求，按照分区规则把数据分到若干个子集当中。

2、 常用数据分布方式之顺序分布

顺序分布常用在关系型数据库的设计.
比如：1到100个数字，要保存在3个节点上，按照顺序分区，把数据平均分配三个节点上,1号到33号数据保存到节点1上，34号到66号数据保存到节点2上，67号到100号数据保存到节点3上

3、 常用数据分布方式之哈希分布(虚拟槽分区是Redis Cluster采用的分区方式)

例如1到100个数字，对每个数字进行哈希运算，然后对每个数的哈希结果除以节点数进行取余，余数为1则保存在第1个节点上，余数为2则保存在第2个节点上，余数为0则保存在第3个节点，这样可以保证数据被打散，同时保证数据分布的比较均匀

哈希分布方式分为三个分区方式：

• 节点取余分区：比如有100个数据，对每个数据进行hash运算之后，与节点数进行取余运算，根据余数不同保存在不同的节点上
  
  优点：客户端分片,配置简单：对数据进行哈希，然后取余
  缺点：数据节点伸缩时，导致数据迁移,迁移数量和添加节点数据有关，建议翻倍扩容
  节点取余分区方式有一个问题：即当增加或减少节点时，原来节点中的80%的数据会进行迁移操作，对所有数据重新进行分布，节点取余分区方式建议使用多倍扩容的方式，例如以前用3个节点保存数据，扩容为比以前多一倍的节点即6个节点来保存数据，这样只需要适移50%的数据。数据迁移之后，第一次无法从缓存中读取数据，必须先从数据库中读取数据，然后回写到缓存中，然后才能从缓存中读取迁移之后的数据

• 一致性哈希分区: 原理： 将所有的数据当做一个token环，token环中的数据范围是0到2的32次方,然后为每一个数据节点分配一个token范围值，这个节点就负责保存这个范围内的数据。
  
  对每一个key进行hash运算，被哈希后的结果在哪个token的范围内，则按顺时针去找最近的节点，这个key将会被保存在这个节点上。

在下面的图中，有4个key被hash之后的值在在n1节点和n2节点之间，按照顺时针规则，这4个key都会被保存在n2节点上，
如果在n1节点和n2节点之间添加n5节点，当下次有key被hash之后的值在n1节点和n5节点之间，这些key就会被保存在n5节点上。
在此例子里，添加n5节点之后，数据迁移会在n1节点和n2节点之间进行，n3节点和n4节点不受影响，数据迁移范围被缩小很多，同理，如果有1000个节点，此时添加一个节点，受影响的节点范围最多只有千分之2。
一致性哈希一般用在节点比较多的时候

优点：采用客户端分片方式：哈希 + 顺时针(优化取余)；节点伸缩时，只影响邻近节点，但是还是有数据迁移
缺点：翻倍伸缩

• 虚拟槽分区:预设虚拟槽，每个槽就相当于一个数字，有一定范围。每个槽映射一个数据子集，一般比节点数大。Redis Cluster中预设虚拟槽的范围为0到16383