这是我参与「第四届青训营 -大数据场」笔记创作活动的第12篇笔记
本文已参与「新人创作礼」活动， 一起开启掘金创作之路。
元数据服务高可用
高可用的需求
高可用的形式
服务器可用：
- 热备份
- 冷备份
故障恢复操作：
- 人工切换
- 自动切换
HDFS NameNode高可用架构
组件介绍：
- ActiveNameNode：主节点，提供服务，生产日志
- StandbyNameNode：备节点，消费日志
- ZooKeeper：为自动选主提供统一协调服务
- BookKeeper：提供日志存储服务
- AKFC：NameNode探活、触发主备切换
- HA Client：提供了自动切换的客户端
- edit log：操作的日志
状态机复制和日志
状态机复制是实现容错的常规方法
组件：
- 状态机以及其副本
- 变更日志
- 共识协议
NameNode状态持久化
(待补充)
NameNode操作日志的生产消费
目录树和文件信息的更新
Active生产，Standby消费
物理日志与逻辑日志
日志系统：
- 高可用
- 高拓展性
- 高性能
- 强一致(有序)
NameNode块状态维护
DataNode要向Active和Standby两种节点做出心跳(Heartbeat)
这样两种节点可知DataNode是存活的状态
区别：
- Active即接收，也发起变更
- Standby只接收，不发起变更
Content Stale状态：
主备切换后，避免DN的不确定状态
分布式协调组件
ZooKeeper
一般用于提供选主、协调、元数据存储
使用它的组件：
- HDFS、YARN、HBase
- Kafka.ClickHouse
HA核心机制：Watch
自动主备切换流程-Server侧
ZKFailoverController：
作为外部组件，驱动HDFS NameNode的主备切换
自动主备切换流程-Client侧
核心机制：StandbyException
通过此机制，Client每次可以找到真正的Active
BookKeeper架构
BookKeeper存储日志：
- 低延时
- 持久性
- 强一致性
- 读写高可用
Application可以理解为HDFS的NameNode
Client提供两种API，Ledger API 和 Log stream API
元数据存储在ZooKeeper集群
Quorum机制
Quorum机制：多副本一致性读写
场景：
- 多副本对象存储，用版本号标识数据新旧
BookKeeper Quorum
Write Quorum：写入副本数
Ack Quorum：响应副本数
BookKeeper Ensemble
如图所示：
有4台机器，要求写入3个副本，数据相对均衡
数据存储高可用
HDFS多副本
如图是Hadoop的多副本放置
优点：
- 读写路径简单
- 副本修复简单
- 高可用
Erasure Coding原理
如图是Reed Solomon 算法原理
HDFS Erasure Coding原理
如图： 直接保存的EC和Stripe(条带化)后保存的EC
元数据高拓展性
元数据节点拓展性的挑战
HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限拓展
Scale out 方案
KV模型的系统可以使用partition
- Redis
- Kafka
- MySQL(分库分表)
如图：三种数据路由方式：
- 服务端侧
- 路由层
- 客户端层
社区解决方案-BlockPool
解决DN同时服务多组NN的问题
文件服务分层
- Namespace
- Block Storage
用blockpool来区分DN的服务
- 数据块存储
- 心跳和块上报
社区解决方案-viewfs
Federation架构：将多个不同集群组合起来，对外表像一个集群一样
如图：viewfs通过在client-side的配置，指定不同的目录访问不同的NameNode
局限性：运维复杂
字节跳动-NNProxy
NNProxy主要实现了路由管理和RPC转发以及鉴权、限流、查询缓存等额外能力
存储数据高拓展性
超大集群的长尾延迟
长尾延迟：
尾部的延迟，衡量系统最差的请求的情况，会显著的要差于平均值
慢节点
慢节点:
读取速度过慢，导致客户端阻塞
超大集群下的数据可靠性
- 条件一：超大集群下，有一部分机器是损坏来不及修理的
- 条件二：副本放置策略完全随机
- 条件三：DN的容量足够大
推论：必然有部分数据全部副本在损坏的机器上，发生数据丢失
