满怀忧思，不如先干再说！

本文章为系列文章，如需系统观看请按照文章顺序阅读，如有所了解，解决针对性问题，可直接阅读，谢谢支持！用到Redis版本为5.X

说在前头

本文涵盖大量理论和原理性知识，适合收藏反复阅读
如果纯粹搭建集群，暂且对理论和原理不感兴趣，可直接阅读 【快速配置】章节

为什么使用集群

之前我们提到redis可以实现主从复制，但是主从复制是不能实现高可用的，当数据容量或者QPS需要很大时但即使无法满足需求的。至于Redis Sentinel【哨兵模式】与Redis Cluster【集群模式】有何区别在文末说明。

并发量

Redsi官方提供的数据为10W/秒，不去计较它的准确性，但是实际使用中是可以完全达到上万，已经可以满足我们很大一部分的需求，但是有些业务可能需要更高的QPS，比如百万级的。

数据量

Redis是基于内存的数据库，机器的内存普遍在16~256G之间，如果我们的数据量有500G，比如个性化推荐系统，将用户相关的数据都存到Redis中。

解决方案

1. 配置强悍的机器，超大内存，顶级CPU等，但是成本非常高，一台节点总归有极限。
2. 分布式，添加节点。

Redis在3.0版本之后推出Redis Cluster来满足我们分布式的需求

数据分区

在学习Redis集群之前先看看数据分区的概念，就是怎么将所有的数据合理的分配到不同的节点上。常有的分区方式有顺序分区和哈希分区

顺序分区

就是将同一个范围内的数据存储到同一个Redis实例中，比如有一张用户表，我们将ID0-ID10000的，ID-10001-ID20000，以此类推，存储到同一个实例中。那么如果我们有些数据不好分区，比如有些ID是随机数，UUID等等，我们可以使用哈希分区

哈希分区

哈希分区跟范围分区相比一个明显的优点是哈希分区适合任何形式的key，而不像顺序分区一样有局限性，而且分区方法也很简单，一个公式就可以表达：id=hash(key)%nodes

其中id代表Redis实例的编号，公式描述的是首先根据key和一个hash函数（如crc32函数）计算出一个数值型的，再对Redis节点数取模，取模的目的是计算出我们要将数据存到第几台节点上！

节点取余分区

当我们Redis节点有三台，但是数据越来越多时，我们会考虑增加节点，这个时候我们建议使用多倍扩容，比如3台节点我们扩容到4台那么80%的数据会切换接点，比如从1到了2节点等现象，数据迁移变化太多，我们如果熙增到6台节点那么只有50%的数据会迁移。

总结：

1. 客户端分片：哈希+取余
2. 节点伸缩：数据节点关系变化，导致数据迁移，因为要重新计算
3. 迁移量和添加节点数量有关：建议翻倍扩容
4. 这种方式不建议使用，是一种比较古老的方式，因为当新增节点时会对大量数据造成迁移，如果你的系统很依赖缓存，那么性能必然会受到影响。

一致性哈希分区

上边说到哈希取余方式如果增加节点对数据造成的迁移比较大，一致性哈希就是解决了这种问题。我们可以将Redis保存数据认为是一个环形，Hash值有32位，0~2 ^32，将节点的IP+算法确定唯一的哈希值，之后在内存中确定节点的位置，当保存数据时，根据key进行哈希运算，顺时针确定挂载到哪台节点上。图丑见谅~~~

如果集群需要添加节点，比如在node2和node3之间添加一个node4，数据分布会变成下图

我们会发现，数据依然有迁移，本来在node3上的数据一部分迁移到了node4上，但是node1和node2没有受到影响。如果我们集群有1000台，是由原本的取余分区方式会有80%的数据迁移，为了避免我们使用双倍扩容，也就是再添加1000台节点达到50%数据迁移的效果，很显然添加这么多的节点是不合适的！！！这种分区方式在memCache中使用。

Redis哈希槽

