---

 

五、分布式存储系统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服务和集群的需求。

（二）Dapper监控系统简介

1、基本概念

  在监控系统中记录下所有这些消息不难，如何将这些消息记录同特定的请求（本例中的X）关联起来才是分布式监控系统设计中需要解决的关键性问题之一。下图是典型分布式系统的请求及应答过程。

Dapper监控系统的三个基本概念：

• 监控树（Trace Tree）：一个同特定事件相关的所有消息
• 区间（Span）：区间实际上就是一条记录
• 注释（Annotation）：注释主要用来辅助推断区间关系，也可以包含一些自定义的内容

区间Helper.Call的详细信息：

  区间包含了来自客户端的注释信息：“<Start>”、“Client Send”、“Client Recv” 和 “<End>”，也包含了来自服务器端的注释信息：“Server Recv”、“foo” 和 “Server Send”。

2、监控信息的汇总

Dapper监控信息的汇总的步骤：

（1）将区间的数据写入到本地的日志文件
（2）所有机器上的本地日志文件汇集
（3）汇集后的数据写入到Bigtable存储库中

（三）关键性技术

1、轻量级核心功能库

• 最关键的代码基础是基本RPC、线程和控制流函数库的实现
• 主要功能是实现区间创建、抽样和在本地磁盘上记录日志。
• 将复杂的功能实现限制在一个轻量级的核心功能库中保证了Dapper的监控过程基本对应用层透明。

2、二次抽样技术

  利用二次抽样技术成功地解决了低开销及广泛可部署性的问题。

第一次抽样： 实践中，设计人员发现当抽样率低至1/1024时也能够产生足够多的有效监控数据，即在1024个请求中抽取1个进行监控也是可行的，从而可以捕获有效数据。

第二次抽样： 发生在数据写入 Bigtable 前，具体方法是将监控 id 散列成一个标量z（0≤z≤1），如果某个区间的z小于事先定义好的汇总抽样系数，则保留这个区间并将它写入 Bigtable，否则丢弃。

（四）常用Dapper工具

1、Dapper存储API

  Dapper的 “存储API” 简称为 DAPI，提供了对分散在区域 Dapper 存储库（DEPOTS）的监控记录的直接访问。一般有以下三种方式访问这些记录。

（1）通过监控id访问（Access by Trace id） ：利用全局唯一的监控id直接访问所需的监控数据

（2）块访问（Bulk Access） ：借助MapReduce对数以十亿计的Dapper监控数据的并行访问

（3）索引访问（Indexed Access） ：Dapper存储库支持单索引（Single Index）

2、Dapper用户界面

（1）选择监控对象

（2）用户对这些执行模式进行排序并选择查看更多细节

（3）分布式执行模式图形化描述呈现给用户

（4）根据最初选择的开销度量标准，Dapper以频度直方图的形式将步骤（3）中选中的执行模式的开销分布展示出来

（5）用户选择了某个监控样例后，就会进入所谓的监控审查视图（Trace Inspection View）

（五）Dapper使用经验

1、新服务部署中Dapper的使用

  利用 Dapper 对系统延迟情况进行一系列的跟踪，进而发现存在的问题。

2、定位长尾延迟（Addressing Long Tail Latency）

  端到端性能和关键路径上的网络延迟有着极大的关系。

3、推断服务间的依存关系（Inferring Service Dependencies）

  Google 的 “服务依存关系” 项目使用监控注释和 DPAI 的 MapReduce 接口实现了服务依存关系确定的自动化。

4、确定不同服务的网络使用情况

  利用 Dapper 平台构建了一个连续不断更新的控制台，用来显示内部集群网络通信中最活跃的应用层终端。

5、分层的共享式存储系统

  没有 Dapper 之类的工具的情况下对于这种共享式服务资源的争用也同样难以调试。

6、利用Dapper进行“火拼”（Firefighting with Dapper）

  Dapper 用户可以通过和 Dapper 守护进程的直接通信，将所需的最新数据汇总在一起。