一个“可以用”的系统和“好用”的系统，差距就是“高可用”和“高扩展性”！

这是我参与「第四届青训营」笔记创作活动的第3天，笔记内容为《HDFS的高可用机制分析之“元数据高可用”》，内容主要为“元数据高可用”。

元数据高可用

服务高可用的需求

故障类型： 硬件故障、软件故障、人为故障；

灾难（数据中心级别不可用）： 机房断电、机房空调停机、机房间网络故障/阻塞；

故障不可避免，灾难时有发生！！！

如果HDFS不可用：

无法核算广告账单，直接引发收入损失

无法生成数据报表，数据驱动无从谈起

无法进行模型训练，引起用户体验下滑

高可用衡量

服务可用性指标：

MTTR：发现一次故障，用多久时间恢复;

MTTF：平均失效时间，运行到故障间的时间，一般用于不可修复的系统（制作业）;

MTBF：平均无故障时间，两次故障间的间隔，一般用于可修复系统（软件）。过短，不稳定，过长，系统稳定。

可用性的年化

可用性： $MTBF$ / $(MTBF+MTTR)$

**全年不可用时间: **

可用性 99.9： 8.76小时不可用

可用性 99.99： 52.6分钟不可用

可用性 99.999： 5.26分钟不可用

高可用的形式

服务高可用： 热备份、冷备份

故障恢复操作： 人工切换、自动切换

人工的反应、决策时间都更长，高可用需要让系统自动决策！

HDFS的设计中，采用中心化的元数据管理节点NameNode，其容易成为故障中的单点。

HDFS NameNode高可用架构

组件介绍

ActiveNamenode：主节点，提供服务，生产日志

StandbyNamenode：备节点，消费日志

ZooKeeper：为自动选主提供统一协调服务

BookKeeper：提供日志存储服务

ZKFC：Namenode探活，触发主备切换

HA Client：提供自动切换的客户端

edit log：操作的日志

围绕3个问题看高可用：

节点状态如何更新

操作日志如何同步

如何做到自动切换

理论基础——状态肌复制和日志（状态机复制是实现容错的常规方法！）

组件：

状态机：一个状态机从初始状态开始，每一个输入都被传入转换函数和输出函数，以生成一个新的状态和输出。新输入被接收到前，状态保持不变，而输出同时被传输给恰当的接受者；

状态机复制：确定性的状态机具有「处理确定的输入后，状态唯一确定」的特性。状态机复制利用这个特性实现多个相同的状态机副本的同步更新；

变更日志：触发状态机更新的变更操作，具有全局确定的顺序；

共识协议：确保每个副本都能收到相同的日志的共识协议，常见的有 Paxos、Raft、ZAB。