虚拟槽分区
redis集群使用的是基于hash的一种分区算法，称之为虚拟槽分区。
虚拟槽算法巧妙地使用了哈希空间，使用分散度良好的哈希函数将数据映射到一个固定范围内的整数集合，整数集合中的每个整数称为一个槽(slot) ，这个整数范围远远大于节点数。槽是集群内数据管理;和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽，如图所示：
当前集群有5个节点，每个节点平均大约负责3276个槽。由于采用高质量的哈希算法，每个槽所映射的数据通常比较均匀，将数据平均划分到 5个节点进行数据分区。
这种结构很容易添加或者删除 节点。如果增加一个节点 6，就需要从节点 1 ~ 5 获得部分槽分配到节点 6 上。如果想移除节点 1，需要将节点 1 中的槽移到节点 2 ~ 5 上，然后将没有任何槽的节点 1 从集群中移除即可。
由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
Redis的数据分区
Redis Cluster 采用CRC16哈希函数+取余方法将数据分为16384个数据槽中：
slot = CRC16（key）& 16383
集群中每个节点负责一部分槽以及槽所映射的键值数据。
优点
- 解耦数据和节点之间的关系，简化了节点扩容和收缩难度。
- 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据。
- 支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景。
问题
- key的批量操作命令会失效
- key的事务操作失效
- 不支持多数据库空间，只使用db0
- 复制结构只支持一层
数据定位
在redis集群启动时，需要指定每个节点各自管理的槽。当节点启动时，需要发握手命令使得节点相互连通，节点会互发管理信息。此时集群的状态为down。当节点确定所有的数据槽都有相应的节点管理时，集群状态修改为up，可以进行数据管理。
客户端只需要连接到一个节点，即可进行数据操作。该节点接收到数据命令时，会根据key计算数据槽：若归自己管理，则直接执行命令并返回结果；若不归自己管理，则发送MOVEN命令给客户端，告诉客户端相应的服务器位置，客户端重定向到正确的服务器上执行命令。
数据迁移
无论是新增还是减少一个节点，本质都是将该节点的数据迁移到另外一个或多个节点。
节点数据的迁移是以slot为单位的，具体流程：
- 在目标节点上声明将从源节点上迁入
Slot CLUSTER SETSLOT <slot> IMPORTING <source_node_id> - 在源节点上声明将往目标节点迁出
Slot CLUSTER SETSLOT <slot> IMPORTING <source_node_id> - 批量从源节点获取
KEY CLUSTER GETKEYSINSLOT <slot> <count> - 将获取的Key迁移到目标节点
MIGRATE <target_ip> <target_port> <key_name> 0 <timeout> - 重复步骤3，4直到所有数据迁移完毕
- 分别向双方节点发送
CLUSTER SETSLOT <slot> NODE <target_node_id>，该命令将会广播给集群其他节点，已经将Slot转移到目标节点。 - 等待集群状态变为OK
迁移过程并不会影响集群的状态，集群可以正常提供数据读写服务：
当一个源节点受到一条已迁移数据命令时，源节点会发送一条ASK ip port 命令给客户端，提示客户端该数据所在数据槽已迁移到目标节点，客户端会向MOVED命令一样，重定向到目标节点上执行命令。
高可用
在Redis Cluster中，每个节点都应包含一个主节点和N个从节点，当主节点挂掉时，需要从节点选举出一个从节点成为主节点，继续管理相应的数据槽。
redis的主节点选举算法为Raft算法
