Bitcoin Forum
May 18, 2024, 03:20:49 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: 对一致性哈希算法改进的两种可行性方案分析  (Read 113 times)
qssi6132 (OP)
Jr. Member
*
Offline Offline

Activity: 55
Merit: 10


View Profile
April 03, 2018, 03:52:03 AM
Merited by BlankZuel (4)
 #1


“一致性哈希算法的提出也伴随着新问题的出现,那就是当某一个服务器结点挂掉之后,它的任务就会分配到它的下一个服务器结点,那么这就有悖于分布式系统中需要满足平衡性的要求。”


雪崩效应

在服务器上会有一些数据会经常被访问,这些数据的访问次数远远高于其他数据,那么这些数据就被称为热点数据,理所当然在分布式服务器中承载这些热点数据的服务器的负载就要大于其他服务器。当对热点数据的访问量超过服务器的承受限度的时候,服务器就会挂掉。

按照一致性哈希算法,这个服务器的数据就会托管给下一个服务器,下一个服务器当然也无法承担这么大的请求量,不一会它也会挂掉,接着下一个服务器也会挂掉,直到最后整个服务器挂掉。这就是雪崩。

优化方案

这里有两种优化方案,第一种简单粗暴,那就是增加承载热点数据的服务器数量。另一种更好的方案是使用虚拟结点技术,这种方法的原理就是将一个物理结点拆分问多个虚拟结点,让这些虚拟结点均匀的分布在哈希环之上。这样就解决了某个结点删除后,它的数据资源分配不平衡的问题。



如图红色的结点3就相当于承载热点数据的服务器,右图中把每个物理结点拆分为了两个虚拟结点,并均匀的分布在哈希环之上。

这种解决方案的优势是与此同时也解决了当增加结点时,新结点从其他节点拉取资源后导致的结点资源分布不均问题。

例如,有ABD三个结点分配一百个资源,当要在BD之间加入一个结点C的时候,C结点会直接从D结点拉取相应的结点,这就会导致AB分配的资源肯定要多于CD所分配的资源,这也就不满足服务器的负载均衡的要求。而当插入一个物理结点时把它拆分为几个虚拟结点并均匀分布在哈希环之上就可以解决这个问题。

时间复杂度

做到这一步好像一致性哈希已经很完美了,但是我们还忽略了一个问题,那就是一致性哈希的查找时间复杂度。一致性哈希不像普通哈希,时间复杂度是0(1),这是因为普通的哈希是基于数组的,而一致性哈希为了满足可伸缩性一般会选择链表作为基础数据结构。那么时间复杂度就会变为O(N)。

优化方案

这里O(N)的时间复杂度对于哈希算法是不能忍受的,在这里我们使用一种叫做跳转表的技术来解决这个问题。



如上图在这个跳转表中,每个结点记录距离自己 1,2,4 距离的数字所存的结点,这样不管查询落在哪个节点上,对整个哈希环上任意的查询一次都可以至少跳过一半的查询空间,这样递归下去很快就可以定位到数据是存在哪个结点上。这样时间复杂度就降为了O(logN)。但是这样也同样会带来一个问题就是会占用服务器的存储空间。

第二种解决方案就是不选用链表作为基础的数据结构,换成二叉查找树结构。因为哈希查找的过程实际上就是在二叉树中查找不小于查找数的最小数值的过程,所以我们可以按照需求选取AVL树,红黑树作基础数据结构。这样也可以降低时间复杂度到O(logN)。
BlankZuel
Member
**
Offline Offline

Activity: 66
Merit: 10


View Profile
April 03, 2018, 04:52:12 AM
 #2

是一篇很不错的干货啊 难的
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!