上边我们介绍了顺序分区和hash分区，而Redis Cluster并没有使用其中的任何一种（坑爹呢，上边叨X叨半天），Redis而是引入了哈希槽的的概念，Redis内置了16384个槽，从0-16383。每个节点都维护一个范围的哈希槽，当有新的key需要添加时，会使用CRC16算法并且对16384取余，公式：CRC16(key) & 16384。得到一个值，去找Redis集群中的节点，看看这个槽是哪个节点维护的，就将key存储到哪个节点上。

到这里我们知道有顺序分区，哈希分区，哈希分区包含节点取余和一致性哈希。memCache分布式使用一致性哈希，Redis集群中使用的是哈希槽的方式存储数据。 我们接下来说一下Redis集群的架构和搭建方式。

Redis集群架构

单体架构

单体架构如下图所示，只有一个Redis实例，多个客户端都在操作同一个Redis，数据存储量，访问量，数据备份上都是有问题的

Redis Cluster架构

说明

下图是分布式架构，蓝色圆圈是Redis实例，这里有五个，之前说Redis集群中存储数据通过槽的概念，会讲16384个槽平均到5台节点上，节点之间看到了有双向箭头指向，这代表他们之间是相互通信的，每个节点都知道对应的槽是哪个节点负责。下方的绿色客户端可以去操作Redis集群中可用的节点。如果客户端要找的数据在该节点上就会返回数据，如果不在会响应客户端新的节点地址，做一个转发操作，去新的节点上获取数据。当然这种方式效率不高，当节点多时，命中率不会很高，需要智能客户端，这个后边再说。

在分布式模式下节点之间会相互通信 每个节点都负责读写，每个节点负责数据的一部分

节点间通信

节点间使用meet命令进行通信，比如A向C发送meet命令，C会反馈给A一个PONG，A给B发送meet，B反馈给A一个PONG，这样B和C也能得知对方的存在。

节点更多时如下

指派槽

比如我们的Redis Cluster有三台节点，我们需要给三台节点分配槽，如下图，而客户端则需要使用公式计算结果将key存储在对应的节点上。

Redis集群配置和启动

Redis集群配置有原生配置、官方提供的ruby插件配置方式和redis5.0之后的快捷配置，我们这里三种方式我们说明第一种和第三种，原生配置比较麻烦，但是可以让你体验到Redis Cluster架构和整个流程，实际应用中使用快捷方式配置即可。

原生配置方式

步骤

1. 配置开启Redis，这种情况每台节点都是独立的；
2. 执行meet操作，让Redis集群之间感知到其他节点的存在；
3. 分配槽；
4. 设置主从关系，我们这里一共6台节点，3主3从。

Redis配置和启动

我们的配置文件从redis-7000.conf到redis-7005.conf，每个配置文件中端口和日志文件名不一样，只贴出redis-7000.conf配置文件

port 7000
daemonize yes
logfile "7000.log"
dir "/usr/local/redis-5.0.5/data/"
protected-mode no
dbfilename dump-7000.rdb
# 开启集群
cluster-enabled yes
# 集群运行时文件
cluster-config-file nodes-7000.conf
# 是否集群所有的节点都正常集群才可使用，改为no
cluster-require-full-coverage no

启动Redis6个节点，在查看进程，发现端口后边都有cluster标记

我们随便进入一个节点添加数据会发现，提示我们集群下线，没有提供哈希槽！请回头看我们的步骤。至此我们第一步和第二步就完成

接下来我们到data目录下发现有nodes开头的文件，这就是我们在redis配置文件中配置的，我们输出一下文件内容，绿色下划线的分别是该节点的ID和自己的状态为master。

meet操作实现节点握手

命令：redis-cli -p port cluster meet 目标节点ip 目标节点port

查看状态命令：

redis-cli -p 7000 cluster info 

发现节点个数为6个

那么这里给大家留个问题，至此我们可否向redis中存储数据呢？

指派槽

集群规划为7000,7001,7002是主节点，7003是7000从节点，7004是7001从节点，7005是7002从节点

7000：0-5461

7001：5462-10922

7002：10923-16383

分配槽命令：redis-cli -p port cluster addslots slot

我们有16384个槽，一个一个分配是很慢的，所以我们编写一个脚本来分配！

分配槽脚本

