用于分析Internet技术体系结构的分布式存储（第2部分）

2016-07-04erixhao建筑师联盟

地球上最大的单个-Google Spanner.

上面的大量介绍了一些分布式存储理论，重点是这些理论. 不要低估这些理论. Google的工件是基于这些理论的. 这些理论甚至使整个Apache Big Data 3剑客项目受益. 难怪@Tiger大牛谈论Google依赖大量博. 在世界顶级的数据，物理和计算领域. 这些伟大的神灵和他们的论文是Google之所以成为Google的原因，以及Google因其不是开源而仍然强大的原因. 背后是一支强大的基础研究团队.

常规目录:

分布式存储概述

分布式存储功能-哈希分布/一致哈希分布

分布式存储协议-两阶段和Paxos

分布式文件系统-Google GFS

分布式键值系统-阿里巴巴交易平台

分布式表格系统-Google BigTable / Megastore

分布式系统-MySQL分片，Google Spanner / F1

1. 分布式文件系统

GFS Google文件系统

对于分布式文件系统，GFS当然是第一个. GFS是Google分布式存储的基石. 所有工件都建立在分布式存储上，例如Google BigTable，Google Megastore，Google Percolator，MapReduce等.

GFS

GFS系统节点可以分为三个角色: GFS主站，GFS块服务器，GFS客户端.

GFS文件分为固定大小的（称为块），并且主服务器分配了64位的全局唯一ID. ChunkServer（CS）以普通Linux文件的形式在磁盘上存储块. 对于HA和块复制，默认值为3.

当客户端访问GFS时，它首先访问主服务器以获得CS信息，然后访问CS来完成数据访问. GFS当前主要用于MapReduce，Bigtable.

租赁机制

GFS的附加记录大小范围从数十KB到数十MB. 为了避免Master成为系统瓶颈，GFS引入了一种租赁机制，该机制授权ChunkServer进行Chunk写操作. 具有租用授权的CS称为主ChunkServer. 在租约的有效期内（例如60秒），主CS负责写入块. 租约到期后，主CS还可继续将租约续签给Master，直到块已满.

一致性模型

GFS支持松散一致性模型. 考虑到相对要求和层名称的简化，我们对HBase的了解是，GFS旨在添加附加而不是重写覆盖的体系结构.

看一下添加记录的过程:

1）客户端请求Master定位块的每个副本的CS

2）主服务器返回到客户的主服务器和备份副本所在的CS位置

3）客户端向每个副本发送其他记录，CS会将这些数据缓存在内部LRU结构中

4）当所有副本都确认收到数据后，客户端随后向主副本发起请求控制命令

5）主副本向所有副本提交写请求.

6）备份副本成功完成后，将回答主副本.

7）主副本响应客户端.

其中，它分为控制流和数据流.

容错

1）主站容错能力:

与传统类似，它是通过在操作日志中添加检查点来执行的.

2）CS容错能力:

复制多份副本.

从GFS的体系结构可以看出，GFS是一个具有良好可伸缩性的系统，可以自动处理各种异常. Google的系统从一开始就考虑了如河的横向扩展，因此后续系统可以站在巨头的肩膀上，例如基于GFS构建的Bigtable，Megastore，Spanner和Biggtable合并了关系的功能. 整个方案非常完美.

此外，Google的成功经验反过来证明了一个母版是可行的，从而简化了系统并实现了一致性.

2. 分布式键值系统

分布式键值类似于分布式表模型Bigtable的特殊情况. 比较有名的是Amazon Dynamo，Memcache和国内的Ali Tair系统.

几天前，一个合作伙伴提到了Tair，所以我们来谈谈Tail.

Tair分布式系统

Tair是由Ali /淘宝网开发的分布式密钥/值存储系统. Tair分为两种方式: 持久性和非持久性. 非持久性对可以视为分布式缓存. 持久性对将数据存储在磁盘上. 当然，可以自动备份tair以避免磁盘损坏等问题.

