数据分区方案：
数据分区有顺序分区、哈希分区等，其中哈希分区由于其天然的随机性，使用广泛；redis集群的分区方案就是哈希分区的一种。
哈希分区的基本思路：对数据的特征值（如key）进行分区，然后根据哈希值决定数据落在哪个节点。常见的哈希分区包括：哈希取余分区，一致性哈希分区，带虚节点的一致性哈希分区等。
衡量数据分区方法的好坏标准很多，其中比较重要的两个因素是：（1）数据分布是否均匀（2）增加或删除节点对数据分区的影响。由于哈希的随机性，哈希分区基本可以保证数据分部均匀；因此在比较哈希分区方案时，重点是看增减节点对数据分布的影响。
（1）哈希取余分区
哈希取余分区的思路：计算key的hash值，然后对节点数量进行取余，从而决定数据映射到哪个节点上。该方案最大的问题是，当新增或者删除节点时，节点数量发生变化，系统所有的数据都需要重新计算映射关系，引发大规模数据迁移。
（2）一致性哈希分区
一致性哈希分区算法将整个哈希值空间组织成一个虚拟的圆环，如下图所示，范围为0-2^32-1；对于每个数据，根据key计算hash值，确定数据在环上的位置，然后从此位置沿环顺时针行走，找到的第一台服务器就是其应该映射到的服务器。
与哈希取余分区相比，一致性哈希分区将增减节点的影响限制在相邻节点。以上图为例，如果在node1和node2之间增加node5，则只有node2中的一部分数据会迁移到node5；如果去掉node2，则原node2中的数据只会迁移到node4中，只有node4会受影响。
一致性哈希分区的主要问题在于，当节点数量较少时，增加或删减节点，对单个节点的影响可能很大，造成数据的严重不平衡。还是以上图为例，如果去掉node2，node4中的数据由总数据的1/4左右变为1/2左右，与其他节点相比负载过高。
（3）带虚拟节点的一致性哈希分区
该方案在一致性哈希分区的基础上，引入虚拟节点的概念。Redis集群使用的便是这种方案，其中的虚拟节点称为槽（slot）。槽是介于数据和实际节点之间的虚拟概念；每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。引入槽后，数据的映射关系由数据hash->实际节点，变成了数据hash->槽->实际节点。
在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系，增加或删除节点对系统的影响很小。仍以上图为例，系统中有4个实际节点，假设为其分配16个槽(0-15)； 槽0-3位于node1，4-7位于node2，以此类推。如果此时删除node2，只需要将槽4-7重新分配即可，例如槽4-5分配给node1，槽6分配给node3，槽7分配给node4；可以看出删除node2后，数据在其他节点的分布仍然较为均衡。
槽的数量一般远小于2^32，远大于实际节点的数量；在Redis集群中，槽的数量为16384。
（1）Redis对数据的特征值（一般是key）计算哈希值，使用的算法是CRC16。
（2）根据哈希值，计算数据属于哪个槽。
（3）根据槽与节点的映射关系，计算数据属于哪个节点。
