通过Key查找Volume的相关过程分析

TS把若干个物理硬盘、目录(通过storeage.config描述),视为一个大的逻辑盘。并把这个逻辑盘,切分为若干个逻辑卷(通过volume.config描述)。

当一个请求过来,这个请求的URL等信息,将被计算出一个md5值,而key则是这个md5值的一个函数:key = fun(md5)。TS需要为每一个请求,关联到一个逻辑卷,以便从这个逻辑卷访问Cache内容。这个过程,就是通过key查找Volume的过程。为了确保高效,key=>Volume的映射保存在一张hash_table中:通过对key取模,映射到hash_table的某个slot,并从这个slot中取出Volume的序号。因此,查找的速度为O(1)。

问题的关键在于,如何生成、维护这张hash_table。这个哈希表,应该满足三个条件:
*条件1、因为逻辑卷(Volume)的Size是各异的,应该根据Volume的Size成比例的映射的hash_table的slot上。即是说,较大的Volume,应该占有哈希表较多的slot。
*条件2、应该让同一个Volume所占据的slots,随机地分布在hash_table上。这样有一个好处,可以确保相似的key,被分流到不同的Volume中,如果这些Volume恰好在不同的物理硬盘(这取决于Volume与物理硬盘的映射关系,我还没有读到相关代码),就能够并行的读写,提高IO访问速度。
*条件3、摘除或添加物理硬盘,会引起Cache数据的“重新均衡”,但一个好的hash算法,应该尽量减少这个均衡过程的代价。

下面将介绍TS是如何满足这三个条件的。
1)满足条件1:
设所有逻辑卷的大小T、hash_table的slot数为N,通过一个比例转换,可以计算数出每个Volume在hash_table中应占用的slot数:
      nr_slots = Volume.size * N/T

2)满足条件2:
为了把某个Volume所占有的slot打散到hash_table上,TS使用每个Volume自身的md5作为一个随机数的种子,然后通过简单的求模,计算出第一个slot的位置,并生成下一个随机数,再次求模,计算出第二个slot的位置。循环这个过程,直到找出所有slot。如果发现某个slot已经被前面的Volume占用,则跳过该slot,继续查找下一未被占用的slot。

通过以上两步,在物理硬盘不发生变化的情况下,已经实现了一个简单且分布性较随机的hash_table,可以高效的把key映射到某个Volume上。

3)满足条件3:
当物理硬盘发生变化时,Volume与物理硬盘的映射关系,也可能发生变化(https://issues.apache.org/jira/browse/TS-949 大概是想解其中的一个bug?尚未完全理解)。而物理硬盘的变化,并不会改变volume.config的配置,所以物理硬盘的变化,并不直接影响逻辑卷在hash_table的分布(但如果物理硬盘的变化,使某个Volume被标识为不可用,则会影响)。从以上分析来看,满足条件3的关键,在于Volume与物理硬盘的映射关系。以上的分析,使我们可以在一个更小的范围内,来满足条件3,即只要关注Volume与物理硬盘的映射关系即可:D。

展开阅读全文

没有更多推荐了,返回首页