start=$1
end=$2
port=$3
for slot in `seq ${start} ${end}`
do
  echo "slot:${slot}"
  redis-cli -p ${port} cluster addslots ${slot}
done

执行命令

addslots.sh 0 5461 7000

addslots.sh 5462 10922 7001

addslots.sh 10923 16383 7002

进入到7000端口实例执行cluster nodes命令看到槽已分配好，大家就可以向Redis中添加数据了

主从分配

根据指派槽哪里说得主从关系我们使用以下命令进行分配

命令

redis-cli -p 从节点port cluster replicate 主节点ID

主节点ID就是上图最前边的那一串字符

redis-cli -p 7003 cluster replicate cb436d72cee8f6547e0dc002c9342dd27087bdcc 
redis-cli -p 7004 cluster replicate 03717034bca9c03e40cf4c1a4041c94f79e209d8
redis-cli -p 7005 cluster replicate c0167209ceb9fa350704781a1a53432a61f92a8c

在执行cluster nodes命令会发现已经变成3主3从，如下图

注意：如果启动集群模式的客户端需要使用redis-cli -c -p 7003命令加上了-c参数！

至此我们的原生方式已经搭建完成，很复杂，但是可以看到Redis Cluster的整个实现流程，对大家理解Redis Cluster更有帮助，希望大家可以自己动手跟着做一遍！有问题的可以下方留言！

快速配置

redis5.0集群创建方式改为了C编写的redis-cli创建，不用再安装麻烦的ruby了。ruby方式大家感兴趣可以到网上搜索，这里就不说了配置和之前一样就是将7000端口改为8000，以此类推为了区别，大家在配置的时候建议先将redis都停掉，还是3主3从的方式，下边只贴出8000的配置

配置文件

port 8000
daemonize yes
logfile "8000.log"
dir "/usr/local/redis-5.0.5/data/"
protected-mode no
dbfilename dump-8000.rdb
# 开启集群
cluster-enabled yes
# 集群运行时文件
cluster-config-file nodes-8000.conf
# 是否集群所有的节点都正常集群才可使用，改为no
cluster-require-full-coverage no
# 节点请求超时时间 
cluster-node-timeout 15000
# 关闭保护模式
protected-mode no

启动节点

分别启动6台节点，查看进程

配置集群

直接使用以下命令即可，前边三台是主节点，后边三台是从节点，如要操作请先看下方蓝色字体部分，有坑！

redis-cli --cluster create 192.168.11.101:8000 192.168.11.101:8001 192.168.11.101:8002 192.168.11.101:8003 192.168.11.101:8004 192.168.11.101:8005 --cluster-replicas 1 

大家这里一定要注意上边create创建集群时，一定要写具体的节点ip，不要写127.0.0.1，否则在你使用Java操作Redis Cluster时会去连接127.0.0.1的节点，比如：你在Centos上部署的redis集群，你的开发环境实在window下，那么他就会操作你window下的redis，然而并没有！当时我这里也是出了问题，搞了将近2个小时才找到！

下图为分配槽、配置主从的过程是可以看出来的

查看集群情况

可以看出3主3从，操作和之前都一样

哨兵模式和集群有何区别

1. 哨兵模式需要开启sentinel进程主要作用是监控Redis节点的运行状态，如果主数据库发生故障则切换到从数据库，sentinel发现master挂掉之后再重新选举出一个新的master，主要是监控，提醒和故障转移，实现Redis的高可用；
2. 哨兵模式客户端不会记录具体的master节点的ip，而是记录sentinel节点，我们从sentinel节点获取redis的地址，上节我们用代码演示过；
3. 哨兵模式存储数据都是全量存储，每个Redis存储的都是完整的数据，浪费内存而且存在木桶效应，为了最大化利用内存，我们可以使用分布式存储，采用集群。即每台节点存储不同的数据，共有16384个slot；
4. 集群最少3主3从，且主从不用配置，集群会自己分配（参考我们的第二种搭建方式）；
5. 集群模式为了解决单机Redis容量有限的问题，将数据按照一定的规则分配到多台机器，提高并发。

如果不错记得关注，点赞哦！无偿提供编程咨询服务，如有需要可私信