这是我参与「第四届青训营 」笔记创作活动的第15天
先来说说什么是高可用：即在遭遇故障时当前组件或机制依旧能够正常运行，保证系统的健壮性和自动修复能力。
故障类型可分为：硬件故障，软件故障以及人为故障
元数据高可用
而如果HDFS系统不可用。
- 无法核算广告账单，直接引发收入损失
- 无法生产数据报表，数据驱动无从谈起
- 无法进行模型训练，用户体验越来越差
业务停止的损失极大，所以HDFS 系统的高可用性就至关重要。
服务可用性指标：
-
MTTR：Mean Time To Restoration
平均失效前时间，就是从出现故障到修复中间的这段时间，它包括确认失效发生所必需的时间，记录所有任务的时间，还有将设备重新投入使用的时间。
-
MTTF：Mean Time To Failure
平均恢复前时间，指某个元件预计可运作的平均时间
-
MTBF：Mean Time Between Failures
平均故障间隔时间
高可用架构的服务体系：
- ActiveNamenode:主节点，提供服务，生产日志
- StandbyNamenode:备节点，消费日志
- zooKeeper:为自动选主提供统一协调服务
- BookKeeper:提供日志存储服务
- ZKFC: NameNode探活、触发主备切换
- HA Client:提供了自动切换的客户端
- edit log:操作的日志
高可用的思考方向
下面的思考方向只能说囫囵吞枣了解大概，想要看懂还得多看几次视频，多查资料
- 状态机复制和日志
- nameNode状态持久化
- nameNode操作日志的生产与消费
- nameNode块状态维护
- zookeeper提供选主，协调以及元数据储存
- bookkeeper储存日志
- Quorum机制等
数据储存高可用
数据储存的高可用需要回到单机开始讲起
RAID
Redundant Arrays of Independent Disks， 磁盘阵列，有"数块独立磁盘构成具有冗余能力的阵列”之意。RAID在课程中提到分别是：
- RAID0：条带化
- RAID1：冗余
- RAID3：容错校验
网络架构
网络架构中，组件由小到大，依次大体可以分为：服务器server -> 机架Rack -> 交换机TOR -> 数据中心 -> 多机房
当我们使用网络架构时，需要考虑网络传输的可靠性，同一交换机内能解决的事，就不外放；同一局域网能解决的事情，就不使用公网；减少因为网络造成的不可靠性，同时注意 物理防灾
元数据高扩展
HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展。
scale up指的是强化单体机器的能力，scale out指的是用多台廉价机器去完成昂贵单体机器所完成的业务
scale up vs.scale out：
- 扩容单个服务器的能力
- 部署多个服务器来服务
挑战：
- 名字空间分裂
- DataNode汇报
- 目录树结构本身复杂
数据储存高扩展
长尾问题
延迟的分布:
- 用百分数来表示访问的延迟的统计特征
- 例如p95延迟为1ms，代表95%的请求延迟要低于1ms, 但后5%的请求延迟会大于1ms
长尾延迟:尾部(p99/p999/p999)的延迟，衡量系统最差的请求的情况。会显著的要差于平均值
长尾问题主要来源于系统的慢节点，然而慢节点是难以避免和预测的。如共享资源的锁，后台的维护，请求的队列，以及机器的损耗等等，甚至在数学上早已明确了混沌现象的不可控性，因此我们可以降低长尾问题的影响，但是无法完美的规避这个问题
可靠性问题
对于现实生活中的超大集群而言：
- 条件一:超大集群下，有一部分机器是损坏来不及修理的
- 条件二:副本放置策略完全随机
- 条件三:DN的容量足够大
- 推论:必然有部分数据全部副本在损坏的机器上，发生数据丢失。
CopySet方案能够解决以上部分问题，但是有所缺陷
不均匀问题
负载均衡：平衡以下三点-降低成本-可靠性-避免热点
同样的，在现实生活中，数据的写入也难以做到均匀：
- 节点容量不均匀
- 数据新旧不均匀
- 访问类型不均匀
这三点不均匀最终导致了资源负载的不均匀
