山西省工程建设标准定额网站,手机端网站建设郑州,新闻发稿发布平台,icp备案网站负责人RegionServer是HBase系统中最核心的组件#xff0c;主要负责用户数据写入、读取等基础操作。RegionServer组件实际上是一个综合体系#xff0c;包含多个各司其职的核心模块#xff1a;HLog、MemStore、HFile以及BlockCache。
一、RegionServer内部结构
RegionServer是HBas…RegionServer是HBase系统中最核心的组件主要负责用户数据写入、读取等基础操作。RegionServer组件实际上是一个综合体系包含多个各司其职的核心模块HLog、MemStore、HFile以及BlockCache。
一、RegionServer内部结构
RegionServer是HBase系统响应用户读写请求的工作节点组件由多个核心模块组成。 一个RegionServer由一个或多个HLog、一个BlockCache以及多个Region组成。其中HLog用来保证数据写入的可靠性BlockCache可以将数据块缓存在内存中以提升数据读取性能Region是HBase中数据表的一个数据分片一个RegionServer上通常会负责多个Region的数据读写。一个Region由多个Store组成每个Store存放对应列簇的数据比如一个表中有两个列簇这个表的所有Region就都会包含两个Store。每个Store包含一个MemStore和多个HFile用户数据写入时会将对应列簇数据写入相应的MemStore一旦写入数据的内存大小超过设定阈值系统就会将MemStore中的数据落盘形成HFile文件。HFile存放在HDFS上是一种定制化格式的数据存储文件方便用户进行数据读取。
二、HLog
HBase中系统故障恢复以及主从复制都基于HLog实现。默认情况下所有写入操作写入、更新以及删除的数据都先以追加形式写入HLog再写入MemStore。大多数情况下HLog并不会被读取但如果RegionServer在某些异常情况下发生宕机此时已经写入MemStore中但尚未flush到磁盘的数据就会丢失需要回放HLog补救丢失的数据。此外HBase主从复制需要主集群将HLog日志发送给从集群从集群在本地执行回放操作完成集群之间的数据复制。
1HLog文件结构 1每个RegionServer拥有一个或多个HLog默认只有1个1.1版本可以开启MultiWAL功能允许多个HLog。每个HLog是多个Region共享的图5-2中Region A、Region B和Region C共享一个HLog文件。 2HLog中日志单元WALEntry图中小方框表示一次行级更新的最小追加单元它由HLogKey和WALEdit两部分组成其中HLogKey由table name、region name以及sequenceid等字段构成。
WALEdit用来表示一个事务中的更新集合在0.94之前的版本中如果一个事务对一行row R三列c1、c2、c3分别做了修改那么 HLog中会有3个对应的日志片段如下所示
logseq1-for-edit1:keyvalue-for-edit-c1
logseq2-for-edit2:keyvalue-for-edit-c2
logseq3-for-edit3:keyvalue-for-edit-c3然而这种日志结构无法保证行级事务的原子性假如RegionServer更新c2列之后发生宕机那么一行记录中只有部分数据写入成功。为了解决这样的问题HBase将一个行级事务的写入操作表示为一条记录如下所示
logseq#-for-entire-txn:WALEdit-for-entire-txn其中WALEdit会被序列化为格式-1#of edits比如-13-1为标识符表示这种新的日志结构。
2HLog文件存储
HBase中所有数据包括HLog以及用户实际数据都存储在HDFS的指定目录假设为hbase-root下可以通过hadoop命令查看hbase-root目录下与HLog有关的子目录如下所示
drwxr-xr-x - hadoop hadoop 0 2017-09-21 17:12 /hbase/WALs
drwxr-xr-x - hadoop hadoop 0 2017-09-22 06:52 /hbase/oldWALs其中/hbase/WALs存储当前还未过期的日志/hbase/oldWALs存储已经过期的日志。可以进一步查看/hbase/WALs目录下的日志文件如下所示
/hbase/WALs/hbase17.xj.bjbj.org,60020,1505980274300
/hbase/WALs/hbase18.xj.bjbj.org,60020,1505962561368
/hbase/WALs/hbase19.xj.bjbj.org,60020,1505980197364/hbase/WALs目录下通常会有多个子目录每个子目录代表一个对应的RegionServer。以hbase17.xj.bjbj.org600201505980274300为例hbase17.xj.bjbj.org表示对应的RegionServer域名60020为端口号1505980274300为目录生成时的时间戳。每个子目录下存储该RegionServer内的所有HLog文件如下所示
/hbase/WALs/hbase17.xj.bjbj.org,60020,1505980274300/hbase17.xj.bjbj.org%2C60020%2C1505980274300.default.1506184980449HLog文件为
hbase17.xj.bjbj.org%2C60020%2C1505980274300.default.15060127722053HLog生命周期
HLog文件生成之后并不会永久存储在系统中它的使命完成后文件就会失效最终被删除。 HLog生命周期包含4个阶段 1HLog构建HBase的任何写入更新、删除操作都会先将记录追加写入到HLog文件中。 2HLog滚动HBase后台启动一个线程每隔一段时间由参数’hbase.regionserver.logroll.period’决定默认1小时进行日志滚动。日志滚动会新建一个新的日志文件接收新的日志数据。日志滚动机制主要是为了方便过期日志数据能够以文件的形式直接删除。 3HLog失效写入数据一旦从MemStore中落盘对应的日志数据就会失效。为了方便处理HBase中日志失效删除总是以文件为单位执行。查看某个HLog文件是否失效只需确认该HLog文件中所有日志记录对应的数据是否已经完成落盘如果日志中所有日志记录已经落盘则可以认为该日志文件失效。一旦日志文件失效就会从WALs文件夹移动到oldWALs文件夹。注意此时HLog并没有被系统删除。 4HLog删除Master后台会启动一个线程每隔一段时间参数’hbase.master.cleaner.interval’默认1分钟检查一次文件夹oldWALs下的所有失效日志文件确认是否可以删除确认可以删除之后执行删除操作。
注意 确认HLog是否删除的条件有两个 1该HLog文件是否还在参与主从复制。对于使用HLog进行主从复制的业务需要继续确认是否该HLog还在应用于主从复制。 2该HLog文件是否已经在OldWALs目录中存在10分钟。为了更加灵活地管理HLog生命周期系统提供了参数设置日志文件的TTL参数’hbase.master.logcleaner.ttl’默认10分钟默认情况下oldWALs里面的HLog文件最多可以再保存10分钟。
三、MemStore
HBase系统中一张表会被水平切分成多个Region每个Region负责自己区域的数据读写请求。水平切分意味着每个Region会包含所有的列簇数据HBase将不同列簇的数据存储在不同的Store中每个Store由一个MemStore和一系列HFile组成如图5-4所示。 HBase基于LSM树模型实现所有的数据写入操作首先会顺序写入日志HLog再写入MemStore当MemStore中数据大小超过阈值之后再将这些数据批量写入磁盘生成一个新的HFile文件。
LSM树架构的优势 1这种写入方式将一次随机IO写入转换成一个顺序IO写入HLog顺序写入加上一次内存写入MemStore写入使得写入性能得到极大提升。大数据领域中对写入性能有较高要求的数据库系统几乎都会采用这种写入模型比如分布式列式存储系统Kudu、时间序列存储系统Druid等。 2HFile中KeyValue数据需要按照Key排序排序之后可以在文件级别根据有序的Key建立索引树极大提升数据读取效率。然而HDFS本身只允许顺序读写不能更新因此需要数据在落盘生成HFile之前就完成排序工作MemStore就是KeyValue数据排序的实际执行者。 3MemStore作为一个缓存级的存储组件总是缓存着最近写入的数据。对于很多业务来说最新写入的数据被读取的概率会更大最典型的比如时序数据80%的请求都会落到最近一天的数据上。实际上对于某些场景新写入的数据存储在MemStore对读取性能的提升至关重要。 4在数据写入HFile之前可以在内存中对KeyValue数据进行很多更高级的优化。比如如果业务数据保留版本仅设置为1在业务更新比较频繁的场景下MemStore中可能会存储某些数据的多个版本。这样MemStore在将数据写入HFile之前实际上可以丢弃老版本数据仅保留最新版本数据。
1MemStore内部结构
写入包括更新删除操作HBase中的数据都会首先写入MemStore除此之外MemStore还要承担业务多线程并发访问的职责。那么一个很现实的问题就是MemStore应该采用什么样的数据结构既能够保证高效的写入效率又能够保证高效的多线程读取效率 实际实现中HBase采用了跳跃表这种数据结构关于跳跃表的基础知识2.1节进行了详细介绍。当然HBase并没有直接使用原始跳跃表而是使用了JDK自带的数据结构ConcurrentSkipListMap。ConcurrentSkipListMap底层使用跳跃表来保证数据的有序性并保证数据的写入、查找、删除操作都可以在OlogN的时间复杂度完成。除此之外ConcurrentSkipListMap有个非常重要的特点是线程安全它在底层采用了CAS原子性操作避免了多线程访问条件下昂贵的锁开销极大地提升了多线程访问场景下的读写性能。 MemStore由两个ConcurrentSkipListMap称为A和B实现写入操作包括更新删除操作会将数据写入ConcurrentSkipListMap A当ConcurrentSkipListMap A中数据量超过一定阈值之后会创建一个新的ConcurrentSkipListMap B来接收用户新的请求之前已经写满的ConcurrentSkipListMap A会执行异步flush操作落盘形成HFile。
2MemStore的GC问题
MemStore从本质上来看就是一块缓存可以称为写缓存。众所周知在Java系统中大内存系统总会面临GC问题MemStore本身会占用大量内存因此GC的问题不可避免。不仅如此HBase中MemStore工作模式的特殊性更会引起严重的内存碎片存在大量内存碎片会导致系统看起来似乎还有很多空间但实际上这些空间都是一些非常小的碎片已经分配不出一块完整的可用内存这时会触发长时间的Full GC。 为什么MemStore的工作模式会引起严重的内存碎片这是因为一个RegionServer由多个Region构成每个Region根据列簇的不同又包含多个MemStore这些MemStore都是共享内存的。这样不同Region的数据写入对应的MemStore因为共享内存在JVM看来所有MemStore的数据都是混合在一起写入Heap的。
3MSLAB内存管理方式
为了优化这种内存碎片可能导致的Full GCHBase借鉴了线程本地分配缓存Thread-Local Allocation BufferTLAB的内存管理方式通过顺序化分配内存、内存数据分块等特性使得内存碎片更加粗粒度有效改善Full GC情况。具体实现步骤如下 1每个MemStore会实例化得到一个MemStoreLAB对象。 2MemStoreLAB会申请一个2M大小的Chunk数组同时维护一个Chunk偏移量该偏移量初始值为0。 3当一个KeyValue值插入MemStore后MemStoreLAB会首先通过KeyValue.getBuffer 取得data数组并将data数组复制到Chunk数组中之后再将Chunk偏移量往前移动data.length。 4当前Chunk满了之后再调用new byte[210241024]申请一个新的Chunk。 这种内存管理方式称为MemStore本地分配缓存MemStore-Local Allocation BufferMSLAB。
4MemStore Chunk Pool
经过MSLAB优化之后系统因为MemStore内存碎片触发的Full GC次数会明显降低。然而这样的内存管理模式并不完美还存在一些“小问题”。比如一旦一个Chunk写满之后系统会重新申请一个新的Chunk新建Chunk对象会在JVM新生代申请新内存如果申请比较频繁会导致JVM新生代Eden区满掉触发YGC。试想如果这些Chunk能够被循环利用系统就不需要申请新的Chunk这样就会使得YGC频率降低晋升到老年代的Chunk就会减少CMS GC发生的频率也会降低。这就是MemStore Chunk Pool的核心思想具体实现步骤如下 1系统创建一个Chunk Pool来管理所有未被引用的Chunk这些Chunk就不会再被JVM当作垃圾回收。 2如果一个Chunk没有再被引用将其放入Chunk Pool。 3如果当前Chunk Pool已经达到了容量最大值就不会再接纳新的Chunk。 4如果需要申请新的Chunk来存储KeyValue首先从Chunk Pool中获取如果能够获取得到就重复利用否则就重新申请一个新的Chunk。
5MSLAB相关配置
HBase中MSLAB功能默认是开启的默认的ChunkSize是2M也可以通过参数hbase.hregion.memstore.mslab.chunksize进行设置建议保持默认值。 Chunk Pool功能默认是关闭的需要配置参数hbase.hregion.memstore.chunkpool.maxsize为大于0的值才能开启该值默认是0。hbase.hregion.memstore.chunkpool.maxsize取值为[01]表示整个MemStore分配给Chunk Pool的总大小为hbase.hregion.memstore.chunkpool. maxsize*Memstore Size。另一个相关参数hbase.hregion.memstore.chunkpool.initialsize取值为[01]表示初始化时申请多少个Chunk放到Pool里面默认是0表示初始化时不申请内存。
四、HFile
MemStore中数据落盘之后会形成一个文件写入HDFS这个文件称为HFile。HFile参考BigTable的SSTable和Hadoop的TFile实现。从HBase诞生到现在HFile经历了3个版本其中V2在0.92引入V3在0.98引入。HFile V1版本在实际使用过程中发现占用内存过多HFile V2版本针对此问题进行了优化HFile V3版本和V2版本基本相同只是在cell层面添加了对Tag数组的支持。
1HFile逻辑结构 HFile文件主要分为4个部分Scanned block部分、Non-scanned block部分、Load-on-open部分和Trailer。 1Scanned Block部分顾名思义表示顺序扫描HFile时所有的数据块将会被读取。这个部分包含3种数据块Data BlockLeaf Index Block以及Bloom Block。其中Data Block中存储用户的KeyValue数据Leaf Index Block中存储索引树的叶子节点数据Bloom Block中存储布隆过滤器相关数据。 2Non-scanned Block部分表示在HFile顺序扫描的时候数据不会被读取主要包括Meta Block和Intermediate Level Data Index Blocks两部分。 3Load-on-open部分这部分数据会在RegionServer打开HFile时直接加载到内存中包括FileInfo、布隆过滤器MetaBlock、Root Data Index和Meta IndexBlock。 4Trailer部分这部分主要记录了HFile的版本信息、其他各个部分的偏移值和寻址信息。
2HFile物理结构 HFile文件由各种不同类型的Block数据块构成虽然这些Block的类型不同但却拥有相同的数据结构。 Block的大小可以在创建表列簇的时候通过参数blocksize65535’指定默认为64K。通常来讲大号的Block有利于大规模的顺序扫描而小号的Block更有利于随机查询。因此用户在设置blocksize时需要根据业务查询特征进行权衡默认64K是一个相对折中的大小。 HFileBlock主要包含两部分BlockHeader和BlockData。其中BlockHeader主要存储Block相关元数据BlockData用来存储具体数据。Block元数据中最核心的字段是BlockType字段表示该Block的类型HBase中定义了8种BlockType每种BlockType对应的Block都存储不同的内容有的存储用户数据有的存储索引数据有的存储元数据meta。对于任意一种类型的HFileBlock都拥有相同结构的BlockHeader但是BlockData结构却一定相同。
3HFile的基础Block
1Trailer Block
Trailer Block主要记录了HFile的版本信息、各个部分的偏移值和寻址信息图5-11为Trailer Block的数据结构其中只显示了部分核心字段。 RegionServer在打开HFile时会加载所有HFile的Trailer部分以及load-on-open部分到内存中。实际加载过程会首先会解析Trailer Block然后再进一步加载load-on-open部分的数据具体步骤如下 1加载HFile version版本信息HBase中version包含majorVersion和minorVersion两部分前者决定了HFile的主版本——V1、V2还是V3后者在主版本确定的基础上决定是否支持一些微小修正比如是否支持checksum等。不同的版本使用不同的文件解析器对HFile进行读取解析。 2HBase会根据version信息计算Trailer Block的大小不同version的Trailer Block大小不同再根据Trailer Block大小加载整个HFileTrailer Block到内存中。Trailer Block中包含很多统计字段例如TotalUncompressedBytes表示HFile中所有未压缩的KeyValue总大小。NumEntries表示HFile中所有KeyValue总数目。Block中字段CompressionCodec表示该HFile所使用的压缩算法HBase中压缩算法主要有lzo、gz、snappy、lz4等默认为none表示不使用压缩。 3Trailer Block中另两个重要的字段是LoadOnOpenDataOffset和LoadOnOpenDataSize前者表示load-on-open Section在整个HFile文件中的偏移量后者表示load-on-open Section的大小。根据此偏移量以及大小HBase会在启动后将load-on-open Section的数据全部加载到内存中。load-on-open部分主要包括FileInfo模块、Root Data Index模块以及布隆过滤器Metadata模块FileInfo是固定长度的数据块主要记录了文件的一些统计元信息比较重要的是AVG_KEY_LEN和AVG_VALUE_LEN分别记录了该文件中所有Key和Value的平均长度。Root Data Index表示该文件数据索引的根节点信息布隆过滤器Metadata记录了HFile中布隆过滤器的相关元数据。
3Data Block
Data Block是HBase中文件读取的最小单元。Data Block中主要存储用户的KeyValue数据而KeyValue结构是HBase存储的核心。HBase中所有数据都是以KeyValue结构存储在HBase中。 KeyValue由4个部分构成分别为Key Length、Value Length、Key和Value。其中Key Length和Value Length是两个固定长度的数值Value是用户写入的实际数据Key是一个复合结构由多个部分构成Rowkey、Column Family、Column Qualifier、TimeStamp以及KeyType。其中KeyType有四种类型分别是Put、Delete、DeleteColumn和DeleteFamily。 由Data Block的结构可以看出HBase中数据在最底层是以KeyValue的形式存储的其中Key是一个比较复杂的复合结构这点最早在第1章介绍HBase数据模型时就提到过。因为任意KeyValue中都包含Rowkey、Column Family以及Column Qualifier因此这种存储方式实际上比直接存储Value占用更多的存储空间。这也是HBase系统在表结构设计时经常强调Rowkey、ColumnFamily以及Column Qualifier尽可能设置短的根本原因。
4HFile中与布隆过滤器相关的Block
布隆过滤器的基本原理可以参考第2章。布隆过滤器对HBase的数据读取性能优化至关重要。前面2.2节介绍过HBase是基于LSM树结构构建的数据库系统数据首先写入内存然后异步flush到磁盘形成文件。这种架构天然对写入友好而对数据读取并不十分友好因为随着用户数据的不断写入系统会生成大量文件用户根据Key获取对应的Value理论上需要遍历所有文件在文件中查找指定的Key这无疑是很低效的做法。使用布隆过滤器可以对数据读取进行相应优化对于给定的Key经过布隆过滤器处理就可以知道该HFile中是否存在待检索Key如果不存在就不需要遍历查找该文件这样就可以减少实际IO次数提高随机读性能。布隆过滤器通常会存储在内存中所以布隆过滤器处理的整个过程耗时基本可以忽略。 HBase会为每个HFile分配对应的位数组KeyValue在写入HFile时会先对Key经过多个hash函数的映射映射后将对应的数组位置为1get请求进来之后再使用相同的hash函数对待查询Key进行映射如果在对应数组位上存在0说明该get请求查询的Key肯定不在该HFile中。当然如果映射后对应数组位上全部为1则表示该文件中有可能包含待查询Key也有可能不包含需要进一步查找确认。 可以想象HFile文件越大里面存储的KeyValue值越多位数组就会相应越大。一旦位数组太大就不适合直接加载到内存了因此HFile V2在设计上将位数组进行了拆分拆成了多个独立的位数组根据Key进行拆分一部分连续的Key使用一个位数组。这样一个HFile中就会包含多个位数组根据Key进行查询时首先会定位到具体的位数组只需要加载此位数组到内存进行过滤即可从而降低了内存开销。 在文件结构上每个位数组对应HFile中一个Bloom Block因此多个位数组实际上会对应多个Bloom Block。为了方便根据Key定位对应的位数组HFile V2又设计了相应的索引Bloom IndexBlock
整个HFile中仅有一个Bloom Index Block数据块位于load-on-open部分。Bloom Index Block见图5-13左侧部分从大的方面看由两部分内容构成其一是HFile中布隆过滤器的元数据基本信息其二是构建了指向Bloom Block的索引信息。 Bloom Index Block结构中TotalByteSize表示位数组大小NumChunks表示Bloom Block的个数HashCount表示hash函数的个数HashType表示hash函数的类型TotalKeyCount表示布隆过滤器当前已经包含的Key的数目TotalMaxKeys表示布隆过滤器当前最多包含的Key的数目。 Bloom Index Entry对应每一个Bloom Block的索引项作为索引分别指向scanned block部分的Bloom BlockBloom Block中实际存储了对应的位数组。Bloom Index Entry的结构见图5-13中间部分其中BlockKey是一个非常关键的字段表示该Index Entry指向的Bloom Block中第一个执行Hash映射的Key。BlockOffset表示对应Bloom Block在HFile中的偏移量。 因此一次get请求根据布隆过滤器进行过滤查找需要执行以下三步操作 1首先根据待查找Key在Bloom Index Block所有的索引项中根据BlockKey进行二分查找定位到对应的Bloom Index Entry。 2再根据Bloom Index Entry中BlockOffset以及BlockOndiskSize加载该Key对应的位数组。 3对Key进行Hash映射根据映射的结果在位数组中查看是否所有位都为1如果不是表示该文件中肯定不存在该Key否则有可能存在。
5HFile中索引相关的Block
根据索引层级的不同HFile中索引结构分为两种single-level和multi-level前者表示单层索引后者表示多级索引一般为两级或三级。HFile V1版本中只有single-level一种索引结构V2版本中引入多级索引。之所以引入多级索引是因为随着HFile文件越来越大Data Block越来越多索引数据也越来越大已经无法全部加载到内存中多级索引可以只加载部分索引从而降低内存使用空间。同布隆过滤器内存使用问题一样这也是V1版本升级到V2版本最重要的因素之一。 V2版本Index Block有两类Root Index Block和NonRoot Index Block。NonRoot Index Block又分为Intermediate Index Block和Leaf Index Block两种。HFile中索引是树状结构RootIndex Block表示索引数根节点Intermediate Index Block表示中间节点Leaf Index Block表示叶子节点叶子节点直接指向实际Data Block如图5-14所示。 需要注意的是这三种Index Block在HFile中位于不同的部分Root Index Block位于“load-on-open”部分会在RegionServer打开HFile时加载到内存中。Intermediate Index Block位于“Non-Scanned block”部分Leaf Index Block位于“scanned block”部分。 HFile中除了Data Block需要索引之外Bloom Block也需要索引Bloom索引结构实际上采用了单层结构Bloom Index Block就是一种Root Index Block。 对于Data Block由于HFile刚开始数据量较小索引采用单层结构只有Root Index一层索引直接指向Data Block。当数据量慢慢变大Root Index Block大小超过阈值之后索引就会分裂为多级结构由一层索引变为两层根节点指向叶子节点叶子节点指向实际Data Block。如果数据量再变大索引层级就会变为三层。
五、BlockCache
提升数据库读取性能的一个核心方法是尽可能将热点数据存储到内存中以避免昂贵的IO开销。现代系统架构中诸如Redis这类缓存组件已经是体系中的核心组件通常将其部署在数据库的上层拦截系统的大部分请求保证数据库的“安全”提升整个系统的读取效率。
1LRUBlockCache
LRUBlockCache是HBase目前默认的BlockCache机制实现相对比较简单。它使用一个ConcurrentHashMap管理BlockKey到Block的映射关系缓存Block只需要将BlockKey和对应的Block放入该HashMap中查询缓存就根据BlockKey从HashMap中获取即可。同时该方案采用严格的LRU淘汰算法当Block Cache总量达到一定阈值之后就会启动淘汰机制最近最少使用的Block会被置换出来。
2SlabCache
为了解决LRUBlockCache方案中因JVM垃圾回收导致的服务中断问题SlabCache方案提出使用Java NIO DirectByteBuffer技术实现堆外内存存储不再由JVM管理数据内存。默认情况下系统在初始化的时候会分配两个缓存区分别占整个BlockCache大小的80%和20%每个缓存区分别存储固定大小的Block其中前者主要存储小于等于64K的Block后者存储小于等于128K的Block如果一个Block太大就会导致两个区都无法缓存。和LRUBlockCache相同SlabCache也使用Least-Recently-Used算法淘汰过期的Block。和LRUBlockCache不同的是SlabCache淘汰Block时只需要将对应的BufferByte标记为空闲后续cache对其上的内存直接进行覆盖即可。 线上集群环境中不同表不同列簇设置的BlockSize都可能不同很显然默认只能存储小于等于128KB Block的SlabCache方案不能满足部分用户场景。比如用户设置BlockSize256K简单使用SlabCache方案就不能达到缓存这部分Block的目的。因此HBase在实际实现中将SlabCache和LRUBlockCache搭配使用称为DoubleBlockCache。在一次随机读中一个Block从HDFS中加载出来之后会在两个Cache中分别存储一份。缓存读时首先在LRUBlockCache中查找如果Cache Miss再在SlabCache中查找此时如果命中则将该Block放入LRUBlockCache中。
3BucketCache
SlabCache方案在实际应用中并没有很大程度改善原有LRUBlockCache方案的GC弊端还额外引入了诸如堆外内存使用率低的缺陷。然而它的设计并不是一无是处至少在使用堆外内存这方面给予了后续开发者很多启发。站在SlabCache的肩膀上社区工程师设计开发了另一种非常高效的缓存方案——BucketCache。 BucketCache通过不同配置方式可以工作在三种模式下heapoffheap和file。heap模式表示这些Bucket是从JVM Heap中申请的offheap模式使用DirectByteBuffer技术实现堆外内存存储管理file模式使用类似SSD的存储介质来缓存Data Block。无论工作在哪种模式下BucketCache都会申请许多带有固定大小标签的Bucket和SlabCache一样一种Bucket存储一种指定BlockSize的Data Block但和SlabCache不同的是BucketCache会在初始化的时候申请14种不同大小的Bucket而且如果某一种Bucket空间不足系统会从其他Bucket空间借用内存使用因此不会出现内存使用率低的情况。 文章来源《HBase原理与实践》 作者胡争范欣欣 文章内容仅供学习交流如有侵犯联系删除哦
