Google云计算之Megastore

1.基础概述

• 什么是Megastore？

  Megastore是Google设计的一种分布式存储系统

• 设计目标

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

• 设计方案

  • 针对可用性的要求，实现了一个同步的、容错的、适合远距离传输的复制机 制。在方案的选择和实现过程中Megastore团队研究和比较了一些传统的远距离复制技 术，最终确定了引入Paxos算法并对其做出一定的改进以满足远距离同步复制的要求。
  • 针对可扩展性的要求，设计团队借鉴了数据库中数据分区的思想，将整个大的数据分割成很多小的数据分区，每个数据分区连同它自身的日志存放在NoSQL数据库 中，具体来说就是存放在Bigtable中。

2.数据分区复制

• 在Megastore中，这些小的数据分区被称为实体组集（Entity Groups）
• 每个实体组集包含若干的实体组（Entity Group，相当于分区中表的概念）
• 每个实体组中又包含很多的实体（Entity，相当于表中记录的概念）
• 实体组集之间只具有比较松散的一致性。每个实体组都通过复制技术在数据中心中保存若干数据副本，这些实体组及其副本都存储在NoSQL数据库（Bigtable）中

3.数据模型

• 关系数据模型不合适

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

• 数据模型示例

  

  • 在Megastore中，所有的表要么是实体组根表（Entity Group Root Table），要么是子表（Child Table）
  • 所有的子表必须有一个参照根表的外键，这个外键是通过ENTITY GROUP KEY来声明的
  • 一个Megastore实例中可以有若干个不同的根表，表示不同类型的实体组集

• 数据存储

  

  • Megastore中的实体组都存储在Bigtable中
  • Bigtable的列名实际上是表名和属性名结合在一起得到的。不同表中的实体可以存储在同一个Bigtable行中

4.事务及并发控制

每个实体组实际上就像一个小的数据库，在实体组内部提供了完整的序列化ACID语义支持。

• Megastore读

  • 对于current读，在开始某次current读之前，需要确保所有已提交的写操作已经全部生效，然后应用程序再从最后一个成功提交的事务时间戳位置读取数据。
  • 对于snapshot读，系统取出已知的最后一个完整提交的事务的时间戳，接着从这个位置读数据。和current读不同的是，snapshot读的时候可能还有部分事务提交了但未生效。
  • 对于inconsistent读，它忽略日志的状态直接读取最新的值。这对于那些要求低延迟并能容忍数据过期或不完整的读操作是非常有用的。

• Megastore写

  Megastore事务中的写操作采用了预写式日志（Write-ahead Log），也就是说只有当所有的操作都在日志中记录下后写操作才会对数据执行修改。

• 事务周期

  • 读：获取最后一次提交的事务的时间戳和日志位置。
  • 应用逻辑：从Bigtable读取并且聚集数据到日志入口。
  • 提交：使用Paxos达到一致，将这个入口追加到日志。
  • 生效：将数据更新到Bigtable中的实体和索引。
  • 清除：清理不再需要的数据。

• 事务机制

  

  • Megastore中事务间的消息传递是通过队列（Queue）实现的， 除了队列机制之外，Megastore还支持两阶段提交（Two-phase Commit）。但是这会产生比较高的延迟并且增加了竞争的风险，一般情况下不鼓励使用
  • Megastore中的消息能够横跨实体组，在一个事务中分批执行多个更新或者延缓作业 （Defer Work）
  • 在单个实体组上执行的事务除了更新它自己的实体外，还能够发送或收到多个信息
  • 每个消息都有一个发送和接收的实体组；如果这两个实体组是不同的，那么传输将会是异步的

5.基本架构

• 最底层的数据是存储在Bigtable中的，不同类型的副本存储不同的数据。

• 在Megastore中共有三种副本

  • 对于完整副本，Bigtable中存储完整 的日志和数据。
  • 对于见证者副本副本，Bigtable只存储其日志而不存储具体数据。
  • 对于只读副本，它们无法参与投票，它们的作用只是读取到最近过去某一个时间点的一致性数据。

• 快速读机制

  如果读操作不需要副本之间进行通信即可完成，那么读取的效率必然相对较高。由于 写操作基本上能在所有的副本上成功，一旦成功认为该副本上的数据都是相同的且是最新 的，就能利用本地读取（Local Reads）实现快速读，能够带来更好的用户体验及更低的延 迟。确保快速读成功的关键是保证选择的副本上数据是最新的。

• 快速写机制

  为了达到快速的单次交互的写操作，Megastore采用了一种在主/从式系统中常用的优 化方法。如果一次写成功，那么下一次写的时候就跳过准备过程，直接进入接受阶段。因 为一次成功的写意味着也准确地获知了下一个日志的位置，所以不再需要准备阶段。

6.核心技术

复制可以说是Megastore最核心的技术，如何实现一个高效、实时的复制方案对于整个系统的性能起着决定性的作用。通过复制保证所有最新的数据都保存有一定数量副本， 能够很好地提高系统的可用性。

• 复制的日志

  每个副本都存有记录所有更新的数据。即使是它正从一个之前的故障中恢复数据，副本也要保证其能够参与到写操作中的Paxos算法，因此Megastore允许副本不按顺序接受日志，这些日志将独立的存储在Bigtable中。

  

• 数据读取

  

  • 本地查询（Query Local）

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

  • 发现位置（Find Position）

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

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

  • 追赶

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

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

  • 验证（Validate）

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

  • 查询数据（Query Data）

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

• 数据写入

  

  • 接受leader：请求leader接受值作为0号提议。这实际上就是前面介绍的快速写方 法。如果成功，跳至步骤（3）。
  • 准备：在所有的副本上使用一个比其当前所见的日志位置更高的提议号进行 Paxos准备阶段。将值替换成拥有最高提议号的那个值。
  • 接受：请求剩余的副本接受该值，如果大多数副本拒绝这个值，返回步骤 （2）。
  • 失效：将不接受值的副本上的协调者进行失效操作。
  • 生效：将值的更新在尽可能多的副本上生效。如果选择的值和原来提议的有冲 突，返回一个冲突错误。

• 协调者的可用性

  Megastore使用了Chubby锁服务，协调者在启动的时候从数据中心获取指定的Chubby 锁。为了处理请求，一个协调者必须持有其多数锁。一旦因为出现问题导致它丢失了大部分锁，协调者就会恢复到一个默认保守状态——认为所有它所能看见的实体组都是失效的。

  • 协调者比任何的Bigtable 服务器都简单，基本上没有依赖，所以可用性更高。
  • 协调者简单、均匀的工作负载让它们能够低成本地进行预防措施。
  • 协调者轻量的网络传输允许使用高可用连接进行服务质量监控。
  • 操作者能够在维护期或者故障期集中地让一批协调者失效。当出现某些系统默认的监控信号时这一过程会自动进行。
  • Chubby 锁的quorum机制能够监测到大多数网络问题和节点的不可用

7.性能防控措施

当某个完整副本忽然变得不可用或失去连接时，为了避免Megastore的性能下降，可采取以下三种应对方法。

• 通过重新选择路由使客户端绕开出现问题的副本，这是最重要的一种错误处理 机制。
• 将出现问题副本上的协调者禁用，确保问题的影响降至最小。
• 禁用整个副本，这是最严厉的一种手段，但是这种方法比较少使用。