您的位置:新葡亰496net > 服务器网络 > 新葡亰496netEngine技术架构之Google的整体架构猜想

新葡亰496netEngine技术架构之Google的整体架构猜想

发布时间:2019-09-17 06:43编辑:服务器网络浏览(196)

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

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

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

    新葡亰496net 1

    Google Spanner简介

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

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

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

    The largest single database on earth - Google Spanner.

    Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级,可以扩展到数百万的机器,数已百计的数据中心,上万亿的行。更给力的是,除了夸张的扩展性之外,他还能 同时通过同步复制和多版本来满足外部一致性,可用性也是很好的。冲破CAP的枷锁,在三者之间完美平衡。

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

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

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

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

    新葡亰496net 2

    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没有开源为什么依然强大的原因,其背后有着强大的基础研究团队。

    Spanner是个可扩展,多版本,全球分布式还支持同步复制的数据库。他是Google的第一个可以全球扩展并且支持外部一致的事务。 Spanner能 做到这些,离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此有几个给力的功能:无锁读事务, 原子schema修改,读历史数据无block。

    从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个内部服务,而且服务这种松耦合的开发模式在测试,开发和扩展等方面都有优势,因为它适合小团队开发,并且便于测试。

    总目录

    EMC中国研究院实时紧盯业界动态,Google最近发布的一篇论文《Spanner: Google’s Globally-Distributed Database》, 笔者非常感兴趣,对Spanner进行了一些调研,并在这里分享。由于Spanner并不是开源产品,笔者的知识主要来源于Google的公开资料,通过现有公开资料仅仅只能窥得Spanner的沧海一粟,Spanner背后还依赖有大量Google的专有技术。

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

    新葡亰496net 3
    位于美国俄勒冈州达尔斯的一个Google数据中心

    整体架构的猜想

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

    三种工作负载

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

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

    两类数据中心

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

    新葡亰496net 4

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

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

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

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

    新葡亰496net 5

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

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

    新葡亰496net 6

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

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

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

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

    地点
    离发电厂近
    离用户近

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

    服务器定制化

    SLA
    普通

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

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

    PUE估值
    1.2
    1.5

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

    总结

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

    新葡亰496net 7

                                                     图4. 总结

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

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

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

    分布式存储概述

    下文主要是Spanner的背景,设计和并发控制。

    新葡亰496net 8 

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

     

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

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

    Spanner背景

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

    分布式文件系统 - Google GFS

    要搞清楚Spanner原理,先得了解Spanner在Google的定位。
    新葡亰496net 9
    从上图可以看到。Spanner位于F1和GFS之间,承上启下。所以先提一提F1和GFS。

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

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

     

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

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

    F1

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

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

    和众多互联网公司一样,在早期Google大量使用了Mysql。Mysql是单机的,可以用Master-Slave来容错,分区来扩展。但是需 要大量的手工运维工作,有很多的限制。因此Google开发了一个可容错可扩展的RDBMS——F1。和一般的分布式数据库不同,F1对应RDMS应有的 功能,毫不妥协。起初F1是基于Mysql的,不过会逐渐迁移到Spanner。

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

    1. 分布式文件系统

    F1有如下特点:

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

    GFS Google文件系统

    ·        7×24高可用。哪怕某一个数据中心停止运转,仍然可用。

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

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

    ·        可以同时提供强一致性和弱一致。

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

    新葡亰496net 10

    ·        可扩展

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

    GFS

    ·        支持SQL

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

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

    ·        事务提交延迟50-100ms,读延迟5-10ms,高吞吐

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

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

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

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

     

    租约机制(Lease)

    Colossus(GFS II)

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

    Colossus也是一个不得不提起的技术。他是第二代GFS,对应开源世界的新HDFS。GFS是著名的分布式文件系统。
    新葡亰496net 11
    初代GFS是为批处理设计的。对于大文件很友好,吞吐量很大,但是延迟较高。所以使用他的系统不得不对GFS做各种优化,才能获得良好的性能。那为什么 Google没有考虑到这些问题,设计出更完美的GFS ?因为那个时候是2001年,Hadoop出生是在2007年。如果Hadoop是世界领先水平的话,GFS比世界领先水平还领先了6年。同样的 Spanner出生大概是2009年,现在我们看到了论文,估计Spanner在Google已经很完善,同时Google内部已经有更先进的替代技术在 酝酿了。笔者预测,最早在2015年才会出现Spanner和F1的山寨开源产品。

    一致性模型

    Colossus是第二代GFS。Colossus是Google重要的基础设施,因为他可以满足主流应用对FS的要求。Colossus的重要改进有:

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

    ·        优雅Master容错处理 (不再有2s的停止服务时间)

    HBase。

    ·        Chunk大小只有1MB (对小文件很友好)

    看一下记录追加的流程:

    ·        Master可以存储更多的Metadata(当Chunk从64MB变为1MB后,Metadata会扩大64倍,但是Google也解决了)

    新葡亰496net 12

    Colossus可以自动分区Metadata。使用Reed-Solomon算法来复制,可以将原先的3份减小到1.5份,提高写的性能,降低延迟。客户端来复制数据。具体细节笔者也猜不出。

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

     

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

    与BigTable, Megastore对比

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

    Spanner主要致力于跨数据中心的数据复制上,同时也能提供数据库功能。在Google类似的系统有BigTable和Megastore。和这两者相比,Spanner又有什么优势呢。

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

    BigTable在Google得到了广泛的使用,但是他不能提供较为复杂的Schema,还有在跨数据中心环境下的强一致性。Megastore 有类RDBMS的数据模型,同时也支持同步复制,但是他的吞吐量太差,不能适应应用要求。Spanner不再是类似BigTable的版本化 key-value存储,而是一个“临时多版本”的数据库。何为“临时多版本”,数据是存储在一个版本化的关系表里面,存储的时间数据会根据其提交的时间 打上时间戳,应用可以访问到较老的版本,另外老的版本也会被垃圾回收掉。

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

    Google官方认为 Spanner是下一代BigTable,也是Megastore的继任者。

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

     

    7)主副本响应客户端。

    Google Spanner设计

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

    功能

    容错

    从高层看Spanner是通过Paxos状态机将分区好的数据分布在全球的。数据复制全球化的,用户可以指定数据复制的份数和存储的地点。 Spanner可以在集群或者数据发生变化的时候将数据迁移到合适的地点,做负载均衡。用户可以指定将数据分布在多个数据中心,不过更多的数据中心将造成 更多的延迟。用户需要在可靠性和延迟之间做权衡,一般来说复制1,2个数据中心足以保证可靠性。

    1)Master容错:

    作为一个全球化分布式系统,Spanner提供一些有趣的特性。

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

    ·        应用可以细粒度的指定数据分布的位置。精确的指定数据离用户有多远,可以有效的控制读延迟(读延迟取决于最近的拷贝)。指定数据拷贝之间有多远,可以控制 写的延迟(写延迟取决于最远的拷贝)。还要数据的复制份数,可以控制数据的可靠性和读性能。(多写几份,可以抵御更大的事故)

    2)CS容错:

    ·        Spanner还有两个一般分布式数据库不具备的特性:读写的外部一致性,基于时间戳的全局的读一致。这两个特性可以让Spanner支持一致的备份,一致的MapReduce,还有原子的Schema修改。

    新葡亰496netEngine技术架构之Google的整体架构猜想,不是美元。采用复制多个副本方式。

    这写特性都得益有Spanner有一个全球时间同步机制,可以在数据提交的时候给出一个时间戳。因为时间是系列化的,所以才有外部一致性。这个很容易理解,如果有两个提交,一个在T1,一个在T2。那有更晚的时间戳那个提交是正确的。

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

    这个全球时间同步机制是用一个具有GPS和原子钟的TrueTime API提供了。这个TrueTime API能够将不同数据中心的时间偏差缩短在10ms内。这个API可以提供一个精确的时间,同时给出误差范围。Google已经有了一个TrueTime API的实现。笔者觉得这个TrueTimeAPI 非常有意义,如果能单独开源这部分的话,很多数据库如MongoDB都可以从中受益。

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

    体系结构

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

    Spanner由于是全球化的,所以有两个其他分布式数据库没有的概念。

    2. 分布式键值系统

    ·        Universe。一个Spanner部署实例称之为一个Universe。目前全世界有3个。一个开发,一个测试,一个线上。因为一个Universe就能覆盖全球,不需要多个。

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

    ·        Zones. 每个Zone相当于一个数据中心,一个Zone内部物理上必须在一起。而一个数据中心可能有多个Zone。可以在运行时添加移除Zone。一个Zone可以理解为一个BigTable部署实例。
    新葡亰496net 13

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

     

    Tair分布式系统

    如图所示。一个Spanner有上面一些组件。实际的组件肯定不止这些,比如TrueTime API Server。如果仅仅知道这些知识,来构建Spanner是远远不够的。但Google都略去了。那笔者就简要介绍一下。

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

    ·        Universemaster: 监控这个universe里zone级别的状态信息

    系统架构:

    ·        Placement driver:提供跨区数据迁移时管理功能

    ·        Zonemaster:相当于BigTable的Master。管理Spanserver上的数据。

    新葡亰496net 14

    ·        Location proxy:存储数据的Location信息。客户端要先访问他才知道数据在那个Spanserver上。

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

    ·        Spanserver:相当于BigTable的ThunkServer。用于存储数据。

    ConfigServer的功能

    可以看出来这里每个组件都很有料,但是Google的论文里只具体介绍了Spanserver的设计,笔者也只能介绍到这里。下面详细阐述Spanserver的设计。

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

     

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

    Spanserver

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

    本章详细介绍Spanserver的设计实现。Spanserver的设计和BigTable非常的相似。参照下图
    新葡亰496net 15
    从下往上看。每个数据中心会运行一套Colossus (GFS II) 。每个机器有100-1000个tablet。Tablet概念上将相当于数据库一张表里的一些行,物理上是数据文件。打个比方,一张1000行的表,有 10个tablet,第1-100行是一个tablet,第101-200是一个tablet。但和BigTable不同的是BigTable里面的 tablet存储的是Key-Value都是string,Spanner存储的Key多了一个时间戳:

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

    (Key: string, timestamp: int64) ->string。

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

    因此spanner天生就支持多版本,tablet在文件系统中是一个B-tree-like的文件和一个write-ahead日志。

    DataServer的功能

    每个Tablet上会有一个Paxos状态机。Paxos是一个分布式一致性协议。Table的元数据和log都存储在上面。Paxos会选出一个 replica做leader,这个leader的寿命默认是10s,10s后重选。Leader就相当于复制数据的master,其他replica的 数据都是从他那里复制的。读请求可以走任意的replica,但是写请求只有去leader。这些replica统称为一个paxos group。

    1) 提供存储引擎

    每个leader replica的spanserver上会实现一个lock table还管理并发。Lock table记录了两阶段提交需要的锁信息。但是不论是在Spanner还是在BigTable上,但遇到冲突的时候长时间事务会将性能很差。所以有一些操 作,如事务读可以走lock table,其他的操作可以绕开lock table。

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

    每个leader replica的spanserver上还有一个transaction manager。如果事务在一个paxos group里面,可以绕过transaction manager。但是一旦事务跨多个paxos group,就需要transaction manager来协调。其中一个Transactionmanager被选为leader,其他的是slave听他指挥。这样可以保证事务。

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

     

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

    Directories and Placement

    5) 访问统计

    之所以Spanner比BigTable有更强的扩展性,在于Spanner还有一层抽象的概念directory, directory是一些key-value的集合,一个directory里面的key有一样的前缀。更妥当的叫法是bucketing。 Directory是应用控制数据位置的最小单元,可以通过谨慎的选择Key的前缀来控制。据此笔者可以猜出,在设计初期,Spanner是作为F1的存 储系统而设立,甚至还设计有类似directory的层次结构,这样的层次有很多好处,但是实现太复杂被摒弃了。

    操作层面

    Directory作为数据放置的最小单元,可以在paxos group里面移来移去。Spanner移动一个directory一般出于如下几个原因:

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

    ·        一个paxos group的负载太大,需要切分

    负载均衡

    ·        将数据移动到access更近的地方

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

    ·        将经常同时访问的directory放到一个paxos group里面

    如下图:

    Directory可以在不影响client的前提下,在后台移动。移动一个50MB的directory大概需要的几秒钟。

    新葡亰496net 16

    那么directory和tablet又是什么关系呢。可以理解为Directory是一个抽象的概念,管理数据的单元;而tablet是物理的东 西,数据文件。由于一个Paxos group可能会有多个directory,所以spanner的tablet实现和BigTable的tablet实现有些不同。BigTable的 tablet是单个顺序文件。Google有个项目,名为Level DB,是BigTable的底层,可以看到其实现细节。而Spanner的tablet可以理解是一些基于行的分区的容器。这样就可以将一些经常同时访问 的directory放在一个tablet里面,而不用太在意顺序关系。

    一致性和可靠性:

    在paxos group之间移动directory是后台任务。这个操作还被用来移动replicas。移动操作设计的时候不是事务的,因为这样会造成大量的读写 block。操作的时候是先将实际数据移动到指定位置,然后再用一个原子的操作更新元数据,完成整个移动过程。

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

    Directory还是记录地理位置的最小单元。数据的地理位置是由应用决定的,配置的时候需要指定复制数目和类型,还有地理的位置。比如(上海, 复制2份;南京复制1分) 。这样应用就可以根据用户指定终端用户实际情况决定的数据存储位置。比如中国队的数据在亚洲有3份拷贝, 日本队的数据全球都有拷贝。

    参考:

    前面对directory还是被简化过的,还有很多无法详述。

    3. 分布式表格系统

     

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

    数据模型

    Google Bigtable:

    Spanner的数据模型来自于Google内部的实践。在设计之初,Spanner就决心有以下的特性:

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

    ·        支持类似关系数据库的schema

    整体结构:

    ·        Query语句

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

    ·        支持广义上的事务

    为何会这样决定呢?在Google内部还有一个Megastore,尽管要忍受性能不够的折磨,但是在Google有300多个应用在用它,因为 Megastore支持一个类似关系数据库的schema,而且支持同步复制 (BigTable只支持最终一致的复制) 。使用Megastore的应用有大名鼎鼎的Gmail, Picasa, Calendar, Android Market和AppEngine。 而必须对Query语句的支持,来自于广受欢迎的Dremel,笔者不久前写了篇文章来介绍他。 最后对事务的支持是比不可少了,BigTable在Google内部被抱怨的最多的就是其只能支持行事务,再大粒度的事务就无能为力了。Spanner的 开发者认为,过度使用事务造成的性能下降的恶果,应该由应用的开发者承担。应用开发者在使用事务的时候,必须考虑到性能问题。而数据库必须提供事务机制, 而不是因为性能问题,就干脆不提供事务支持。

    新葡亰496net 17

    数据模型是建立在directory和key-value模型的抽象之上的。一个应用可以在一个universe中建立一个或多个 database,在每个database中建立任意的table。Table看起来就像关系型数据库的表。有行,有列,还有版本。Query语句看起来 是多了一些扩展的SQL语句。

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

    Spanner的数据模型也不是纯正的关系模型,每一行都必须有一列或多列组件。看起来还是Key-value。主键组成Key,其他的列是Value。但这样的设计对应用也是很有裨益的,应用可以通过主键来定位到某一行。
    新葡亰496net 18
    上图是一个例子。对于一个典型的相册应用,需要存储其用户和相册。可以用上面的两个SQL来创建表。Spanner的表是层次化的,最顶层的表是 directory table。其他的表创建的时候,可以用interleave in parent来什么层次关系。这样的结构,在实现的时候,Spanner可以将嵌套的数据放在一起,这样在分区的时候性能会提升很多。否则Spanner 无法获知最重要的表之间的关系。

    系统架构:

     

    TrueTime
    新葡亰496net 19
    TrueTime API 是一个非常有创意的东西,可以同步全球的时间。上表就是TrueTime API。TT.now()可以获得一个绝对时间TTinterval,这个值和UnixTime是相同的,同时还能够得到一个误差e。 TT.after(t)和TT.before(t)是基于TT.now()实现的。

    新葡亰496net 20

    那这个TrueTime API实现靠的是GFS和原子钟。之所以要用两种技术来处理,是因为导致这两个技术的失败的原因是不同的。GPS会有一个天线,电波干扰会导致其失灵。原子钟很稳定。当GPS失灵的时候,原子钟仍然能保证在相当长的时间内,不会出现偏差。

    Bigtable

    实际部署的时候。每个数据中心需要部署一些Master机器,其他机器上需要有一个slave进程来从Master同步。有的Master用 GPS,有的Master用原子钟。这些Master物理上分布的比较远,怕出现物理上的干扰。比如如果放在一个机架上,机架被人碰倒了,就全宕了。另外 原子钟不是并很贵。Master自己还会不断比对,新的时间信息还会和Master自身时钟的比对,会排除掉偏差比较大的,并获得一个保守的结果。最终 GPS master提供时间精确度很高,误差接近于0。

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

    每个Slave后台进程会每个30秒从若干个Master更新自己的时钟。为了降低误差,使用Marzullo算法。每个slave还会计算出自己的误差。这里的误差包括的通信的延迟,机器的负载。如果不能访问Master,误差就会越走越大,知道重新可以访问。

    Master:

     

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

    Google Spanner并发控制

    Tablet Server:

    Spanner使用TrueTime来控制并发,实现外部一致性。支持以下几种事务。

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

    ·        读写事务

    Chubby:

    ·        只读事务

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

    ·        快照读,客户端提供时间戳

    为什么需要五个副本?

    ·        快照读,客户端提供时间范围

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

    例如一个读写事务发生在时间t,那么在全世界任何一个地方,指定t快照读都可以读到写入的值。
    新葡亰496net 21
    上表是Spanner现在支持的事务。单独的写操作都被实现为读写事务 ; 单独的非快照被实现为只读事务。事务总有失败的时候,如果失败,对于这两种操作会自己重试,无需应用自己实现重试循环。

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

    时间戳的设计大大提高了只读事务的性能。事务开始的时候,要声明这个事务里没有写操作,只读事务可不是一个简单的没有写操作的读写事务。它会用一个 系统时间戳去读,所以对于同时的其他的写操作是没有Block的。而且只读事务可以在任意一台已经更新过的replica上面读。

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

    对于快照读操作,可以读取以前的数据,需要客户端指定一个时间戳或者一个时间范围。Spanner会找到一个已经充分更新好的replica上读取。

    2)保存bigtable系统引导信息

    还有一个有趣的特性的是,对于只读事务,如果执行到一半,该replica出现了错误。客户端没有必要在本地缓存刚刚读过的时间,因为是根据时间戳读取的。只要再用刚刚的时间戳读取,就可以获得一样的结果。

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

     

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

    读写事务

    Bigtable

    正如BigTable一样,Spanner的事务是会将所有的写操作先缓存起来,在Commit的时候一次提交。这样的话,就读不出在同一个事务中写的数据了。不过这没有关系,因为Spanner的数据都是有版本的。

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

    在读写事务中使用wound-wait算法来避免死锁。当客户端发起一个读写事务的时候,首先是读操作,他先找到相关数据的leader replica,然后加上读锁,读取最近的数据。在客户端事务存活的时候会不断的向leader发心跳,防止超时。当客户端完成了所有的读操作,并且缓存 了所有的写操作,就开始了两阶段提交。客户端闲置一个coordinator group,并给每一个leader发送coordinator的id和缓存的写数据。

    复制与一致性:

    leader首先会上一个写锁,他要找一个比现有事务晚的时间戳。通过Paxos记录。每一个相关的都要给coordinator发送他自己准备的那个时间戳。

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

    Coordinatorleader一开始也会上个写锁,当大家发送时间戳给他之后,他就选择一个提交时间戳。这个提交的时间戳,必须比刚刚的所有时间戳晚,而且还要比TT.now() 误差时间 还有晚。这个Coordinator将这个信息记录到Paxos。

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

    在让replica写入数据生效之前,coordinator还有再等一会。需要等两倍时间误差。这段时间也刚好让Paxos来同步。因为等待之 后,在任意机器上发起的下一个事务的开始时间,都比如不会比这个事务的结束时间早了。然后coordinator将提交时间戳发送给客户端还有其他的 replica。他们记录日志,写入生效,释放锁。

    Google Megastore:

     

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

    只读事务

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

    对于只读事务,Spanner首先要指定一个读事务时间戳。还需要了解在这个读操作中,需要访问的所有的读的Key。Spanner可以自动确定Key的范围。

    系统架构如下:

    如果Key的范围在一个Paxos group内。客户端可以发起一个只读请求给group leader。leader选一个时间戳,这个时间戳要比上一个事务的结束时间要大。然后读取相应的数据。这个事务可以满足外部一致性,读出的结果是最后 一次写的结果,并且不会有不一致的数据。

    新葡亰496net 22

    如果Key的范围在多个Paxos group内,就相对复杂一些。其中一个比较复杂的例子是,可以遍历所有的group leaders,寻找最近的事务发生的时间,并读取。客户端只要时间戳在TT.now().latest之后就可以满足要求了。

    客户端库Megastore Library:

     

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

    最后的话

    复制服务器Replication:

    本文介绍了GoogleSpanner的背景,设计和并发控制。希望不久的将来,会有开源产品出现。

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

    协调者Coord.

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

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

    操作流程:

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

    数据复制Replication

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

    新葡亰496net 23

    如上图所示,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中也是类似:

    新葡亰496net 24

    如上图,总体分为:应用端,中间层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的扩展性达到了全球级,可以扩展数百个数据中心,数百万台机器,上万亿行记录。

    新葡亰496net 25

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

    重温CAP理论:

    新葡亰496net 26

    上图的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。

    新葡亰496net 27

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

    F1系统架构及功能:

    新葡亰496net 28

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

    Spanner数据模型

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

    新葡亰496net 29

    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

    新葡亰496net 30

    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时代;未来十年,在美国人睡觉的时候,中国的企业也开始大量注重基础研究,中国会胜出么?

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

    新葡亰496net 31

    关注公众号:技术极客TechBooster

    新葡亰496net 32

    本文由新葡亰496net发布于服务器网络,转载请注明出处:新葡亰496netEngine技术架构之Google的整体架构猜想

    关键词: