Consistent Hashing

一致性哈希是一种应对系统存储架构扩展的技术,主要应用的场景提供可伸缩(根据负载动态的添加和移除)的缓存服务器,其次是对像NoSQL数据库这样的存储结点进行横向扩展。

为什么我们需要哈希一致性?
想像这样一个场景,你想去创建一个可伸缩的数据库,后台有n台数据库服务器为你的应用提供服务,就像下图展示的那样,为了简单,我们假设我们就存储键值对如:“Country : Canada”

Consistent Hashing_第1张图片
A distributed system with a cluster of database servers

我们设计的这个数据库存储系统的目标如下:

  • 我们可以统一地分配查询请求在n个数据库服务器中
  • 我们可以动态的添加和移除数据库服务器
  • 我们添加或移除数据库服务器,我们在服务器之间需要移动最小的数据量。

因此,本质上我们需要将每次请求发送到特定的服务器上,一个简单的方法如下:

  • 生成一个key(来自请求的数据中)的hash:“hashValue = HashFunction(Key)”
  • 用上步的hashValue模上当前数据库服务器的台数n,得到的值就是数据应发送到数据库服务器的编号。

让我们进一步简单例子:

  • 假设我们有4个数据库服务器
  • 假设我么的hash函数返回0到7
  • 假设“key0”传给hash函数会得到一个为0的hashValue,“key1”得到一个为1的hashValue。依次下去。
  • “key0”对应的的服务器编号为0, “key1”对应的的服务器编号为1

假设我们接收到 8分数据,并且我们的哈希函数均匀的将他们分配到了我们的四个数据库服务器上。

Consistent Hashing_第2张图片
Data-Sharding-Based-on-Modulo-number-of-servers.jpg

问题解决了,正确吗?显然没有,这种方法有两个主要的缺陷,即水平可扩展性和服务器上分布非统一数据。

水平扩展性
这个方案是无法水平扩展的,如果我们添加或者移除服务器从服务器集合中,那么所有已经存在的映射很大可能被破坏,这是因为n在函数中计算我们服务器编号。这就导致,所有已经存在的数据需要从重新去映射,并且迁移到对应的服务器上,这可能是一项艰巨的任务,因为它要么需要调度系统去停止工作,从而来更新我们的映射或者创建一个已存在系统的读备份,使得在迁移的过程中可以提供查询服务。显然,代价很大。
在下图中,当我们添加一台服务器,我们可以很快看到会发生些什么,注意和上图比较,你会发现,我们的4台服务器中,有三台需要更新。

Consistent Hashing_第3张图片
Data-Sharding-Server-Added.jpg

如下图所示,如果我们移除掉一个编号为2的服务器,那么我需要更新所有的服务器:
Consistent Hashing_第4张图片
Data-Sharding-Server-removed.jpg

我们无法保证一直来的请求数据,都很均匀的存储到每个数据库中,当某个数据库被存放了许多数据,而其他的存的相对较少,那么成该数据库为“热点数据”,。我们在一个集群中应该避免出现这样的问题,而哈希一直算法可以帮我们解决上面所阐述的一系列问题。

那哈希一致性算法是如何工作的了?
当在集群中添加或移除节点时,哈希一致性算法有助于最小化集群中数据数据的重新映射。

  1. 创建一个哈希键的空间生成的范围从0到2^32-1.并且它形成一个环形。


    Consistent Hashing_第5张图片
    HashRing.jpg
  2. 将数据库服务器放在键空间中,我们可以通过ip或ip和端口去映射出一个整数,将这个整数当作其在哈希环上的位置,如下图所示:


    Consistent Hashing_第6张图片
    Placing-DB-Servers-on-Hash-Ring.jpg
  3. 决定将key(数据的key)放在(或查询)哪个服务器上,用我们之前散列服务器的哈希函数来散列key,散列的情况有两种,一种是散列的位置没有数据库服务器,这种情况,我们顺时针的在这个圆环上找,找到的第一个服务器,将key插入到这台服务器上或查找key就在这台服务器上查找。另外,就是该位置存在服务器,则直接将数据插入到这台数据库服务器或者在这台服务器上查找查找key。
    例如,我们来了4个keys:key0,key1,key2,key3。它们的位置上没有数据库服务器,因此我们需要顺时针为其查找服务器,如下图所示:


    Consistent Hashing_第7张图片
    Key-Placement-on-Hash-Ring.jpg

    4.添加一个服务器到环中:如果我们添加一个服务器到哈希环中,我们将需要重新哈希key值,然而,我们只需要重新哈希3号服务器与4号服务器之间的key。平均而言,我们仅需要重新映射k/n个key(其中k为key的数量,n为数据库服务器数量)。这极大了减少了key重新哈希的数量。如下图所示:


    Consistent Hashing_第8张图片
    Consistent-Hashing-Adding-Servers.jpg
  4. 从环移除掉一个服务器:在生产环境中一个服务器可能会移除掉,我们的哈希一致性测量确保了受影响的服务器和key达到最小化,在下图中,我们的0号服务器移除掉,只有0和3号服务之间的key(黄色区域)需要重新映射到1号服务器上,其他的key不会受到影响:


    Consistent Hashing_第9张图片
    Consistent-Hashing-Removing-Servers.jpg

至此,哈希一致性算法已经成功的解决了水平扩展性的时,大量数据被重新映射的问题。

但是上述讨论的是,数据分布在各个数据库服务器上,当数据没有均匀分布时,容易遭成某些数据库高负载。如下图所示:


Consistent Hashing_第10张图片
Consistent-Hashing-Non-Uniform-Distribution-No-Replicas.jpg

那么我们怎么解决这个问题了,通常是为环中的每个服务器引入虚拟节点,如下图所示,0号和1号分别有两个不同的位置的虚拟节点:


Consistent Hashing_第11张图片
Consistent-Hashing-Virtual-Nodes.jpg

下图,在没有虚拟节点的情况下,1号服务器需要承担75%负载:
Consistent Hashing_第12张图片
Non-uniform key distribution in absence of virtual node in a hash ring.jpg

如果我们给每个服务器引入一个虚拟节点,那么它们将各自承担一半的责任。


Consistent Hashing_第13张图片
Consistent-Hashing-Replication-Alleviates-Hotspots.jpg

通过加入虚拟节点,可以使我们的key的分布跟家均匀,在真实的系统中,虚拟节点的数量是非常的(大于100)。至此哈希一致性算法解决了我们所有的问题。

需要记住的是:
使用哈希一致性的场景:

  • 根据负载给数据库集群动态的增加或减少数据库服务器的数量。
  • 根据负载给缓存服务器集群动态的增加或减少服务器的数量。
    使用哈希一致性的好处:
  • 带来集群的可伸缩性。
  • 带来系统的高可用性。

常用的Hash函数FNVhash函数

hash = offset
for each byte_of_data to be hashed
   hash = hash × FNV_prime
   hash = hash* XOR octet_of_data
   return hash

翻译原文:
system-design-interview-consistent-hashing

你可能感兴趣的:(Consistent Hashing)