这是我参与「第四届青训营 」笔记创作活动的的第5天
HDFS 的架构
- HDFS 的主要服务端主要组件是 NameNode 和 DataNode，两者通过定时心跳通信。
- NameNode（NN）负责维护目录树、文件和块的关系、各个块的副本放置位置等元信息。
- DataNode（DN）负责维护数据副本，执行 NameNode 下发的副本迁移、副本删除等操作。
- HDFS Client 属于是胖客户端（fat/rich client），客户端中实现了数据读写的容错等较为复杂的逻辑。
HDFS 的读写路径
- 数据读取：Client 从 NN 上获取到文件信息和块的位置（getFileInfo+getBlockLocation），从对应 DN 上读取数据。当一个 DN 读取失败时，会去尝试块的其他 DN。
- 数据写入：Client 要求 NN 创建文件（create），并依次获得不同的 DN 来写入数据块（addBlock）。Client 通过链式写入来同时写入数据到多个 DN。在整个写入完成后，会让 NN 关闭文件（complete）。
HDFS高可用架构
- Active NameNode：提供服务的 NameNode 主节点，生产 editlog。
- Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog
- editlog：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志。
- ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。
- BookKeeper：开源的日志存储组件，存储 editlog
- ZKFC：和 ZK、NN 通信，进行 NN 探活和自动主备切换。
- HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点。
NameNode块状态维护
Active和Standby区别：Active既接受，也发起变更，Standby只接收，不发起变更
自动主备切换流程
DN需要同时向activeNN和standbyNN汇报信息，但只有activeNN会发出command
高可用日志系统 BookKeeper
- 高可靠：数据写入多个存储节点，数据写入就不会丢失。
- 高可用：日志存储本身是高可用的。因为日志流比文件系统本身的结构更为简单，日志系统高可用的实现也更为简单。
- 强一致：日志系统是追加写入的形式，Client 和日志系统的元数据可以明确目前已经成功的写入日志的序号（entry-id）。
- 可扩展：整个集群的读写能力可以随着添加存储节点 Bookie 而扩展。
Quorum 协议：基于鸽巢原理，在多个副本间确保高可用、高性能的多副本变更协议
- 多副本间一般通过 version-id 来描述状态的新旧。
- 高可用：多个副本确保了高可用（后文会再次介绍多副本高可用）。
- 高性能：不用等所有副本写入成功，降低了的长尾延迟（后文会再次介绍长尾延迟）。
BookKeeper Quorum 协议：基于 Quorum 的多数派思想来提供高可用、高性能写入的日志写入
- 日志写入是追加，不是状态变更，只需要确认目前的 entry-id，相对更简单。
- Write Quorum：一次写入需要写入到的存储节点数。
- Ack Quorum：一次写入需要收到的响应数，小于 write quorum。
- 高性能：不用等所有副本写入成功，降低了的长尾延迟（后文会再次介绍长尾延迟）。
- Ensemble：通过轮询（Round-Robin）来确认 write quorum 实际对应的存储节点实例，可以比较简单的完成副本放置和扩展。
数据高可用
- RAID阵列
- Erasure Codeing：将数据分段，通过特殊的编码方式存储额外的校验块，并条带化的组成块，存储在 DN 上。
- 条带化对于发生损坏进行恢复可以有效减少计算量
- 机架（Rack）：每个机架顶部有一个交换机
- 多机房容灾
- 双机房中每个机房都需要写入一个副本才算完成一次写入
- 容灾期间，限制跨机房的写入，限制跨机房副本
元数据扩展性
扩展性方案
- scale up：通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。
- scale out：通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。
federation 架构
- 使得多个集群像一个集群一样提供服务的架构方法，提供了统一的服务视图，提高了服务的扩展性。
- 文件系统的目录树比 kv 模型更复杂，划分更困难。
- 邦联架构的难点一般在于跨多个集群的请求，例如 HDFS 的 rename 操作就可能跨多个集群。
