当前位置: 澳门新濠3559 > 服务器运维 > 正文

Google的全球基础设施启动了一个专有系统,主要

时间:2019-10-06 18:46来源:服务器运维
Google的全球基础设施启动了一个专有系统,当大型数据中不甘心和网络交换负荷出现硬件问题时自动转移和重复负载。 Google从来没有说过它的数据中心里有多少台服务器,不过Google的一

Google的全球基础设施启动了一个专有系统,当大型数据中不甘心和网络交换负荷出现硬件问题时自动转移和重复负载。

Google从来没有说过它的数据中心里有多少台服务器,不过Google的一位工程师在近日演讲时透露,他们的目标已经瞄向上百万台甚至一千万台。

上一篇我们比较详细地介绍了Google的核心技术,主要从Google的GFS、Chubby、Protocol Buffer、MapReduce、BigTable、Sharding等技术来讲它的核心技术。

澳门新濠3559 1

这种分布式的技术最早在今年夏季的一个叫做“Google经典时尚”(classically coy Google fashion)的会议中初露端倪,Google院士Jeff Dean在本月早些时候的一个研讨会上证实了这种技术的存在。

Google检索系统架构师Jeff Dean在美国计算机协会(ACM)组织的一次研讨会上发表了主题演讲,畅谈大型分布式系统,并阐述了Google在这方面的一些基础架构技术细节,揭示了他们是如何管理遍布全球各地的几十个数据中心的。

本文是基于现有的公开资料和个人的经验来对Google的整体架构进行总结和猜想。

The largest single database on earth - Google Spanner.

该平台被称为“Spanner”(扳手?)。在Dean的演示文稿中,这个平台被这样描述:“存储和计算系统,涵盖了数据中心自动移动,增强数据的复制和计算使用限制以及模式。”者包括了带宽、数据包丢失、资源限制、能耗以及“失败模式”。

Jeff Dean还提到了Google当前正在开发的一种新型存储与计算系统“Spanner”(扳手),主要用于横跨多个数据中心的Google服务的自动管理,能够在全球范围内自动、动态地安排数据和计算,并把延迟和成本降到最低。

在软件工程界,大家有一个共识,那就是"需求决定架构",也就是说,架构的发展是为了更好地支撑应用。那么本文在介绍架构之前,先介绍一下Google所提供的主要产品有哪些?

我们继续互联网技术架构-分布式存储。

Dean正在谈论的是“一整列机器资源的自动调配”——Google全球现在至少有36个大型数据中心,一些也许还在建。正如之前提到的,Google这个新系统正希望跨越一个大的数据中心舰队。

据称,这种系统可以管理100-1000万台服务器、100万亿个目录、1018字节数据(1ZB/1000000PB)、100-1000个数据中心、10亿台客户端。

产品

对于Google和它几个主要产品,比如搜索和邮件等,大家已经非常熟悉了,但是其提供服务的不只于此,并主要可分为六大类:

  • 各种搜索:网页搜索,图片搜索和视频搜索等。
  • 广告系统:AdWords和AdSense。
  • 生产力工具:Gmail和Google Apps等。
  • 地理产品:地图,Google Earth和Google Sky等。
  • 视频播放:Youtube。
  • PaaS平台:Google App Engine。

上文大篇幅介绍了一些分布式存储的理论,偏重理论。可别小看这些理论,Google的各个神器都是建立在这些理论之上,甚至整个Apache的大数据3剑客项目都是受惠于这些理论。难怪@Tiger大牛讲Google靠的是一大批世界顶尖数据,物理,计算领域的Ph.D.,这些大神以及他们的Paper是Google为什么是Google的原因,以及Google没有开源为什么依然强大的原因,其背后有着强大的基础研究团队。

从Dean的演讲中可以看出,Google希望Spanner能够控制一百万到一千万台服务器,包括10万亿(1013)目录和一千万亿(1018)字节的存储空间。而这所有一切分散在世界各地的数据中心。