系统架构:

类似地，Tair由一个Master和一系列Slave节点组成，称为Config Server作为整体控制中心，而服务节点是一个可伸缩的Data Server. Config Server负责管理所有数据服务器并维护其状态信息. 数据服务器在外部提供各种数据服务，并通过心跳将其自身的信息提供给配置服务器. 可以看出，Config Server是核心控制点，它是一个单点，只有主备格式才能保证其可靠性.

ConfigServer的功能

1）通过维护和数据服务器心跳获取集群中尚存节点的信息

2）根据幸存节点的信息，构造集群中数据的分布表.

3）提供数据分配表的查询服务.

4）安排数据服务器之间的数据迁移和复制.

此外，ConfigServer实现从配置文件中加载节点信息，然后根据配置的数据分发桶和要建立的数据备份数量，建立数据分发表，其长度为数量存储桶数乘以备份数. 例如，当前有1023个存储桶和3个备份，因此长度是1023 * 3的数组. 数组元素是要存储在数据中的主要节点信息，下标是存储桶编号. 以下1023 * 2是备份节点信息. 为了实现负载均衡，主存储桶应尽可能均匀地分配到所有节点，备用存储桶应根据策略（例如不同的数据中心）进行分配.

DataServer功能

1）提供存储引擎

2）接受客户的put / get / remove和其他操作

3）执行数据迁移，复制等.

4）插件: 在接受请求时处理一些自定义功能

5）访问统计

操作级别:

客户端首先请求配置服务器获取数据所在的数据服务器，然后向数据服务器发送读写请求.

负载均衡:

Tair使用分布式一致哈希算法. 您可以参考我们以前的介绍，这是理论的基石. 对于所有键，将tair分配给Q桶. 存储桶是负载平衡和数据迁移的基本单元. 配置服务器根据已建立的策略将每个存储桶分配给不同的数据服务器. 因为数据是根据密钥进行散列的，所以每个存储桶中的数据基本上是平衡的.

如下所示:

一致性和可靠性:

由于网络错误，不能同时保证分布式系统中的可靠性和一致性. tair使用复制技术来提高可靠性并进行一些优化. 当没有网络错误时，tair提供了很强的一致性. 但是，当数据服务器出现故障时，客户可能无法在特定时间段内读取最新数据. 甚至最新的数据也可能会丢失.

参考:

3. 分布式表格系统

顾名思义，表模型具有多行和多列，并由主键唯一标识. 就像祖先的Google Bigtable

Google Bigtable:

基于GFS和Chubby的分布式表格系统旨在解决阅读速度. 网页索引和卫星图像数据等许多Google数据都存储在bigtabe中.

总体结构:

（行: 字符串，列: 字符串，时间戳: int64）->字符串

RowKey是长度小于64kb的任何字符串. 根据主键对整个数据进行排序，并对字典进行排序. 如果使用域名，通常使用反向转换进行排序，这样可以达到第二级，并且子域名可以是连续的.

系统架构:

Bigtable: 分为客户端，主服务器和平板电脑服务器. Bigtable将大表划分为100-200m的子表平板电脑.

主服务器: 管理所有子表平板电脑服务器，将子表分配给子表服务器分布式存储网络，合并子表，接收子表拆分消息，监视子表服务器，并对子表实施负载平衡和故障恢复.

Tablet Server: 子表服务器，用于实现子表的加载/卸载，以及对表内容的读取，写入，合并和拆分. 它提供的数据包括操作日志和子表sstable数据，这些数据存储在基础GFS中.

胖乎乎的: Google的分布式服务，zk的创建者. 底层的核心算法是我们上面提到的Paxos，也就是说，大多数人都同意，类似于昨天的英国脱欧. 胖乎乎是整个大表的核心. 如果发生故障，则整个bigtabe将不可用. 为了维护HA，Chubby通常在两个位置部署五个副本的三个数据中心.

为什么需要五份？

