大型互联网技术架构分析之分布式存储(下)

 

2016-07-04 erixhao 架构师联盟

 

The largest single database on earth - Google Spanner.

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

总目录：

分布式存储概述

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

分布式存储协议 － 两阶段与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系统节点可以分为三种角色：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。

看一下记录追加的流程：

 

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可以自动备份以避免磁盘损坏等问题。

系统架构：

同样，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算法，所以每个桶中的数据基本平衡。

如下图：

 

一致性和可靠性：

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

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

 

3. 分布式表格系统

 

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

 

Google Bigtable:

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

整体结构：

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

 

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

 

系统架构：

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毫秒。

系统架构如下：

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

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

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

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

操作流程：

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

数据复制Replication：

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

 

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

 

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

 

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

重温CAP理论：

 

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

 

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

 

F1系统架构及功能：

 

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

 

Spanner数据模型

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

 

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

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版本，并且获得高额风投。

https://www.infoq.com/news/2014/08/CockroachDB

CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

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

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