对相关技术感兴趣的朋友可以下载Jeff Dean的演示文稿来研究一番

设计理念

根据现有的资料,Google的设计理念主要可以总结出下面这六条:

  • Scale,Scale,Scale Scale:因为Google大多数服务所面对的客户都是百万级别以上的,导致Scale也就是伸缩已经深深植入Google的DNA中,而且 Google为了帮助其开发人员更好地开发分布式应用和服务,不仅研发了用于大规模数据处理MapReduce框架,还推出了用于部署分布式应用的 PaaS平台Google App Engine。
  • 容错:一个分布式系统,就算是构建在昂贵的小型机或者大型机之上,也会不时地出现软件或者硬件方面的错误,何况Google的分布式系统还是浇筑在便宜的X86服务器之上,即使其设备标称的MTBF(平均故障间隔时间)很高,但是由于一个集群内的设备极多,导致其错误发生的几率非常高,比如李开复曾经提过这样一个例子:在一个拥有两万台X86服务器的集群中,每天大约有110台机器会出现宕机等恶劣情况,所以容错是一个不可被忽视的问题,同时这点也被Google院士Jeffrey Dean在多次演讲中提到。
  • 低延迟:延迟是影响用户体验的一个非常重要的因素,Google的副总裁Marissa Mayer曾经说过:"如果每次搜索的时间多延迟半秒的话,那么使用搜索服务的人将减少20%",从这个例子可以看出,低延迟对用户体验非常关键,而且为了避免光速和复杂网络环境造成的延时,Google已在很多地区设置了本地的数据中心。
  • 廉价的硬件和软件:由于Google每天所处理的数据和请求在规模上是史无前例的,所以现有的服务器和商业软件厂商是很难为Google"度身定做"一套分布式系统,而且就算能够设计和生产出来,其价格也是Google所无法承受的,所以其上百万台服务器基本采用便宜的X86系统和开源的 Linux,并开发了一整套分布式软件栈,其中就包括上篇提到的MapReduce,BigTable和GFS等。
  • 优先移动计算:虽然随着摩尔定律的不断发展,使得很多资源都处于不断地增长中,比如带宽等,但是到现在为止移动数据成本远大于移动计算的成本,所以在处理大规模数据的时候,Google还是倾向于移动计算,而不是移动数据。
  • 服务模式:在Google的系统中,服务是相当常用的,比如其核心的搜索引擎需要依赖700-1000个内部服务,而且服务这种松耦合的开发模式在测试,开发和扩展等方面都有优势,因为它适合小团队开发,并且便于测试。

总目录

想象一下:一个独立的大房子正在通过线缆控制着这个世界上其它的数据中心。

澳门新濠3559 2
位于美国俄勒冈州达尔斯的一个Google数据中心

整体架构的猜想

在整体架构这部分,首先会举出Google的三种主要工作负载,接着会试着对数据中心进行分类,最后会做一下总结。

三种工作负载

对于Google而言,其实工作负载并不仅仅只有搜索这一种,主要可以被分为三大类:

  • 本地交互:用于在用户本地为其提供基本的Google服务,比如网页搜索等,但会将内容的生成和管理工作移交给下面的内容交付系统,比如:生成搜索所需的Index等。通过本地交互,能让用户减少延迟,从而提高用户体验,而且其对SLA要求很高,因为是直接面对客户的。
  • 内容交付:用于为Google大多数服务提供内容的存储,生成和管理工作,比如创建搜索所需的Index,存储YouTube的视频和GMail 的数据等,而且内容交互系统主要基于Google自己开发那套分布式软件栈。还有,这套系统非常重视吞吐量和成本,而不是SLA。
  • 关键业务:主要包括Google一些企业级事务,比如用于企业日常运行的客户管理和人力资源等系统和赚取利润的广告系统(AdWords和AdSense),同时关键业务对SLA的要求非常高。

两类数据中心