理论上，已经有3个数据中心可用，为什么选择5个？如果仅部署在3个数据中心中，则一个挂起后不得再挂掉其余两个，因为在Paxos协议中提交已成功完成. 至少需要2个节点. 但是如果第二个节点再次挂起，则此时确实无法访问. 为了实现高可用性，选择了5个数据中心节点.

Chubby在Bigtable中提供/辅助了以下核心功能:

1）选择并确保同时只有一个主服务器

2）保存bigtable系统启动信息

3）与主服务器合作发现子表服务器的加载和卸载

4）获取bigtable模式信息和访问控制信息

Bigtable分为用户表（User Table），元数据表（Meta Table）和根表（Root Table）. 在查询客户群时，首先访问Chubby以读取根表的位置，然后从根表中读取所需的元数据子表的位置.

复制和一致性:

Bigtable使用强一致性. 同时，同一子表只能由平板电脑服务器提供服务. 主机需要控制这种一致性，而Chubby的分布式互斥锁定机制也可以保证这一点.

GFS + Bigtable两层体系结构以优雅的方式考虑了系统的强一致性和高可用性. 底层GFS的一致性较弱，具有良好的可用性和性能，但是多客户端附加可能会导致数据不一致，例如重复记录；上层的Bigtable通过多层分布式索引使系统看起来很稳定. Bigtable的最大优势在于线性扩展. 如果一台计算机发生故障，该服务（在1分钟内）可以自动迁移到整个群集.

Google Megastore:

Megastore在Bigtable的基础上提供了功能支持，这是关系和NoSQL之间的存储. 谷歌在其公开的Megastore论文中指出，谷歌否认了传统的关系，例如MySQL. 昂贵的商业将大大增加用户在云中进行大型部署的总成本.

Megastore设计的原理和本质是它可以在WAN中同步复制文件写入操作，并且具有可接受的延迟，并支持数据中心故障迁移. 该文件还透露，目前，谷歌和超过100个生产应用程序的Megastore作为存储服务，其可靠性为99.99％-100％，并且平均读取延迟小于十分之一毫秒，写入延迟为100-400毫秒.

系统架构如下:

客户端库Megastore库: 为应用程序提供了一个接口，包括将megastore操作映射到bigtable，事务和并发控制，基于Paxos的复制，将请求分发到复制服务器，以及通过协调器快速读写.

复制服务器复制: 接受客户端的用户请求并将其转发到计算机房中的bigtable实例，以解决整个计算机房中的连接过多的问题.

协调器: 存储每个机房的本地实体组是否处于最新状态信息中，以实现快速读写.

Megastore的主要功能分为: 将Megastore映射到Bigtable；交易并发控制；跨机房数据复制和读写优化.

操作流程:

首先分析用户的SQL，然后根据用户定义的Megastore数据模型将sSQL转换为基础的Bigtable.

数据复制:

将数据分为不同的实体组，并且每个实体组中的操作日志都基于Paxos同步到多个计算机机房，以保持强大的一致性. 分布式事务是通过分布式队列或两阶段提交协议在实体组之间实现的.

如上图所示，Megastore的数据复制是通过paxos同步复制的，也就是说分布式存储网络，如果更新了数据，则由于使用了paxos协议，所有机房将被同步更新，因此不同的机房实际上会更新相同的数据. 所有计算机机房的更新顺序是一致的；同步复制可确保数据的实时可见性，而paxos算法的使用可确保所有计算机机房的更新一致性.

Megastore的主要创新:

1）包括实体组的数据模型，在实体组内维护关系的ACID功能，在实体组之间保持NoSQL弱一致性，并创新地融合了SQL和NoSQL的优势. 另外，实体组的定义绕过了性能杀手Join.

2）Paxos协议可同时确保高可靠性和高可用性. 它可以将数据同步到多个计算机机房，并在发生故障的情况下实现自动切换，而不会影响读写服务.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-195115-1.html