集群中数据如何分区？

集群中数据如何分区？

在分布式存储中，有几种常见的数据分区规则：

方案一：节点取余分区

节点取余分区是一种简单易懂的分区方案，它使用特定的数据（如 Redis 键或用户ID）的哈希值进行取余运算：hash(key) % N，以确定数据映射到哪个节点上。

然而，该方案的主要问题是，当节点数量发生变化（例如节点的扩容或收缩）时，需要重新计算数据节点的映射关系，导致数据的重新迁移。

方案二：一致性哈希分区

一致性哈希分区将整个哈希值空间组织成一个虚拟的圆环，缓存节点的 IP 地址或主机名经过哈希取值后放置在这个圆环上。当确定某个键需要访问哪个节点时，先对键进行哈希取值，确定其在环上的位置，然后按顺时针方向在环上前进，遇到的第一个缓存节点即为所需访问的节点。

这种方案的优势在于加入和删除节点只会影响哈希环中相邻的节点，对其他节点没有影响。然而，它仍然存在以下问题：

• 缓存节点在哈希环上的分布可能不均匀，导致部分节点负载过大。
• 当某个节点发生故障时，其负责的所有访问会顺移到另一个节点上，给该节点带来压力。

方案三：虚拟槽分区

虚拟槽分区在一致性哈希分区的基础上引入了虚拟节点的概念。Redis 集群就采用了这种方案，其中虚拟节点被称为槽（slot）。槽是数据和实际节点之间的虚拟概念，每个实际节点包含一定数量的槽，每个槽包含一定范围内的哈希值数据。

在使用槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽的引入解耦了数据和实际节点之间的关系，因此增加或删除节点对系统的影响很小。以之前的示意图为例，假设系统有4个实际节点，并为其分配16个槽（编号从0到15）：

• 槽0到3位于Node1，槽4到7位于Node2，依此类推...

如果此时删除Node2，只需要重新分配槽4到7即可。例如，将槽4和槽5分配给Node1，将槽6分配给Node3，将槽7分配给Node4，数据在其他节点的分布仍然相对均衡。这种方式使得节点的加入或移除对整体数据分布的影响较小。