按照2008年数据,Google在全球有37个数据中心,其中19个在美国,12个在欧洲,3个在亚洲(北京、香港、东京),另外3个分布于俄罗斯和南美。下图显示其中36个数据中心在全球的分布:

澳门新濠3559 3

                      图1. 2008年Google全球数据中心分布图

根据 Jeffrey Dean 在2009年末的一次演讲和最近几期季报可以推测出Google并没有在2009年过多地增加全球数据中心的数量,总数应该还是稍多于36个,但很有可能在台湾、马来西亚、立陶宛等地增加新的数据中心。

虽然Google拥有数据中心数量很多,但是它们之间存在一定的差异,而且主要可以分为两类:其一是巨型数据中心,其二是大中型数据中心。

巨型数据中心:服务器规模应该在十万台以上,常坐落于发电厂旁以获得更廉价的能源,主要用于Google内部服务,也就是内容交付服务,而且在设计方面主要关注成本和吞吐量,所以引入了大量的定制硬件和软件,来减低PUE并提升处理量,但其对SLA方面要求不是特别严厉,只要保证绝大部分时间可用即可。下图是Google巨型数据中心的一个代表,这个数据中心位于美国俄勒冈州北部哥伦比亚河畔的Dalles市,总占地面积接近30英亩,并占用了附近一个1.8GW水力发电站的大部分电力输出,当这个数据中心全部投入使用后,将消耗103兆瓦的电力,这相当于一个中小型城市的整个生活用电。

澳门新濠3559 4

                         图2. Google在美国俄勒冈州哥伦比亚河畔的巨型数据中心近景图

大中型数据中心:服务器规模在千台至万台左右,可用于本地交互或者关键业务,在设计方面上非常重视延迟和高可用性,使得其坐落地点尽可能地接近用户而且采用了标准硬件和软件,比如Dell的服务器和MySQL的数据库等,常见的PUE大概在1.5和1.9之间。本来坐落于北京朝阳区酒仙桥附近的"世纪互联"机房的Google中国数据中心也属于大中型数据中心这类,其采用的硬件有DELL的工作站和Juniper的防火墙等,下图为其一角。

澳门新濠3559 5

                 图3. Google前中国数据中心的一角(参[26])

关于两者的区别:具体请查看下表:

巨型数据中心
大中型数据中心

工作负载
内容交付
本地交互/关键业务

地点
离发电厂近
离用户近

设计特点
高吞吐,低成本
低延迟,高可用性

服务器定制化

SLA
普通

服务器数量
十万台以上
千台以上

数据中心数量
十个以内
几十个

PUE估值
1.2
1.5

表1. 巨型与大中型数据中心的对比表

总结

最后,稍微总结一下,首先,普通的用户当访问Google服务时,大多会根据其请求的IP地址或者其所属的ISP将这个请求转发到用户本地的数据中心,如果本地数据中心无法处理这个请求,它很有可能将这个请求转发给远端的内容交互中心。其次,当广告客户想接入Google的广告系统时,这个请求会直接转发至其专业的关键业务数据中心来处理。

澳门新濠3559 6

                                                 图4. 总结

因为本文是基于现有的公开资料和个人的经验的总结和猜想,所以和Google实际的运行情况没有任何联系。

我们还介绍过以下网站的架构信息:MySpace架构,Facebook架构,Yupoo网站架构,Amazon网站架构,Twitter网站架构,优酷网站架构

相信这些网站的架构能给喜欢架构的朋友开拓思路,下一篇我们将继续介绍Google App Engine的技术架构,感谢吴朱华,原文来自:dbanotes。

分布式存储概述

澳门新濠3559 7 

分布式存储特性 - 哈希分布/一致性哈希分布

Dean拒绝作出评论。Google的公关部门也没有就此问题给出具体的回复,不过Google工程与架构部门的高级经理Vijay Gill在此前旧金山举办的一个迷你会议上提到过这项技术。

分布式存储协议 - 两阶段与Paxos

