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

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容错：