这是我参与「第四届青训营」笔记创作活动的第十一天。
高可用
高可用需求
可能的故障：设备故障、软件故障、人为故障
高可用衡量：MTTR、MTTF、MTBF
可用性
服务高可用：冷备份、热备份
故障恢复操作：人工切换、自动切换
高可用架构
- ActiveNamenode：主节点，提供服务，生产日志
- StandbyNamenode：备节点，消费日志
- ZooKeeper：为自动选主提供统一-协调服务
- BookKeeper：提供日志存储服务
- ZKFC ：NameNode探活、触发主备切换
- HA Client：提供了自动切换的客户端
- edit log：操作的日志
NameNode操作日志的生产消费
Active生产，StandBy消费
content stale状态：避免主备切换后的DN的不确定状态
自动主备切换
ZKFC（ZooKeeperFailoverController）
注册并监控NameNode的存活状态 作为外部组件，驱动NameNode的主备切换
脑裂机制：
client侧
StandByException机制
BookKeeper架构
Quorum机制
多副本一致性读写
多副本对象存储，版本号标识数据新旧
规则
BookKeeper Quorum
Sloppy Quorum机制
顺序追加，只写
Write Quorum
Ack Quorum
数据存储高可用
RAID Redundant Array of Independent Disk
- RAID0：条带化
- RAID1：冗余
- RAID3：容错检验
HDFS多副本
HDFS版本的RAID1，通过checksum检验正确性
读写路径简单、副本修复简单、高可用
erasure coding EC 纠删码
Reed Solomon算法
网络架构
服务器Server 机架Rack TOR（top of rack）机架顶部的交换机 POD(Point of Delivery) :数据中心中的一个物理区域 数据中心(Data Center) :集中部署服务器的场所
元数据高扩展性
scale up vs. scale out 提升单个服务器的能力vs.部署多个服务器提供服务
挑战：
- 名字空间分裂
- DataNode汇报
- 目录树结构本身复杂
scale out方案
KV模型的系统可以用partition
- Kafka
- Redis
- MySQL（分库分表）
BlockPool方案
文件服务分层
- NameSpace
- Block Storage
viewfs方案
federation架构：将多个集群组合起来，表现得像一个集群一样
viewfs通过在client侧的配置指定不同的目录使用不同的NameNode
NNProxy
NNProxy实现了路由管理和RPC转发以及限流、鉴权和查询缓存等额外能力
数据存储高扩展性
超大集群的长尾延迟问题
主要的延迟会分布在正常范围内，但小部分请求延迟可能会很大。如p99表示99%的请求延迟会小于1ms，但1%的请求延迟可能会将很大
用户访问多个服务时，请求的延迟取决于最慢的请求响应延迟
慢节点的发生
- 共享资源、后台维护、请求多级排队、功率限制
- 机器损坏
- 混沌现象
部分数据块的读取受长尾影响会拖累整个任务的进行
超大集群的负载均衡和数据迁移
- 避免热点
- 降低成本
- 提高可靠性
典型场景
数据迁移
跨NN迁移
- DistCopy:基于MapReduce，要拷贝数据，流量大速度较慢
- FastCopy：需要新旧集群的DN列表一致，对于元数据直接拷贝，对于数据块进行hardlink（让两条路景指向同一块数据）到目标BlockPool
Balancer工具