当被问及“如果能够挥动魔杖以创建一个后端网络技术”时,Gill称,“我们现在没有这种技术,”当谈及Google著名的分布式在线基础设施时他略显神秘——Google将数据中心变成了“仓库规模”的机器,当某个数据中心出现超负荷危险时就转移到别的地方。

分布式文件系统 - Google GFS

“我们现在要做的是——当然了这是仓库规模的计算机,”Gill表示,你必须拥有从冷却到整合CPU等所有的权利。”

分布式键值系统- Alibaba Tair**

“有时候,有一个温度的变化,你可能需要一个快速的负载切换去组织温度的变化,你的数据中心有没有冷水机组?你想要降低一些负载,你希望减少一些CPU和一些RAM里的进程数。”

分布式表格系统- Google BigTable /Megastore

他表示公司可以做自动或者近乎自动不需人工干预的意义,“你怎么做全球范围内管理系统的优化呢?这是一个有趣的现象。”

分布式数据库系统****MySQL Sharding, Google Spanner / F1**

“我们现在看到,Google大规模以线性规划问题的变量数十万计,几乎都需要实时的计算。当一个数据中心里的温度开始变化时,你没有宝贵的时间去设定其它数据中心的温度,必须得在几秒钟内作出判断。”

1. 分布式文件系统

当被问及这是否Google正在使用的技术时,Gill回复说这只是Google最乐于见到的情况。“我无法做出评论,”他说,“我也不记得我们发表任何一个文件。”

GFS Google文件系统

但是看起来Gill描述的技术就是在说Spanner。而且根据Dean院士的演讲,似乎该技术已经被部署。Google还表示,其位于比利时Saint Ghislain得一个新数据中心也没有机组运行,显然,是用了Spanner技术才使得可以度过炎热的夏季。

提到分布式文件系统,当然首推GFS了。GFS是Google分布式存储的基石,所有的神器都是建立在分布式存储之上的,如Google BigTable, Google Megastore, Google Percolator, MapReduce等。

Dean表示,Spanner的目的是为50微妙之内的数据传递提供通道。而且,Google至少机会在欧洲部署两套存储设备以存储设备,在美国部署两套,在亚洲部署一套。

澳门新濠3559 8

显然,Google有做分布式计算的天赋。

GFS

  1. Google死亡会带来怎样的“互联网海啸”
  2. Google揭秘:高流量背后的零宽带费
  3. Google系统自带的Chrome浏览器曝光

GFS系统节点可以分为三种角色:GFS Master, GFS ChunkServer, GFS Client.

这种分布式的技术最...

GFS文件被划分固定大小的数据库,称为Chunk, 由Master分配一个64位全局唯一ID; ChunkServer(CS)以普通Linux文件形式将chunk存储在磁盘,为了HA, Chunk被replication,默认3份。

客户端访问GFS时,首先访问Master,获取CS信息,之后再去访问CS,完成数据存取。GFS目前主要用于MapReduce, Bigtable.

租约机制(Lease)

GFS追加的记录大小从即是KB到几十MB不等,为了避免Master变成系统瓶颈,GFS引入了租约机制,即将Chunk的写操作授权给ChunkServer。拥有租约授权的CS称为主ChunkServer。在租约有效期内,如60秒,对该chunk的写操作都由主CS负责。主CS也可以在租约到期后,不断向Master提出续约直到Chunk写满。

一致性模型

GFS支持一个宽松的一致性模型,GFS从相对需求以及简单化层名考虑,设计成主要是为了追加append而不是为了改写override的架构,如我们了解的

HBase。

看一下记录追加的流程:

澳门新濠3559 9

1)客户端向Master请求chunk每个副本所在CS

2)Master返回客户端主副本和备副本所在CS位置

3)客户端将追加记录发送给每一个副本,CS会内部LRU结构缓存这些数据

4)当所有副本都确认收到数据,客户端接着发起一个请求控制命令给主副本

5)主副本把写请求提交给所有副本。

6)备副本成功完成后应答主副本。

