一、redis集群的部署模式
redis cluster是redis官方提供的分布式集群解决方案，在3.0版本正式推出，主要解决在高并发、大流量场景下单机出现的性能问题，使用数据分片的集群方式将流量进行分割，达到分而治之的目的。
以下是部署模式示意图，一般情况下集群至少保证三主+三从的部署结构，任意一个master节点故障可以提升slave节点为master节点。
与传统的通过代理进行分布式分发的方案对比，缺少了代理层，架构上更加的简单，也减少了代理层在性能上的损耗和维护上的成本。
二、数据分布方案
既然是集群的模式，就必然涉及到数据分布的问题，哪个数据应该落在哪个分区必须有明确的数据分布计算负责，一般来说应用普遍的有两种方案：
1、使用key值对节点取余分区
这种方式与数据库分库分表的方案类似，提前规划好分区数量，然后使用hash(key)%N的方式决定数据应该落在哪一个数据分区上,N为节点数量。
这种方式操作起来非常的简单，只是在数据扩容的时候，需要进行数据关系的重新映射，需要对原有的数据进行迁移，在数据量比较大的情况下很不方便。
2、虚拟槽分区
redis并没有采用节点取余分区的方式，而是采用了虚拟槽分区的方式，虚拟槽分区方案是使用哈希函数将所有的数据映射到一个固定范围的整数集合中，整数在这里被定义为slot槽，在redis cluster中范围是0～16383，集群中的每个节点负责其中一部分的slot，一般来说每个节点的slot数量比较平均，相差不大。
针对每一个数据的key，使用计算公式slot=CRC16(key)&16383计算其slot，然后根据slot在哪一个节点决定数据落在哪个分片上。
使用这种虚拟槽分区的方案有以下好处
- 无需任何代理，预案数据信息由所有的节点各自维护。
- 使用slot解除了数据和节点之间的耦合，简化了扩容和缩容的难度。
- 各节点均可提供元数据的查询，客户端直连节点可以方便的查询元数据信息进行数据路由。
三、集群扩容流程
集群的扩容就是槽和数据在redis集群中的重新分配的过程，扩容主要涉及以下流程：
- 新建redis待加入集群的节点。
- 使用cluster meet命令让节点加入集群。
- 使用虚拟槽分区的方案重新计算各个节点所负责的槽位，确定槽和数据迁移计划。
- 向目标节点发送cluster setslot {slot} importing {sourceNodeId}命令，准备导入槽的数据。
- 向源节点发送cluster setslot {slot} migrating {targetNodeId}命令，让源节点准备迁出槽数据
- 源节点循环执行cluster getkeysinslot {slot} {count}命令获取count个属于槽{slot}的key，然后通过migrate {targetIp} {targetPort} "" 0 {tiemout} keys {keys…}命令，把获取到的key通过pipeline迁移到目标节点。
- 使用cluster setslot {slot} node {targetNodeId}命令通知集群各节点迁移完成，slot的新的分配信息。
四、集群缩容流程
集群扩容的流程与扩容的流程一样都是涉及槽从一个节点被迁移到另外一个节点，不同的是集群扩容流程需要先新建新的节点，而缩容的流程则是需要下线节点，需要通知到集群中的其他节点下线节点的信息。
redis提供了redis-trib.rb工具用于通知节点下线，使用命令redis-trip.rb del-node {host:port} {downNodeId}
五、数据路由
为了保证性能，redis采用的是直连的方式，所发起请求的节点未必就是刚好对应数据槽所在的节点，所以就涉及到请求的重定向，在redis cluser模式下，客户端向某个节点发起请求，节点会根据规则计划出对应的数据所在的槽，并且根据元数据信息确定槽所在的节点，然后回复MOVED重定向错误，客户端收到这个重定向以后就知道了对应数据应该落在哪个目标节点上，于是重新向目标节点发起请求，流程示意图如下：
