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

Posted 2020-07-30 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）中间