7)主副本响应客户端。

其中,分为控制流与数据流。

容错

1)Master容错:

与传统类似,通过操作日志加checkpoint来进行。

2)CS容错:

采用复制多个副本方式。

从GFS的架构可以看出,GFS是一个具有良好可扩展能力并可以自动处理各种异常的系统。Google的系统已开始就考虑了如河水平扩展,所以后续的系统能够站在巨人的肩膀上,如Bigtable建构在GFS之上,Megastore, Spanner又在

Biigtable之上融合了关系型数据库的功能,整个方案华丽,完美。

另外,Google的成功经验反过来证明了单Master是可行的,简化了系统同时实现了一致性。

2. 分布式键值系统

分布式键值类似于分布式表格模型Bigtable的一种特例。比较著名的有Amazon Dynamo, Memcache以及国内阿里的Tair系统。

前两天有伙伴提到Tair, 那我们就以Tail来聊聊吧。

Tair分布式系统

Tair是阿里/淘宝开发的一个分布式键/值存储系统,tair分为持久化和非持久化两种方式。非持久化的tair可以看作一个分布式缓存,持久化的tair将数据存放置磁盘,当然tair可以自动备份以避免磁盘损坏等问题。

系统架构:

澳门新濠3559 10

同样,Tair由一个Master和一系列Slave节点组成,称之为Config Server作为整体的控制中心,而服务节点为可伸缩的Data Server。Config Server负责管理所有的data server, 维护其状态信息。Data Server则对外提供各种数据服务,并以心跳来将自身信息反馈给config server。可以看到,Config Server是核心控制点,而且是单点,只有主-备形式保证其可靠性。

ConfigServer的功能

1) 通过维护和dataserver心跳获知集群中存活节点信息

2) 根据存活节点的信息来构建数据在集群中的分布表。

3) 提供数据分布表的查询服务。

4) 调度dataserver之间的数据迁移、复制。

另外ConfigServer实现了从配置文件load进节点信息,然后根据配置的数据分布的桶和需要建立的数据备份数,建立数据分布表,长度为桶数乘以备份数。如目前有1023个桶,备份3,所以长度为1023*3的数组。数组元素就是数据要存储的主节点信息,下标即桶号码。其中后面的1023*2为备份节点信息。为了负载均衡,主桶会尽量均匀分布到所有节点,备桶则根据策略,如不同数据中心来分布。

DataServer的功能

1) 提供存储引擎

2) 接受client的put/get/remove等操作

3) 执行数据迁移,复制等

4) 插件:在接受请求的时候处理一些自定义功能

5) 访问统计

操作层面

客户端首先请求Config Server获取数据所在Data Server, 之后向Data Server发送读写请求。

负载均衡

Tair采用分布式一致性哈希算法,可参考我们上一篇介绍,正所谓理论之基石。tair对于所有的key,分配到Q个桶,桶是负载均衡和数据迁移的基本单位。config server根据已定策略把每个桶指派到不同的data server,因为数据按照key做hash算法,所以每个桶中的数据基本平衡。

如下图:

澳门新濠3559 11

一致性和可靠性:

分布式系统中的可靠性和一致性是无法同时保证的,因为有网络错误. tair采用复制技术来提高可靠性,并做了一些优化,当无网络错误的时候, tair提供的是一种强一致性.但是在有data server发生故障的时候,客户有可能在一定时间窗口内读不到最新的数据.甚至发生最新数据丢失的情况.

参考:

3. 分布式表格系统

顾名思义,表格模型,多行多列,通过主键唯一标识。如始祖Google Bigtable

Google Bigtable:

基于GFS与Chubby的分布式表格系统,目标是解决读取速度,许多Google数据如web索引,卫星图像数据都存放在bigtabe。

整体结构:

(row:string, column:string, timestamp:int64) -> string

澳门新濠3559 12

RowKey为任意字符串,长度小于64kb。整个数据按照主键进行排序,字典排序,如果域名的话通常使用反向变换来排序,这样可以做到二级,子域名可以连续。

