Google云计算原理与应用（三）

- 五、分布式存储系统Megastore
- - （一）设计目标及方案选择
  - （二）Megastore数据模型
  - （三）Megastore中的事务及并发控制
  - （四）Megastore基本架构
  - （五）核心技术——复制
  - （六）产品性能及控制措施
- 六、大规模分布式系统的监控基础架构Dapper
- - （一）基本设计目标
  - （二）Dapper监控系统简介
  - （三）关键性技术
  - （四）常用Dapper工具
  - （五）Dapper使用经验

五、分布式存储系统Megastore

互联网的迅速发展带来了新的数据应用场景，和传统的数据存储有别的是，互联网上的应用对于数据的可用性和系统的扩展性具有很高的要求。一般的互联网应用都要求能够做到7天×24小时的不间断服务，达不到的话则会带来较差的用户体验。热门的应用往往会在短时间内经历急剧的用户数量增长，这就要求系统具有良好的可扩展性。在互联网的应用中，为了达到好的可扩展性，常常会采用 NosQL 存储方式。但是从应用程序的构建方面来看，传统的关系型数据库又有着 NoSQL 所不具备的优势。Google 设计和构建了用于互联网中交互式服务的分布式存储系统 Megastore，该系统成功的将关系型数据库和 NoSOL 的特点与优势进行了融合。将向大家介绍该系统，着重突出 Megastore 设计与构建过程中的核心思想和技术。

（一）设计目标及方案选择

设计目标： 设计一种介于传统的关系型数据库和NoSQL之间的存储技术，尽可能达到高可用性和高可扩展性的统一。

两种方法：

针对可用性的要求，实现了一个同步的、容错的、适合远距离传输的复制机制。
针对可扩展性的要求，将整个大的数据分割成很多小的数据分区，每个数据分区连同它自身的日志存放在 NoSQL 数据库中，具体来说就是存放在 Bigtable 中。

数据的分区和复制：

在Megastore中，这些小的数据分区被称为实体组集（Entity Groups）。每个实体组集包含若干的实体组（Entity Group，相当于分区中表的概念）。一个实体组中包含很多的实体（Entity，相当于表中记录的概念）。

在这里插入图片描述

（二）Megastore数据模型

传统的关系型数据库不合适的三个原因：

传统的关系型数据库是通过连接（Join）来满足用户的需求的，但是就 Megastore 而言，这种数据模型是不合适的，主要有以下三个原因：

（1）对于高负载的交互式应用来说，可预期的性能提升要比使用一种代价高昂的查询语言所带来的好处多。
（2）Megastore 所面对的应用是读远多于写，因此好的选择是将读操作所需要做的工作尽可能地转移到写操作上。
（3）在 Bigtable 这样的键/值存储系统中存储和查询级联数据（Hierarchical Data）是很方便的。

Megastore数据模型怎么设计？

1、细粒度控制的数据模型和模式语言

在这里插入图片描述

同关系型数据库一样，Megastore的数据模型是在模式（schema）中定义的且是强类型的（strongly typed）
每个模式都由一系列的表（tables）构成，表又包含有一系列的实体（entities），每实体中包含一系列属性（properties）
属性是命名的且具有类型，这些类型包括字符型（strings）、数字类型（numbers）或者 Google 的 Protocol Buffers。

2、照片共享服务数据模型实例

在这里插入图片描述

表Photo就是一个子表，因为它声明了一个外键
User则是一个根表
一个Megastore实例中可以有若干个不同的根表，表示不同类型的实体组集
三种不同属性设置，既有必须的（如user_id），也有可选的（如thumbnail_url）
Photo中的可重复类型的tag属性

3、Megastore索引

在这里插入图片描述
4、Bigtable中存储情况

行键（Row Key）	User.name	Photo.time	Photo.tag	Photo._url
101	John
101,500		12:30:01	Dinner, Paris	…
101,502		12:15:22	Betty, Paris	…
102	Mary

（三）Megastore中的事务及并发控制

Megastore 提供的三种读：

current：总是在单个实体组中完成。
snapshot：总是在单个实体组中完成。系统取出已知的最后一个完整提交的事务的时间戳，接着从这个位置读数据。
inconsistent：忽略日志的状态直接读取最新的值。

完整的事务周期：

在这里插入图片描述
Megastore中的事务机制：

在这里插入图片描述

（四）Megastore基本架构

Megastore 基本架构如下。在Megastore中共有三种副本：完整副本（Full Replica），见证者副本（Witness Replica），只读副本（Read-only Replica）。

在这里插入图片描述
1、快速读

利用本地读取实现快速读，带来更好的用户体验及更低的延迟。关键是保证选择的副本上数据是最新的。协调者是一个服务，该服务分布在每个副本的数据中心里面。它的主要作用就是跟踪一个实体组集合。协调者的状态是由写算法来保证。

2、快速写

如果一次写成功，那么下一次写的时候就跳过准备过程，直接进入接受阶段。Megastore 没有使用专门的主服务器，而是使用 leaders。leader 主要是来裁决哪个写入的值可以获取0号提议。客户端、网络及 Bigtable 的故障都会导致一个写操作处于不确定的状态。

