GoogleAppEngine技术架构资料大盘点pengzl的个人空间中文JAVA技术网javajava技术java软件java面试java教程java基础教程javajava技术java软件java面试java教程java基础教程.pdf
- 1、本文档共18页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
GoogleAppEngine技术架构资料大盘点pengzl的个人空间中文JAVA技术网javajava技术java软件java面试java教程java基础教程javajava技术java软件java面试java教程java基础教程.pdf
今天看到几篇有关Google App Engine 的技术架构文章,一起分享给大家,没看到过的同学赶紧惊喜一下吧,看到过了的同学
也假装惊喜一下嘛,呵呵。
全部文章有点长,请耐心看下去,相信程序员都是有耐心的,除了我
一、Google 的核心技术
在切入Google App Engine 之前,首先会对Google 的核心技术和其整体架构进行分析,以帮助大家之后更好地理解Google
App Engine 的实现。
本篇将主要介绍Google 的十个核心技术,而且可以分为四大类:
◆ 分布式基础设施:GFS、Chubby 和 Protocol Buffer。
◆ 分布式大规模数据处理:MapReduce 和 Sawzall。
◆ 分布式数据库技术:BigTable 和数据库 Sharding。
◆ 数据中心优化技术:数据中心高温化、12V 电池和服务器整合。
分布式基础设施
GFS
由于搜索引擎需要处理海量的数据,所以Google 的两位创始人Larry Page 和Sergey Brin 在创业初期设计一套名为BigFiles
的文件系统,而GFS(全称为Google File System)这套分布式文件系统则是BigFiles的延续。
首先,介绍它的架构,GFS 主要分为两类节点:
◆ Master 节点:主要存储与数据文件相关的元数据,而不是Chunk(数据块)。元数据包括一个能将64 位标签映射到数据块的
位置及其组成文件 的表格,数据块副本位置和哪个进程正在读写特定的数据块等。还有Master 节点会周期性地接收从每个
Chunk 节点来的更新(Heart- beat)来让元数据保持最新状态。
◆ Chunk 节点:顾名思义,肯定用来存储Chunk ,数据文件通过被分割为每个默认大小为64MB 的Chunk 的方式存储,而且
每个Chunk 有唯一一个64 位标签,并且每个Chunk 都会在整个分布式系统被复制多次,默认为3 次。
下图就是GFS 的架构图:
图1. GFS 的架构图(参片[15])
接着,在设计上,GFS 主要有八个特点:
◆ 大文件和大数据块:数据文件的大小普遍在GB 级别,而且其每个数据块默认大小为64MB ,这样做的好处是减少了元数据
的大小,能使Master 节点能够非常方便地将元数据放置在内存中以提升访问效率。
◆ 操作以添加为主:因为文件很少被删减或者覆盖,通常只是进行添加或者读取操作,这样能充分考虑到硬盘线性吞吐量大和
随机读写慢的特点。
◆ 支持容错:首先,虽然当时为了设计方便,采用了单Master 的方案,但是整个系统会保证每个Master 都会有其相对应的复
制品,以便于在 Master 节点出现问题时进行切换。其次,在Chunk 层,GFS 已经在设计上将节点失败视为常态,所以能非常
好地处理Chunk 节点失效的问题。
◆ 高吞吐量:虽然其单个节点的性能无论是从吞吐量还是延迟都很普通,但因为其支持上千的节点,所以总的数据吞吐量是非
常惊人的。
◆ 保护数据:首先,文件被分割成固定尺寸的数据块以便于保存,而且每个数据块都会被系统复制三份。
◆ 扩展能力强:因为元数据偏小,使得一个Master 节点能控制上千个存数据的Chunk 节点。
◆ 支持压缩:对于那些稍旧的文件,可以通过对它进行压缩,来节省硬盘空间,并且压缩率非常惊人,有时甚至接近90%。
◆ 用户空间:虽然在用户空间运行在运行效率方面稍差,但是更便于开发和测试,还有能更好利用Linux 的自带的一些POSIX
API。
现在Google 内部至少运行着200 多个GFS 集群,最大的集群有几千台服务器,并且服务于多个Google 服务,比如Google
搜索。但由于 GFS 主要为搜索而设计,所以不是很适合新的一些Google 产品,比YouTube、Gmail 和更强调大规模索引和
实时性的Caffeine 搜索引擎 等,所以Google 已经在开发下一代GFS ,代号为Colossus ,并且在设计方面有许多不同,比
如:支持分布式Master 节点来提升高可用性 并能支撑更多文件,Chunk 节点能支持1MB 大小的chunk 以支撑低延迟应用的
需要。
Chubby
简单的来说,Chubby 属于分布式锁服务,通过 Chubby ,一个分布式系统中的上千个client 都能够对于某项资源进行加锁
或者解锁 ,常用于BigTable 的协作工作,在实现方面是通过 对文件的创建操作来实现加锁 ,并基于著名科学家Leslie
Lamport 的Paxos 算法。
Protocol Buffer
Protocol
文档评论(0)