系统架构:

澳门新濠3559 13

Bigtable

总体分为客户端,主控服务器和子表服务器Tablet Server。 Bigtable把大表分割为100-200m的子表tablet。

Master:

管理所有子表tablet server,暴扣分配子表给子表服务器,子表合并,以及接受子表分裂消息,监控子表服务器,以及在子表实现负载均衡与故障恢复。

Tablet Server:

子表服务器,实现子表的装载/卸载,以及表格内容的读写,合并,分裂。其服务的数据包含操作日志及子表sstable数据,而数据保存于底层GFS中。

Chubby:

Google的分布式服务,zk的鼻祖。底层核心算法就是我们上文提及的Paxos,即多数派达成一致,类似昨天的英国公投脱欧。Chubby作为整个bigtable的核心,如果发生故障,则整个bigtabe不可用。Chubby为了保持HA, 通常大型部署结构为两地三数据中心五副本

为什么需要五个副本?

理论上3个数据中心就已经很高可用了,为什么要选择5个呢?假如只部署在3个数据中心,一个挂了后剩余两个必须不能挂,因为commit成功在Paxos协议里需要至少2节点;但如果第二个节点又挂了此时就真的无法访问了,为了高可用,所以选择了5个数据中心节点.

Chubby在Bigtable中提供了/辅助了以下核心功能:

1)选取并保证同一时间有且只有一个主控服务器master

2)保存bigtable系统引导信息

3)配合master发现子表服务器加载与卸载

4)获取bigtable的schema信息以及访问控制信息

Bigtable

分为用户表(User Table), 元数据表(Meta Table)和根表(Root Table)。客户段查询时,首先访问Chubby读取根表位置,再从根表读取所需元数据子表的位置。

复制与一致性:

Bigtable采用强一致性,同一时刻同一个子表只能被一台tablet server服务,master需要来控制这种一致性,而这也是通过Chubby的分布式互斥锁机制来保证的。

GFS Bigtable两层架构以一种优雅的方式兼顾系统的强一致和HA。底层的GFS是弱一致性,可用性和性能很好,但是多客户追加可能会出现重复记录等数据不一致问题;上层的Bigtable通过多级分布式索引使得系统对外表现为强一致。Bigtable最大优势在于线性扩展,单机出现故障,可以将服务(1分钟内)自动迁移到整个集群。

Google Megastore:

Megastore在Bigtable的基础上,提供了数据库功能的支持,介于关系型数据库与NoSQL之间的存储。Google在其公开的Megastore论文中指出,传统的关系型数据库在Google已经被否定,如MySQL。昂贵的商业数据库会大幅加大用户在云中大幅部署的总成本。

Megastore设计原理与精髓在于,能够在广域网中同步复制文件写操作,可接受的延时,支持数据中心的故障迁移。论文还透漏,目前Google以及有100多个生产应用Megastore作为存储服务,其可靠度在99.99%-100%,并且平均读取延迟小于万分之一毫秒,写入延迟100-400毫秒。

系统架构如下:

澳门新濠3559 14

客户端库Megastore Library:

提供应用程序的接口,包括映射megastore操作到bigtable,事务及并发控制,基于Paxos的复制,将请求分发给复制服务器,通过协调者快速读写。

复制服务器Replication:

接受客户端的用户请求并转发到所在机房的bigtable实例解决跨机房连接数过多的问题。

协调者Coord.

存储每个机房本地的实体组是否处于最新状态信息,实现快速读写。

Megastore主要功能分为:映射Megastore到Bigtable; 事务并发控制;跨机房数据复制与读写优化。

操作流程:

首先解析用户的SQL,接着根据用户定义的Megastore数据模型将sSQL转换为底层对应的Bigtable。

数据复制Replication

数据拆分成不同的实体组,每个实体组内的操作日志采用基于Paxos的方式同步到多个机房保持强一致性。实体组之间通过分布式队列或者两阶段提交协议实现分布式事务。