（五）核心技术——复制

1、复制的日志

每个副本都存有记录所有更新的数据。Megastore 允许副本不按顺序接受日志，这些日志将独立的存储在 Bigtable 中。

在这里插入图片描述
2、数据读取

在这里插入图片描述
（1）本地查询（Query Local）

查询本地副本的协调者来决定这个实体组上数据是否已经是最新的。

（2）发现位置（Find Position）

确定一个最高的已经提交的日志位置，选择一个己经在该位置上生效的副本。

本地读取（Local Read）：如果本地查询确定当前的本地副本已经是最新的，则从副本中的最高日志位置和时间戳读取数据。这实际上就是前面提到的快速读。
多数派读取（Majority Read）：如果本地副本不是最新的（或者本地查询或本地读取超时），从一个副本的多数派中发现最大的日志位置，然后从中选取一个读取。选择一个响应最快或者最新的副本，并不一定就是本地副本。

（3）追赶

一旦某个副本被选中，就采取如下方式使其追赶到已知的最大日志位置处。

对于所选副本中所有不知道共识值（Consensus Value）的日志位置、从其他的副本中读取值。对于任意的没有任何可用的已提交的值的日志位置，将会利用 Paxos 算法发起一次无操作的写。Paxos 将会促使绝大多数副本达成一个共识值——可能是无操作的写也可能是以前的一次写操作。
接下来就所有未生效的日志位置生效成上面达成的共识值，以此来达到一种分布式一致状态。

（4）验证（Validate）

如果本地副本被选中且数据不是最新，发送一个验证消息到协调者断定（entity group, replica）对（(entity group, replica) pair）能够反馈所有提交的写操作。无须等待回应，如果请求失败，下一个读操作会重试。

（5）查询数据（Query Data）

在所选的副本中利用日志位置的时间戳读取数据。如果所选的副本不可用了，重新选中一个替代副本，执行追赶操作，然后从中读取数据。单个的较大查询结果可能是从多个副本中汇聚而来。

需要指出的是，本地查询和本地读取是并行执行的。

3、数据写入

在这里插入图片描述
（1）接受leader：请求 leader 接受值作为0号提议。这实际上就是前面介绍的快速写方法。如果成功，跳至步骤（3）。

（2）准备：在所有的副本上使用一个比其当前所见的日志位置更高的提议号进行 Paxos 准备阶段。将值替换成拥有最高提议号的那个值。

（3）接受：请求剩余的副本接受该值，如果大多数副本拒绝这个值，返回步骤（2）。

（4）失效：将不接受值的副本上的协调者进行失效操作。

（5）生效：将值的更新在尽可能多的副本上生效。如果选择的值和原来提议的有冲突，返回一个冲突错误。

4、协调者的可用性

协调者在系统中是比较重要的——协调者的进程运行在每个数据中心。每次的写操作中都要涉及协调者，因此协调者的故障将会导致系统的不可用。Megastore 使用了 Chubby 锁服务，为了处理请求，一个协调者必须持有多数锁。一旦因为出现问题导致它丢失了大部分锁，协调者就会恢复到一个默认保守状态。除了可用性问题，对于协调者的读写协议必须满足一系列的竞争条件。

（六）产品性能及控制措施

可用性的分布情况：

Megastore 在 Google 中已经部署和使用了若干年，有超过100个产品使用 Megastore 作为其存储系统。从图中可以看出，绝大多数产品具有极高的可用性（>99.999%）。这表明 Megastore 系统的设计是非常成功的，基本达到了预期目标。

在这里插入图片描述
产品延迟情况的分布：

应用程序的平均读取延迟在万分之一毫秒之内，平均写入延迟在100至400毫秒之间。避免Megastore的性能下降，可采取以下三种应对方法：

（1）重新选择路由使客户端绕开出现问题的副本。
（2）将出现问题副本上的协调者禁用，确保问题的影响降至最小。
（3）禁用整个副本。

在这里插入图片描述

六、大规模分布式系统的监控基础架构Dapper

Google 认为系统出现故障是一种常态，基于这种设计理念，Google 的工程师们结合 Google 的实际开发出了 Dapper。这是目前所知的第一种公开其实现的大规模分布式系统的监控基础架构。

（一）基本设计目标

在这里插入图片描述
两个基本要求：

监控系统设计两个基本要求。

（1）广泛可部署性（Ubiquitous Deployment）：设计出的监控系统应当能够对尽可能多的 Google 服务进行监控。
（2）不间断的监控：Google 的服务是全天候的，如果不能对 Google 的后台同样进行全天候的监控很可能会错过某些无法再现的关键性故障。

三个基本设计目标：

低开销：这个是广泛可部署性的必然要求。监控系统的开销越低，对于原系统的影响就越小，系统的开发人员也就越愿意接受这个监控系统。
对应用层透明：监控系统对程序员应当是不可见的。如果监控系统的使用需要程序开发人员对其底层的一些细节进行调整才能正常工作的话，这个监控系统肯定不是一个完善的监控系统。
可扩展性：Google的服务增长速度是惊人的，设计出的系统至少在未来几年里要能够满足Google服务和集群的需求。