大型互联网技术架构4－分布式存储-II Google

The largest single database on earth - Google Spanner.

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

上文大篇幅介绍了1些散布式存储的理论，偏重理论。可别小视这些理论，Google的各个神器都是建立在这些理论之上，乃至全部Apache的大数据3剑客项目都是沾恩于这些理论。难怪@Tiger大牛讲Google靠的是1大批世界顶尖数据，物理，计算领域的Ph.D.，这些大神和他们的Paper是Google为何是Google的缘由，和Google没有开源为何仍然强大的缘由，其背后有着强大的基础研究团队。

总目录

散布式存储概述

散布式存储特性 － 哈希散布/1致性哈希散布

散布式存储协议 － 两阶段与Paxos

散布式文件系统 － Google GFS

散布式键值系统－ Alibaba Tair

散布式表格系统－ Google BigTable /Megastore

散布式数据库系统－MySQL Sharding, Google Spanner / F1

1. 散布式文件系统

GFS Google文件系统

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

GFS

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

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

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

租约机制(Lease)

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

1致性模型

GFS支持1个宽松的1致性模型，GFS从相对需求和简单化层名斟酌，设计成主要是为了追加append而不是为了改写override的架构，如我们了解的

HBase。

看1下记录追加的流程：

1）客户端向Master要求chunk每一个副本所在CS

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

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

4）当所有副本都确认收到数据，客户端接着发起1个要求控制命令给主副本

5）主副本把写要求提交给所有副本。

6）备副本成功完成后应对主副本。

7）主副本响应客户端。

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

容错

1）Master容错：

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

2）CS容错：

采取复制多个副本方式。

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

Biigtable之上融会了关系型数据库的功能，全部方案华丽，完善。

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

2. 散布式键值系统

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

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

Tair散布式系统

Tair是阿里/淘宝开发的1个散布式键/值存储系统，tair分为持久化和非持久化两种方式。非持久化的tair可以看做1个散布式缓存，持久化的tair将数据寄存置磁盘，固然tair可以自动备份以免磁盘破坏等问题。

系统架构：

一样，Tair由1个Master和1系列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) 插件：在接受要求的时候处理1些自定义功能

5) 访问统计

操作层面：

客户端首先要求Config Server获得数据所在Data Server， 以后向Data Server发送读写要求。

负载均衡：

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

以下图：

1致性和可靠性：

散布式系统中的可靠性和1致性是没法同时保证的,由于有网络毛病. tair采取复制技术来提高可靠性,并做了1些优化,当无网络毛病的时候, tair提供的是1种强1致性.但是在有data server产生故障的时候,客户有可能在1定时间窗口内读不到最新的数据.乃至产生最新数据丢失的情况.

参考：http://tair.taobao.org/

3. 散布式表格系统

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

Google Bigtable:

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

整体结构：

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

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

系统架构：

Bigtable

整体分为客户端，主控服务器和子表服务器Tablet Server。 Bigtable把大表分割为100⑵00m的子表tablet。

Master:

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

Tablet Server:

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

Chubby:

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

为何需要5个副本？

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

Chubby在Bigtable中提供了／辅助了以下核心功能：

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

2）保存bigtable系统引导信息

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

4）获得bigtable的schema信息和访问控制信息

Bigtable

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

复制与1致性：

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

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

Google Megastore:

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

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

系统架构以下：

客户端库Megastore Library:

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

复制服务器Replication:

接受客户真个用户要求并转发到所在机房的bigtable实例解决跨机房连接数过量的问题。

调和者Coord.

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

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

操作流程：

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

数据复制Replication：

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

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

Megastore主要创新：

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

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

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

4. 散布式数据库

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

MySQL Sharding

通常水平扩大的做法是利用层依照规则将数据查分到多个分片，散布到多个数据库节点，并引入1个中间层利用来屏蔽后段的拆分细节。

一样，在MySQL Sharding中也是类似：

如上图，整体分为：利用端，中间层dbproxy集群，数据库组，元数据服务器等。

1）利用端／客户端：通过MySQL与客户端交互，支持JDBC，使得原有单机数据库无缝对接。

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

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

4）元数据服务器：保护dbgroup拆分规则并用于dbgroup选主。dbproxy通过元数据服务器拆分规则肯定SQL的履行计划。另外采取zk来实现多个副本HA。

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