澳门新濠3559 15

如上图所示,Megastore的数据复制是通过paxos进行同步复制的,即如果更新一个数据,所有机房都会进行同步更新,因为使用了paxos协议,所以不同机房真对同一条数据的更新复制到所有机房的更新顺序都是一致的;同步复制保证了数据的实时可见性,采用paxos算法则保证了所有机房的更新一致性。

Megastore主要创新:

1) 包括提出了实体组的数据模型,实体组内部维持了关系数据库的ACID特性,实体组之间维持NoSQL弱一致性,创新的融合了SQL和NoSQL的优势。另外实体组的定义规避了性能杀手Join。

2) 通过Paxos协议同时保证了高可靠与高可用,既可把数据强同步到多个机房,又做到发生故障时自动切换不影响读写服务。

分布式存储系统有两个目标:可扩展性 + 全功能SQL在Megastore上基本实现了。当然,Megastore也有一些问题,其中一些来源于底层Bigtable,如单副本等等。实际上,在Google, Megastore已经过时,并重新开发了一套革命性的分布式系统Spanner用于解决这些问题。

4. 分布式数据库

关系型数据库汇集了计算机领域的智慧,也为如今互联网,大数据做好了铺垫。在互联网时代,如何水平扩展是传统关系型数据的最大挑战。

MySQL Sharding

通常水平扩展的做法是应用层按照规则将数据查分到多个分片,分布到多个数据库节点,并引入一个中间层应用来屏蔽后段的拆分细节。

同样,在MySQL Sharding中也是类似:

澳门新濠3559 16

如上图,总体分为:应用端,中间层dbproxy集群,数据库组,元数据服务器等。

1)应用端/客户端:通过MySQL与客户端交互,支持JDBC,使得原有单机数据库无缝对接。

2)中间层dbproxy:解析客户SQL,并转发到后端数据库。解析MySQL协议,执行SQL路由,过滤,读写分离,结果归并,排序以及分组等。另外可以引入LVS(Linux Virtual Server)进行负载均衡。

3)数据库组dbgroup:每个dbgroup由n台数据库机器组成,一台master,剩余为slave。master负责所有些事务及强一致读,并复制到备机。

4)元数据服务器:维护dbgroup拆分规则并用于dbgroup选主。dbproxy通过元数据服务器拆分规则确定SQL的执行计划。另外采用zk来实现多个副本HA。

值得注意的是,如果请求数据只涉及一个数据库组,则中间层将请求转发并等待返回结果给客户端;如涉及多个数据库分组,则由中间层将结果执行合并,分组,排序等操作后返回给客户端,中间层协议与MySQL兼容,所以透明于客户端。

Google Spanner

终于到Google Spanner登场了,Google Spanne是Google全球级分布式数据库存储系统。Spanner的扩展性达到了全球级,可以扩展数百个数据中心,数百万台机器,上万亿行记录。

澳门新濠3559 17

澳门新濠3559,Spanner使得分布式技术与数据库技术有机的结合起来,分布式可扩展,而数据库则类关系型数据模型。

重温CAP理论:

澳门新濠3559 18

上图的CAP定理是指在网络可能出现分区故障的情况下,一致性和可用性不可得兼。例如在银行等应用领域,一致性是非常重要的。又如我们熟知的MongoDB并不支持复杂的事务,只支持少量的原子操作,所以不适用于“转帐”等对事务和一致性要求很高的场合。这就要求需要一个关系数据库来对 交易进行过高级别的控制。

Spanner同时支持同步复制,多版本控制,以及跨数据中心事务,完全冲破CAP的枷锁,在三者之间完美平衡。无论从学术还是工程,Spanner可谓一个划时代的分布式存储系统。Spanner能做到这些,Google使用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此实现了功能:无锁读事务,原子schema修改,读历史数据无block。

Google F1 RDBMS

说到Spanner, 我们不得不提一下F1,赛车?Google研究院推出命名为F1的新数据库,F1是Google全新建立的新RDBMS数据库,作为一种混合型数据库融合了BigTable的高扩展性和SQL数据库的可用性和功能性。支持拥有伸缩性很强的数据库,而不必转向NoSQL。

澳门新濠3559 19

如上图,F1目前支撑着谷歌的AdWords核心业务, 而AdWords的后台F1已经从MySQL分库分表迁移到了Spanner。

F1系统架构及功能:

澳门新濠3559 20

为什么Google还需要F1,而不是都使用BigTable呢?因为BigTable提供的最终一致性,一些需要事务级别的应用无法使用。同时BigTable还是NoSql,而大量的应用场景需要有关系模型。就像现在大量的互联网企业都使用Mysql而不愿意使用HBase,因此Google才有这个可扩展数据库的F1.而Spanner就是F1的至关重要的底层存储技术。

Spanner数据模型

数据模型类似Megastore系统。Spanner的表是层次化的,最底层是目录表directory,其它表创建时可以使用INTERLEAVE IN PARENT表示层次关系。其中目录类似于megastore中的实体组,实际存储时,会将同一个目录的数据放到一起,同一个目录的每个副本都会分配到同一台机器。因此,针对同一个目录的读写事物通常不会涉及跨机器,除非目录非常非常之巨大。

澳门新濠3559 21

Google全新设计了GFS 2- Colossus之上,主要改进了实时性,并支持海量小文件。

Spanner基本概念

Universe:一个Spanner部署实例称之为一个Universe, 目前全世界只有3个,一个用于开发,一个测试,一个线上。

Zones:每个zone属于一个数据中心,而一个数据中心可以包含多个zone。跨zone通信代价较高。

Universe Master:监控这个实例中的zone级别状态信息

Placement Driver: 提供跨zone数据迁移

Location Proxy:提供获取数据位置信息服务;

Spanserver: 提供存储服务,类似于bigtable中的tablet server

澳门新濠3559 22

Spanner也是通过Paxos协议实现跨数据中心多个副本的一致性。每个主副本所在的spanserver还会实现一个锁用于并发控制。

TrueTime

为了实现并发,数据库需要给每个事务分配全局唯一事务ID。然而,在分布式系统中,很难生成全局唯一ID。Google创意的选用了TrueTime机制。

TrueTime是一个提供本地时间的接口,可以同步全球时间。这个API的实现靠的是GPS与原子钟。引入了两种,是避免当GPS受到干扰失败后,原子钟则非常稳定,不会出现偏差。实际部署中,每个数据中心都需要部署Master机器,其它机器则需要Slave来从Master同步。

有了TrueTime, Spanner并可以控制并发,实现外部一致性,支持以下事务:

读写,只读,快照读,读写事务。

[Google2012] James C. Corbett, Jeffrey Dean, Michael Epstein, etc. Spanner: Google’s Globally-Distributed Database.OSDI’2012.

我们非常期望看到类似Spanner和F1的山寨开源产品。当然,在2014年以及去年2015年,我们看到一个类似于Spanner的开源项目,值得注意的是其作者是前Google员工,CockroachDB,中文叫蟑螂?打不死的小强。目前

CockroachDB已经推出Beta版本,并且获得高额风投。

CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

过去十年,在中国睡觉的时候,美国靠着强大的基础研究与高尖工程师在的硅谷打造了一个全新的互联网+DT时代;未来十年,在美国人睡觉的时候,中国的企业也开始大量注重基础研究,中国会胜出么?

好了,我们分布式存储到此暂告一段落,写作辛苦,其中参考了大量网络资源,包括英文文档。此文基本上属于科普,入门级作品,作者希望在学习过程中一起分享给极客朋友。

澳门新濠3559 23

关注公众号:技术极客TechBooster

澳门新濠3559 24

编辑:服务器运维 本文来源:Google的全球基础设施启动了一个专有系统,主要

关键词: 澳门新濠3559