注:本文基于HBase 0.94.1的源码进行分析。本文原文连接:
http://blog.csdn.net/bluishglc/article/details/21516067,转载请著明出处!
每load一个block到cache时,都会检查当前cache的size是否已经超过了“警戒线”,这个“警戒线”是一个规定的当前block cache总体积占额定体积的安全比例,默认该值是0.85,即当加载了一个block到cache后总大小超过了既定的85%就开始触发异步的evict操作了。
evict的逻辑是这样的:遍历cache中的所有block,根据它们所属的级别(single,multi,in-memory)分拨到三个优先级队列中,队头元素是最旧(最近访问日间值最小)的那个block。对这个三队列依次驱逐对头元素,释放空间。
所以说:in-memory的block与其他类型的block并无本质上的不同,它不会长久驻留cache而不被逐出cache, 当不断有新的in-memory的block被访问,而现有in-memory cache已达到上限时,旧的in-memory block就会被替换出去,除非,所有in-memory的block的总体积小于in-memory cache。
但是in-memory的block确实不同于其他两种block的地方在于它的这个“in-memory”特征是静态指定的(
每load一个block到cache时,都会检查当前cache的size是否已经超过了“警戒线”,这个“警戒线”是一个规定的当前block cache总体积占额定体积的安全比例,默认该值是0.85,即当加载了一个block到cache后总大小超过了既定的85%就开始触发异步的evict操作了。
evict的逻辑是这样的:遍历cache中的所有block,根据它们所属的级别(single,multi,in-memory)分拨到三个优先级队列中,队头元素是最旧(最近访问日间值最小)的那个block。对这个三队列依次驱逐对头元素,释放空间。
所以说:in-memory的block与其他类型的block并无本质上的不同,它不会长久驻留cache而不被逐出cache, 当不断有新的in-memory的block被访问,而现有in-memory cache已达到上限时,旧的in-memory block就会被替换出去,除非,所有in-memory的block的总体积小于in-memory cache。
但是in-memory的block确实不同于其他两种block的地方在于它的这个“in-memory”特征是静态指定的(