AirJD 焦点
  • 本月热门
AirJD

没有录音文件
00:00/00:00
加收藏

从百度文件系统看大型分布式系统设计中的定式与创新

发布者 kernal
发布于 1492610631039  浏览 1323 关键词 大数据, NoSQL 
分享到

第1页

从百度文件系统 看大型分布式系统设计

颜世光 百度 搜索基础架构



第3页

自我介绍

• 颜世光, 专注于大规模分布式系统 • 代表作品

- 百度第三代Spider系统 - 百度文件系统BFS - 万亿量级实时数据库Tera - 集群调度系统Galaxy

• 个人主页&Blog

- https://github.com/bluebore - http://bluebore.cn



第4页

提纲

• 百度文件系统简介 • 分布式系统设计实践 • 总结与致谢



第5页

百度的集群环境

• 单个集群通常几千台机器 • 百度文件系统(BFS)、集群调度系统(Galaxy)、分布式协

调服务(Nexus)是核心服务 • 实时任务与批量任务混合部署

Nexus

lock service

BFS master

Galaxy master



第6页

分布式软件栈中的BFS



The Baidu Stack

Apps(Spider/Index/Search)



分布式数据库 Tera



分布式计算框架 Shuttle



分布式文件系统 BFS



集群调度系统 Galaxy



分布式协调服务 Nexus



网络通信框架Sofa-pbrpc



第7页

数据中心操作系统(DCOS)

• 进程调度&内存管理

- Galaxy - 应用部署和任务调度

• 锁和信号量

- Nexus - 分布式锁 - 分布式通知

• 文件系统

- The Baidu File System - 持久化存储



第8页

百度文件系统架构



第9页

设计一个分布式系统要考虑的

• 数据与计算的分片 • 分区故障容忍 • 数据一致性 • 系统扩展性 • 延迟与吞吐 • 成本与资源利用率 •…



第10页

数据与计算的分片

• 哈希分片

- 简单、均衡 - 扩容复杂、易用性差 - 一致性哈希、虚拟节点

• 按范围、数据量分

- 使用简单 - 需要管理元数据 - 中心化与去中心化



第11页

元数据管理

• 去中心化

- P2P技术 - 潜在的一致性问题 - 能管理的元数据有限

• 中心化

- 设计实现简单 - Master节点易成为瓶颈



第12页

中心化的解决方案

• Master-Slave模型

- Master是管理者 - Slave是执行者

• 解决Master节点瓶颈

- 常规操作不经过Master

• 一般计算系统 • Bigtable、Tera等存储系统

- 使Master无状态

• 非最底层系统都可以设计无状态Master

- Master分布化

• BFS选择的解决方案



第13页

NameServer Cluster



第14页

故障容忍

• 设备都是会坏的

- 假设的服务器MTBF是30年 - 搭建一个1万台服务器的系统 - 每一两天就坏一个

• 典型数据中心

- 过热:5分钟内数千台机器宕机 - 供电异常: 500~1000台机器突然消失 - 机架晃动: 几十台机器出现50%丢包 - 交换机故障: 几十台机器突然消失 - 磁盘、单机故障

• 通过冗余应对故障



第15页

一个典型的数据处理场景



2. 通知



数据接收模块



数据处理模块



1. 写入



3. 读取



存储 从 主从



多副本冗余



第16页

一致性问题



• 怎么定义写成功



- 3副本成功, 影响可用性



• 可以读从节点

- 刚写入的读不到



2. 通知



数据接收模块



数据处理模块



- 不一致



1. 写入



3. 读取



• 只允许读主节点

- 扩展性受限



存储 从 主从



第17页

CAP理论

• 简要历史

- Eric Brewer 1998年提出 - 2002年证明

• CAP三选二

- Consistency 一致性 - Availability 可用性 - Partition Tolerance 分区

容忍性

• 分布式系统

- 容忍网络隔离是必须的 - CP、AP



第18页

Quorum机制

• Quorum写(NWR)

- Write 写成功W副本 - Read 读R副本 - W+R>N,就不会丢失更新

• 一致性协议

- Paxos - Raft



第19页

CAP到CAD的演变

• 必须容忍网络隔离

- CAP->CA

• 跨地域的延迟

- CA->CAD/CAL

• 多数情况下我们更重视可用性

- CAD->CD

• 一致性与延迟的折衷

- 要求强一致的, 容忍延迟 - 要求低延迟的, 选择最终一致



第20页

提升系统扩展性

• 架构的可扩展性

- 拆分元数据节点 - 引入MetaServer



第21页

提升系统扩展性

• 设计的可扩展性

- 保证在规模扩大5倍或10倍是正常工作

• BFS避免了过渡设计

- 用设计中的不可扩展达到最大的可扩展

• 最多支持6万台机器 • 最多支持100亿文件



第22页

分布式存储系统设计的特殊性

• 最基础服务的提供者

- 不可能做成无状态的

• 最底层的仲裁者

- 不能依赖ZooKeeper等系统选主 - 分布式的双主问题只从存储系统解决



第23页

这些设计给BFS带来哪些优势?



名字节点 扩展方式



HDFS



BFS



联邦式



分布式



分裂的目录树 统一的目录树



宕机恢复时间 分钟级



秒级



外部依赖 开发语言



ZooKeeper & QJM

Java



无 C++



第24页

Q&A

• 欢迎参与BFS的开发 • https://github.com/baidu/bfs • 谢谢~



支持文件格式:*.ppt, *.pptx, *.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。