1. 整体架构
各角色之间的关系
集群部署架构
flowchart TB
A[Master] & B[zookeeper] --> C[RegionServer] & D[RegionServer] & E[RegionServer]
-
zookeeper
- 用于和客户端连接，存储hbase:meta表的位置。hbase:meta存储所有region的行键范围
- 【实现master高可用】
-
master负责
- 跨region的操作：建表，删表，alter，移动region，合并，拆分等
- 【为HRegionServer分配Region，维护整个集群的负载均衡】
- 【维护集群的元数据信息】
- 【发现失效的Region，并将失效的Region分配到正常的HRegionServer上】
- 清理过期的WAL（TTL, 备份集群）
-
RegionServer
- 接收并处理客户端读写请求
- 【负责管理Region】
- 【切分在运?过程中变?的Region】
2. 数据模型层次图
flowchart LR
A[RegionServer] --> B1[Region]
A --> B2[Region]
B1 --> C1[Store]
B1 --> C2[Store]
B2 --> C4[Store]
B2 --> C5[Store]
C1 --> D1[Hfile]
C1 --> D2[Hfile]
C1 --> D5[MemStore]
3. 写入流程
WAL : WAL实例维护了一个ConcurrentNavigableMap ，包含了多个WAL文件的引用。当一个文件写满了就会开始写下一个文件。WAL工作时，WAL文件数量会不断增长直到一个阈值后开始滚动。环状滚动日志结构
WAL实例只有一个，WAL文件会有多个，个数由HBase内部计算，公式：
Math.max(32, (regionserverHeapSize * memstoreSizeRatio*2 / logRollSize))
MemStore刷写, LSM树，主要是保证读性能（牺牲了一些写性能）
- 大小达到阈值 hbase.hregion.memstore.flush.size 512M
- 定时检查，若未到检查时间就达到阈值，会出发阻塞机制，阻止写入
- 整个regionserver的memstore总和达到阈值
- 也会出现阻塞
- WAL数量大于maxLogs
- 不会阻塞写入。触发memstore的刷写，以创建新空间加载WAL
- memstore达到刷写时间间隔 1小时
- 手动触发刷写
4. 读取流程
从store中获取的数据先写入BlockCache，再返回到客户端
BlockCache的实现方案
1. LRUBlockCache
LeastRecentUsed 最近最少使用的数据淘汰
分为三个区域：
- single-access 25%
- multi-access 50%
- in-memory 25%
列族的in-memory属性为true时，该列族的block从一开始就会被读到in-memory，且淘汰block时最后考虑这个区域。
BlockCache和Memstore配置的联动影响
memtore + blockcache 的内存占用比不能超过80%，否则会报错。因为必须留20%作为机动空间。
Full GC
2. BucketCache
14种桶
堆内、堆外、SSD-file
3. 组合模式
不同类型的Block分别放到LRUCache和BucketCache：
- IndexBlock 和 BloomBlock 会被放到LRUCache
- DataBlock 直接放到BucketCache
二级缓存：数据从一级到二级再到硬盘，从小到大，存储介质也是从快到慢。
比较合理的介质是：LRUCache使用内存，BucketCache使用SSD，HFile使用机械硬盘