⑴ 什么是分布式存储系统
分布式存储系统
定义
分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务
特性
可扩展
低成本
高性能
易用
挑战
分布式存储系统的挑战主要在于数据、状态信息的持久化，要求在自动迁移、自动容错、并发读写的过程中保证数据的一致性。分布式存储涉及的技术主要来自两个领域：分布式系统以及数据库。
数据分布
一致性
容错
负载均衡
事务与并发控制
易用性
压缩/解压缩
分类
非结构化数据，一般的文档
结构化数据， 存储在关系数据库中
半结构化数据，HTML文档
不同的分布式存储系统适合处理不同类型的数据：
分布式文件系统
非结构化数据，这类数据以对象的形式组织，不同对象之间没有关联，这样的数据一般称为Blob（二进制大对象）数据
典型的有Facebook Haystack 以及 Taobao File System
另外，分布式文件系统也常作为分布式表格系统以及分布式数据库的底层存储，如谷歌的GFS可以作为分布式表格系统Google Bigtable 的底层存储，Amazon的EBS（弹性存储块）系统可以作为分布式数据库（Amazon RDS）的底层存储
总体上看，分布式文件系统存储三种类型的数据：Blob对象、定长块以及大文件
分布式键值系统
较简单的半结构化数据，只提供主键的CRUD（创建、读取、更新、删除）
典型的有Amazon Dynamo 以及 Taobao Tair
分布式表格系统
较复杂的半结构化数据，不仅支持CRUD，而且支持扫描某个主键范围
以表格为单位组织数据，每个表格包括很多行，通过主键标识一行，支持根据主键的CRUD功能以及范围查找功能
典型的有Google Bigtable 以及 Megastore，Microsoft Azure Table Storage，Amazon DynamoDB等
分布式数据库
存储结构化数据，一般是由单机关系数据库扩展而来
典型的包括MySQL数据库分片集群、Amazon RDS以及Microsoft SQL Azure
⑵ 在大数量级的数据存储上，比较靠谱的分布式文件存储有哪些
一、 Ceph
Ceph最早起源于Sage就读博士期间的工作、成果于2004年发表，并随后贡献给开源社区。经过多年的发展之后，已得到众多云计算和存储厂商的支持，成为应用最广泛的开源分布式存储平台。
二、 GFS
GFS是google的分布式文件存储系统，是专为存储海量搜索数据而设计的，2003年提出，是闭源的分布式文件系统。适用于大量的顺序读取和顺序追加，如大文件的读写。注重大文件的持续稳定带宽，而不是单次读写的延迟。
三、 HDFS
HDFS(Hadoop Distributed File System)，是一个适合运行在通用硬件(commodity hardware)上的分布式文件系统，是Hadoop的核心子项目，是基于流数据模式访问和处理超大文件的需求而开发的。该系统仿效了谷歌文件系统(GFS)，是GFS的一个简化和开源版本。
⑶ GFS 小结
title: GFS 小结
tags:
categories:
comments: true
date: 2017-06-12 17:00:00
提到分布式系统，有一个无法绕开的话题—— Google 三驾马车。本文就 GFS 概括介绍。
与传统的分布式系统相比，在大方向上，GFS 同样追求高性能、高可靠性、高可用性，同时 Google 基于自身的生产环境、技术环境，有一些特殊的设计思路。
GFS 架构比较简单，一个 GFS 集群一般由一个 master 、多个 chunkserver 和多个 clients 组成，在 GFS 中，所有文件被切分成若干个 chunk，并且每个 chunk 拥有唯一不变的标识（在 chunk 创建时，由 master 负责分配），所有 chunk 都实际存储在 chunkserver 的磁盘上。为了容灾，每个 chunk 都会被复制到多个 chunkserver。
系统架构如下：
在整个集群中，为了简化设计，master 是单节点，它管理着所有文件系统的所有 metadata：命名空间、访问控制信息、文件和 chunk 的映射关系、chunk 的存储位置。同时 master 还管理系统范围内的各种活动：chunk 创建、复制、迁移、回收，chunk lease 等等，是系统中最核心的部分，后面会继续进一步描述 master 是如何工作的。
Chunkserver 真正存储着所有 chunk，chunkserver 依托于 linux 文件系统，所以它本身不需要缓存文件数据，直接利用 linux 系统的数据缓存，简化了设计。
Master 是整个 GFS 的核心，这里重点介绍下 master 的存储以及工作。
所有的元数据都存储在 Master 的内存中，以保证 Master 的性能。大部分元数据同时会以变更记录的形式保存到操作日志中，操作日志会在本地磁盘中持久化同时被复制到其他的 Master 上（虽然是 single master，但是会有备份节点备份 Master 的相关数据，比如操作日志、checkpoint 文件，以保证可靠性）。
Master 会在后台周期性的扫描所保存的状态信息，因为全部在内存中，所以效率非常高。通过这种周期性的扫描，master 实现 chunk 回收、chunkserver 宕机时 chunk 的复制、以及迁移 chunk ，实现 chunkserver 的负载均衡。
但是， chunk 的位置信息不会被持久化，而是在每次 master 启动时（以及启动后定期执行），或有 chunkserver 加入时，master 会轮训所有 chunkserver 获取所有的 chunk 信息然后保存在内存中。这种方式简化了 master 和 chunkserver 的数据同步，当然数据定期轮训的缺点就是实时性稍差。
操作日式是元数据唯一的持久化记录，它还定义了并发操作的执行顺序的逻辑时间线，所以操作日志的完整性得到保证，才能保证 GFS 的可靠性，否则会丢失文件或者 client 的操作。因此操作日志会被复制到多台备份节点，而且，只有 master 把操作日志持久化到本地并且复制到远程之后，才会响应客户端的请求，保证数据不丢失。
随着时间的增长，操作日志会越来越大，当日止增长到一定量时，master 会将所有的系统状态做一次 checkpoint（可以理解为持久化某一个时间点的全部状态数据），后续的操作变更会写入到新的日志文件，这样在重启或灾难恢复时，master 只需要加载最新的 checkpoint 文件到内存，然后重新执行最新的一部分操作日志即可。（这也是比较通用的一种灾备方法，定期做 checkpoint，然后重新记录操作日志，恢复时基于 checkpoint + operation log）
Checkpoint 文件以压缩 B- 树的结构存储，能直接映射到内存，无需额外解析，大幅提升了速度。同时创建 checkpoint 时，master 会启动独立的线程，不会阻塞正在进行的操作。
Master 节点执行所有的命名空间管理、chunk管理以及负责垃圾回收。
Master 在操作命名空间是基于锁实现的，在操作对应的文件或目录时，会给对应的文件/目录加读锁以及读写锁，eg：对于一个 /home/usr/zhaif 的操作，会依次给父目录 /home，/home/usr 加读锁，读锁可以防止正在读取得文件、父目录被删除、改名，同时给 /home/usr/zhaif 加读锁或写锁（根据操作类型），当对操作目标的操作是修改类操作时，会加写锁，保证并发场景下互斥写。
上文提到，master 会负责 chunk 副本的存储位置，即存储在哪些 chunkserver 上，master 会最大化的保证数据可靠性，同时最大化利用网络带宽。
在创建一个 chunk 时，master 选择存储空副本的初始位置时，会考虑一下几点：
除了管理 chunk 副本的存储位置，master 会在 chunk 有效副本数小于指定数量时重新复制 chunk 副本，以保证数据可靠性。
最后，Master 会定期对所有副本负载均衡，检查当前副本分布情况，然后移动副本位置以更搞笑的利用硬盘空间和负载。
GFS 的文件删除不会立刻回收物理空间，而是惰性的（现如今，惰性回收在存储系统中是一种比较常见的策略，比如 redis 回收过期数据，分配的内存空间）。这种回收机制使系统更简单、更可靠、更高效。
当一个文件被删除时，master 只是将文件改名，标记为已删除。Master 会对命名空间做定期扫描，会删除一定时间前标记删除的文件，同时删除其在命名空间中的记录以及相关元数据，此时一个文件才被真正的删除。
Master 在常规定期扫描的过程中会发现一些孤儿 chunk，即不被任何文件包含的 chunk，然后删除他们的元数据。Chunkserver 在和 master 定期交互时，汇报了其所有的 chunk 信息，master 会告知其不存在的 chunk，chunkserver 得知后会删除这些 chunk 副本。
这种惰性删除的主要问题是空间利用率，尤其的在存储空间紧缺时。所以 GFS 也提供了通过显示的再删除一次已经删除的文件来加速空间回收，另外也允许用户根据需要对不同的目录设置不同的回收策略，eg：指定用些目录的删除策略为即时删除，而不是惰性删除。
Master 的写操作是基于 lease 机制（后文介绍），当 master 每次分配 lease 时都会增加对应的 chunk 的版本号，然后所用最新的副本，通过版本号区分当前的和过期的副本。
GFS 在设计是采用 client 和 API 协同设计的思路，所以在读写过程中 client 也不单纯是发读请求或写请求，还包括其他一些操作。
Client 不通过 master 节点读写文件，而是从 master 那获取读写操作的需要联系的 chunkserver，为了避免频率的和 master 联系，client 会缓存 从 master 获取的 metadata，后续操作直接和 chunkserver 沟通实现读写。一次简单的读流程如下：
相较于读操作，写实现更为复杂一些。所有的写入操作会在所有 chunk 的副本上执行，GFS 采用 lease 机制来保证多个 chunk 副本之间变更顺序一致。
Master 会选择一个副本分配 lease，拥有这个 lease 的 chunk 被称为 primary，其他副本则是 secondary。Primary 会将对 chunk 的操作序列化，然后其他 secondary 按也这个序列执行修改，从而保证所有副本变更一致。
Lease 有效期初始为 60s，primary chunk 在完成修改操作后可以申请延长 lease 有效期，同样的 master 在一些情况下可以提起取消 lease。Master 和 chunkserver 之间会有定期的心跳监测，传递心跳信息是可以带上这些 lease 的验证请求或者批准信息。Lease 机制极大的简化的 master 的负担，将写操作保证数据一致性的工作分担给 chunkserver，使得 master 变得很轻量。
下图是一次写操作的流程：
GFS 将写操作拆分为数据流（对应3）和控制流（对应4），数据流以 Pipline 的方式推送到所有副本。
GFS 同时提供了一个种原子的写入操作——记录追加。相比普通的写入操作，追加只需指定要写入的数据，不需要提供偏移量（即要写入的位置）。GFS 会保证追加操作至少一次原子性写入。记录追加的控制流程同上文描述基本相同，却别在于 primary 会检测此次追加后 chunk 是否超过最大值，如果达到最大值，primary 会先将当前 chunk 填充满，然后同步给 secondary 同样操作，然后回复 client 要求其对下一个 chunk 重新执行追加操作。
原子记录追加操作在避免了使用一个分布式锁带来的开销，对于多 procer，单 consumer的场景以及合并多个来源文件的场景很契合。
GFS 是一个分布式系统，为了更好的 AP，一定程度上降低了对 C 的要求，其一致性模型是比较宽松。下图是变更后文件状态，其中：
从上文的写入数据流程可以发现，串行的写数据secondary 和 primary 操作顺序是一直的，如果成功，则一定是 defined，如果失败，则不一致，比如 primary 写成功了，而有一个 secondary 写失败。同样的道理，在并行场景下，写失败会不一致，但是成功的话只能保证一致，因为并发操作可能会导致一个文件 region 内包含来自多个 client 的写操作，所以是 undefined.
记录追加操作是原子的，GFS对于此操作能保证的是 至少一次成功 语义，所以有可能会在某个副本上发生多次追加，但是 GFS 返回给 client 的 offset 都是 defined region 的起点，如果这期间在某个副本的操作被重复追加了，此时它的 offset 会比其他大，后续的操作对所有副本都会从这个最大的 offset 开始追加，或者被追加到其他 chunk 上，因此对于记录追加操作而言，如果执行成功，文件 region 状态是定义的但会有部分不一致。
GFS 通过 Checksum 叫校验数据是否损坏，比如因为宕机丢失了一些修改操作而导致失效，此时 master 会标记失效，不在返回给 client 失效的副本位置信息，并尽快回收。 对于已经被 client 缓存的失效副本信息，当 client 访问这个失效副本时，一个失效副本会返回提前结束的 chunk，从而 client 能得知重新联系 master 获取最新的位置信息。
另外，正如上文所述， master 也会和 chunkserver 通过心跳来检测宕机，并校验数据有效性，在发现问题后会尽快恢复。
GFS 通过快速恢复和复制保证整个集群的高可用性，无论 master 还是 chunkserver 都可以在数秒内重启并恢复状态。
Chunk 会被复制到不同的机架上的不同 chunkserver，当某台 chunkserver 失效或者其上的 chunk 已损坏时，master 会继续复制已有的副本，保证每个 chunk 的可用性。
Master 服务器的状态会被复制，它所有的操作日志、checkpoint 文件都会被复制到多台机器，对 master 服务器的状态的任何操作都要等操作日志被复制到备份节点后本机磁盘后才会被提交生效。所以 Master 宕机后，重启后不会有任何数据丢失，如果无法重启或磁盘故障，则可以选择拥有全部操作日志的备份节点启动一个新的 master 进程。由此可以保证 master 的可靠性。
同时，还存在一些 shadow master ，在 master 宕机时能可以提供 read-only 服务，但要比 master 慢一些（通常不到 1s），它们通过读取操作日志副本的并顺序执行方式保证其和 master 以相同的方式变更。同样的，shadow master 也会和 chunkserver 定期交互检测 chunkserver状态、拉取数据。
⑷ 分布式储存_gluster
9)查看卷
gluster volume info
gluster volume stop 卷名 停止
gluster volume delete 卷名 删除注： 删除 磁盘 以后，必须删除 磁盘( 数据目录 ) 中的 （ .glusterfs/ .trashcan/ ）目录。 否则创建新 volume 相同的 磁盘 会出现文件 不分布，或者 类型 错乱 的问题。
gluster peer detach 节点名 删除节点
。
添加GlusterFS节点：
gluster peer probe swarm-node-3
gluster volume add-brick models swarm-node-3:/opt/gluster/data
注：如果是复制卷或者条带卷，则每次添加的Brick数必须是replica或者stripe的整数倍
配置卷
gluster volume set
缩容volume:
先将数据迁移到其它可用的Brick，迁移结束后才将该Brick移除：
gluster volume remove-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data start
在执行了start之后，可以使用status命令查看移除进度：
gluster volume remove-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data status
不进行数据迁移，直接删除该Brick：
gluster volume remove-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data commit
注意，如果是复制卷或者条带卷，则每次移除的Brick数必须是replica或者stripe的整数倍。
扩容：
gluster volume add-brick models swarm-node-2:/opt/gluster/data
修复命令:
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data commit -force
迁移volume:
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data start
pause 为暂停迁移
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data pause
abort 为终止迁移
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data abort
status 查看迁移状态
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data status
迁移结束后使用commit 来生效
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data commit
均衡volume:
gluster volume models lay-outstart
gluster volume models start
gluster volume models startforce
gluster volume models status
gluster volume models stop
gluster 性能调优：
开启 指定 volume 的配额： (models 为 volume 名称)
gluster volume quota models enable
限制 models 中 / (既总目录) 最大使用 80GB 空间
gluster volume quota models limit-usage / 80GB
gluster volume set models performance.cache-size 4GB
gluster volume set models performance.flush-behind on
gluster volume set models performance.io-thread-count 32
gluster volume set models performance.write-behind on
部署GlusterFS客户端并mount GlusterFS文件系统 (客户端必须加入 glusterfs hosts 否则报错。)
yum install -y glusterfs glusterfs-fuse
mkdir -p /opt/gfsmnt
mount -t glusterfs swarm-manager:models /opt/gfsmnt/
确认挂载结果：
mount -t fuse.glusterfs
查看卷
gluster volume list / 列出集群中的所有卷 /
gluster volume info [all] / 查看集群中的卷信息 /
gluster volume status [all] / 查看集群中的卷状态 /
更改卷类型
1.需要先卸载挂载的目录
umount ／mnt
2.停止卷
3.更改卷的类型
语法：gluster volume set test-volume config.transport tcp,rdma OR tcp OR rdma
例子：
重新均衡卷
语法：gluster volume rebalance <VOLNAME> fix-layout start
例子：gluster volume rebalance test-volume fix-layout start
⑸ Bigtable---分布式的结构化数据存储系统
sina
Bigtable 是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：通常是分布在数千台普通服务器上的PB 级的数据。Google 的很多项目使用Bigtable 存储数据，包括Web 索引、GoogleEarth、Google Finance。这些应用对Bigtable 提出的要求差异非常大，无论是在数据量上（从URL到网页到卫星图像）还是在响应速度上（从后端的批量处理到实时数据服务）。
Bigtable 已经实现了下面的几个目标：适用性广泛、可扩展、高性能和高可用性,Bigtable 是一个稀疏的、分布式的、持久化存储的多维度排序Map。
图一：一个存储Web 网页的例子的表的片断。行名是一个反向URL。contents 列族存放的是网页的内容，anchor 列族存放引用该网页的锚链接文本（alex 注：如果不知道HTML 的Anchor，请Google一把）。CNN 的主页被Sports Illustrater和MY-look 的主页引用，因此该行包含了名为“anchor:cnnsi.com”和“anchhor:my.look.ca”的列。每个锚链接只有一个版本（alex 注：注意时间戳标识了列的版本，t9 和t8 分别标识了两个锚链接的版本）；而contents 列则有三个版本，分别由时间戳t3，t5，和t6 标识。
行
Bigtable 通过行关键字的字典顺序来组织数据。表中的每个行都可以动态分区。每个分区叫做一个”Tablet”，Tablet 是数据分布和负载均衡调整的最小单位。
列族
Webtable 有个列族language，language 列族用来存放撰写网页的语言。
我们在language 列族中只使用一个列关键字，用来存放每个网页的语言标识ID。Webtable 中另一个有用的列族是anchor；这个列族的每一个列关键字代表一个锚链接，如图一所示。Anchor 列族的限定词是引用该网页的站点名；Anchor 列族每列的数据项存放的是链接文本。访问控制、磁盘和内存的使用统计都是在列族层面进行的。
时间戳
不同版本的数据通过时间戳来索引。Bigtable 时间戳的类型是64 位整型。
Bigtable 可以给时间戳赋值，用来表示精确到毫秒的“实时”时间；用户程序也可以给时间戳赋值。如果应用程序需要避免数据版本冲突，那么它必须自己生成具有唯一性的时间戳。数据项中，不同版本的数据按照时间戳倒序排序，即最新的数据排在最前面。为了减轻多个版本数据的管理负担，我们对每一个列族配有两个设置参数， Bigtable 通过这两个参数可以对废弃版本的数据自动进行垃圾收集。用户可以指定只保存最后n 个版本的数据，或者只保存“足够新”的版本的数据（比如，只保存最近7 天的内容写入的数据）。
Bigtable支持的其他特性
1、Bigtable 支持单行上的事务处理，利用这个功能，用户可以对存储在一个行关键字下的数据进行原子性的读-更新-写操作。
2、Bigtable 允许把数据项用做整数计数器。
3、Bigtable 允许用户在服务器的地址空间内执行脚本程序
4、Bigtable 可以和MapRece一起使用，MapRece 是Google 开发的大规模并行计算框架。我们已经开发了一些Wrapper 类，通过使用这些Wrapper 类，Bigtable 可以作为MapRece 框架的输入和输出。
Bigtable依赖于google的几项技术。用GFS来存储日志和数据文件；按SSTable文件格式存储数据；用Chubby管理元数据：
Bigtable是建立在其它的几个Google基础构件上的。BigTable 使用Google 的分布式文件系统(GFS)存储日志文件和数据文件。BigTable 集群通常运行在一个共享的机器池中，池中的机器还会运行其它的各种各样的分布式应用程序，BigTable 的进程经常要和其它应用的进程共享机器。BigTable 依赖集群管理系统来调度任务、管理共享的机器上的资源、处理机器的故障、以及监视机器的状态。
BigTable 内部存储数据的文件是Google SSTable 格式的。SSTable 是一个持久化的、排序的、不可更改的Map 结构，而Map 是一个key-value 映射的数据结构，key 和value 的值都是任意的Byte串，从内部看，SSTable 是一系列的数据块（通常每个块的大小是64KB，这个大小是可以配置的）。。SSTable 使用块索引（通常存储在SSTable 的最后）来定位数据块；在打开SSTable的时候，索引被加载到内存。每次查找都可以通过一次磁盘搜索完成：首先使用二分查找法在内存中的索引里找到数据块的位置，然后再从硬盘读取相应的数据块。也可以选择把整个SSTable 都放在内存中，这样就不必访问硬盘了。
BigTable 还依赖一个高可用的、序列化的分布式锁服务组件，叫做Chubby。Chubby有五个活跃副本，同时只有一个主副本提供服务，副本之间用Paxos算法维持一致性，Chubby提供了一个命名空间（包括一些目录和文件），每个目录和文件就是一个锁，Chubby的客户端必须和Chubby保持会话，客户端的会话若过期则会丢失所有的锁。
Bigtable 包括了三个主要的组件：链接到客户程序中的库、一个Master主服务器和多个Tablet片 服务器。
Bigtable会将表（table）进行分片，片（tablet）的大小维持在100-200MB范围，一旦超出范围就将分裂成更小的片，或者合并成更大的片。每个片服务器负责一定量的片，处理对其片的读写请求，以及片的分裂或合并。片服务器可以根据负载随时添加和删除。这里片服务器并不真实存储数据，而相当于一个连接Bigtable和GFS的代理，客户端的一些数据操作都通过片服务器代理间接访问GFS。主服务器负责将片分配给片服务器，监控片服务器的添加和删除，平衡片服务器的负载，处理表和列族的创建等。注意，主服务器不存储任何片，不提供任何数据服务，也不提供片的定位信息。
客户端需要读写数据时，直接与片服务器联系。因为客户端并不需要从主服务器获取片的位置信息，所以大多数客户端从来不需要访问主服务器，主服务器的负载一般很轻。
Master 服务器主要负责以下工作：为Tablet 服务器分配Tablets、检测新加入的或者过期失效的Table 服务器、对Tablet 服务器进行负载均衡、以及对保存在GFS 上的文件进行垃圾收集。除此之外，它还处理对模式的相关修改操作，例如建立表和列族。
我们使用一个三层的、类似B+树的结构存储Tablet 的位置信息。
第一层是一个存储在Chubby 中的文件，它包含了Root Tablet 的位置信息。这个Chubby文件属于Chubby服务的一部分，一旦Chubby不可用，就意味着丢失了root tablet的位置，整个Bigtable也就不可用了。
第二层是root tablet。root tablet其实是元数据表（METADATA table）的第一个分片，它保存着元数据表其它片的位置。root tablet很特别，为了保证树的深度不变，root tablet从不分裂。
第三层是其它的元数据片，它们和root tablet一起组成完整的元数据表。每个元数据片都包含了许多用户片的位置信息。
片的数据最终还是写到GFS里的，片在GFS里的物理形态就是若干个SSTable文件。下图展示了读写操作基本情况。
BigTable和GFS的关系
集群包括主服务器和片服务器，主服务器负责将片分配给片服务器，而具体的数据服务则全权由片服务器负责。但是不要误以为片服务器真的存储了数据（除了内存中memtable的数据），数据的真实位置只有GFS才知道，主服务器将片分配给片服务器的意思应该是，片服务器获取了片的所有SSTable文件名，片服务器通过一些索引机制可以知道所需要的数据在哪个SSTable文件，然后从GFS中读取SSTable文件的数据，这个SSTable文件可能分布在好几台chunkserver上。
一个简化的Bigtable结构图：
结构图以Webtable表为例，表中存储了网易、网络和豆瓣的几个网页。当我们想查找网络贴吧昨天的网页内容，可以向Bigtable发出查询Webtable表的(com..tieba, contents:, yesterday)。
假设客户端没有该缓存，那么Bigtable访问root tablet的片服务器，希望得到该网页所属的片的位置信息在哪个元数据片中。使用 METADATA.Webtable.com..tieba 为行键在root tablet中查找，定位到最后一个比它大的是 METADATA.Webtable.com..www ，于是确定需要的就是元数据表的片A。访问片A的片服务器，继续查找 Webtable.com..tieba ，定位到 Webtable.com..www 是比它大的，确定需要的是Webtable表的片B。访问片B的片服务器，获得数据。
这里需要注意的是，每个片实际都由若干SSTable文件和memtable组成，而且这些SSTable和memtable都是已排序的。这就导致查找片B时，可能需要将所有SSTable和memtable都查找一遍；另外客户端应该不会直接从元数据表获得SSTable的文件名，而只是获得片属于片服务器的信息，通过片服务器为代理访问SSTable。
⑹ 如何自己在linux上搭建类似云盘的分布式云存储
如何自己在linux上搭建类似云盘的分布式云存储
对分布式的要求（弹性可伸缩、高可用）的需求，只是为了整合多个电脑的存储资源，并且还想要一个漂亮的操作界面的话，最简单的方法其实是用iscsi将其他电脑的存储资源挂载到服务器，然后使用seafile提供服务。
如果真正的有对分布式存储的需求并且对界面没什么需求或者打算自己开发一个界面的话，swift，ceph，glusterFS都是可以考虑的可靠的技术。（需求简单的话swift还是有很多界面的，也是可以考虑
⑺ GFS采用了哪些容错措施来确保整个系统的可靠性
GFS的精彩在于它采用了多种方法，从多个角度，使用不同的容错措施来确保整个系统的可靠性。
客户端在访问GFS时，首先访问Master节点，获取将要与之进行交互的Chunk Server信息，然后直接访问这些Chunk Server完成数据存取。GFS的这种设计方法实现了控制流和数据流的分离。Client与Master之间只有控制流，而无数据流，这样就极大地降低了Master的负载，使之不成为系统性能的一个瓶颈。Client与Chunk Server之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个Chunk Server，从而使得整个系统的I/O高度并行，系统整体性能得到提高。
⑻ 如何实现高性能分布式文件存储
其实分布式文件存储，最复杂的就是元数据的保存和处理，而我使用的XGFS文件存储软件只需要三个全闪存元数据高可用节点，就可以高效保存和处理 100 亿文件规模的数据，可以灵活扩展，满足公司不断增长的业务对性能和容量的需求，XSKY星辰天合这款产品还是很有性价比的。
⑼ GFS论文笔记
GFS的诞生来源于google日益增长的数据量的处理需求，它是一个可扩展的分布式文件系统，用于大型分布式数据密集型应用，在廉价的通用硬件上运行时提供容错机制，并且可以为大量客户端提供较高的聚合性能。
它的设计由当前和预期的应用负载(当时的)和技术环境驱动，与以前的文件系统的假设有着明显不同，因此gfs在设计上有几个不同的points：
当前已部署多个集群用于不同目的，最大的拥有1000多个存储节点，超过300TB的存储服务，并且有数百个客户端连续不断地高负载请求。
前面提到一些对应用负载和技术环境的观察，现在更详细地进行阐述：
虽然GFS不能提供像POSIX标准的API，但它提供一个相似的文件系统接口。文件在目录中按层次结构组织，并以路径名作为标识。支持create、delete、open、close、read and write files。
gfs支持快照和record append操作。快照以低代价创建文件副本或者目录树，record append支持多个客户端并发地写文件，保证每个独立客户端append的原子性。
一个gfs集群包含一个master和多个chunkservers，chunkserver被多个客户端访问，如图1所示。每一个都是普通linux机器上运行的用户态服务进程。资源允许的情况下，客户端可以和chunkserver部署在同一台机器上。
文件被划分为固定大小的块。每个chunk由一个独一无二的64位大小的chunk handle所标识，chunk handle在chunk被创建时由master分配。每个chunk的副本分布在多个机器上，系统默认为三副本模式，用户也可以为不同namespace的文件指定不同级别的副本。
master包含文件系统的所有元信息。包含namespace、访问控制权限信息、文件到chunks的映射、当前chunks的位置信息。也控制着全局的活动，像chunk租约管理、gc、chunk迁移等。master通过心跳的方式与每个chunkserver交流来发送它的指令和收集状态。
客户端与master的交互涉及元信息操作，所有数据操作直接与chunkserver交互。gfs不提供POSIX标准API，因此不需要挂接到linux的vnode层。
客户端和chunkserver都不缓存文件数据。大多数应用传输大文件，客户端缓存收益很低。chunks作为本地的文件存储，linux系统有自己的buffer cache，chunkserver不需要再增加缓存。
单master简化了系统的设计，但是会有单点的瓶颈问题，这是必须要解决的。客户端不会从master读写数据文件，客户端请求master它需要的交互的chunkserver信息，并且将其缓存一段时间，后续的操作直接与chunkservers交互。
客户端会发送请求给离它最近的一个副本。实际上，客户端通常会向master请求多个chunk的信息，以减少未来与maser交互的代价。
chunk size定为64MB，相比普通的文件系统的block size更大。每个chunk副本以linux文件的形式存在chunkserver上，仅根据需要来扩展。使用lazy space allocation的方式避免空间浪费。
large chunk size有以下几个优点：
但是large chunk size with lazy space allocation也有其缺点：单个文件可能包含很少数量的chunks，或许只有一个，当许多客户端访问相同文件时这些chunks成为热点。但由于目标应用大多是顺序的读多个large chunk文件，热点并不是主要的问题。
然而GFS第一次用于批处理队列系统时确实出现了热点问题，数百个客户端同时访问一个单chunk文件，存储这个文件的几个chunkserver超负荷运转，当时通过错开应用的启动时间避免了这个问题，一个潜在、长期的解决方法是允许客户端从其它客户端读取数据。
master保存三种类型的元数据：
所有元数据都保存在内存中 。对于元数据的内存操作是很快的，后台任务周期巡检整个状态也是比较简单高效的。周期巡检用于实现chunk gc、在chunkserver故障时重新构造副本、chunk迁移以平衡多个chunkserver的负载和disk usage。
虽然系统的容量受master内存大小的限制，但这并不是一个严重的问题，64MB的chunk只需要不到64byte大小的元信息，如果一定需要更大的文件系统，那么增加内存的代价相比为可靠性、性能和灵活性等付出的代价是较小的。
前两种类型的元数据通过写日志来保证持久化，并且会复制日志到远程机器上。master不需要将chunks的位置信息持久化，而是在master启动和新的chunkserver加入集群时向每个chunkserver询问它的位置信息，之后通过心跳信息监控chunk位置变更信息。chunkserver作为最后一关是确切知道自己本地有没有哪些chunk的，因此维护一个一致性的视图是没有必要的。
operation log 包含元数据的变更记录， 它是GFS的核心 ，它不仅仅是唯一的元数据持久化记录，也表明了并发操作的逻辑时间线。文件、chunks和它们的版本都是由逻辑时间线唯一标识。元数据变更记录在持久化之前对客户端是不可见的，而且日志被复制到多个远程的机器，只有相应的记录在本地和远程都持久化到硬盘了才可以回复客户端。master使用批处理log的方式提高系统的吞吐。
master通过回放日志来恢复文件系统的状态，为提高恢复速度需要保持log量足够小。当log增长超过特定大小时，master会checkpoint它的状态，以加速恢复提高可用性。构建checkpoint可能需要花费一段时间，因此master以一种不delay后续变化的方式来组织内部状态，先switch到一个新的日志文件，使用独立的线程创建checkpoint，新的checkpoint包含了所有switch之前的变化。几百万个文件的集群在一分钟内可以完成，完成后将同时被写入本地和远程。恢复只需要最新的checkpoint和之后的日志文件，旧的checkpoints和日志文件可以完全删除。
GFS使用一个宽松的一致性模型，这种模型可以很好地支持分布式应用程序，而且实现起来简单有效。
file namesapce变化(例如文件创建)是原子的，使用namespace锁。
master的operation log定义了这些操作的全局顺序。
数据变化后文件region的状态取决于变化的类型，是否成功、失败或者是并发的。Table1做了总结。如果所有客户端都能看到相同的数据，无论它们读的是哪个副本，则这个file region是一致的。
数据变化有两种：writes或者record appends。write是指从应用指定offset处开始写数据，record append指即使存在并发冲突，数据也要被原子地append到文件至少一次，但offset是由GFS选定。
GFS保证在一系列成功的mutations后，file region是defined，通过下面两点来保证：
过期的副本将不会再涉及到任何mutation，master也不会将其位置信息回应给客户端，不久后将会被gc。但客户端缓存的信息可能包含过期的副本，缓存失效存在一个时间窗口，文件再次打开也会清除该文件的所有chunk信息。由于大多数文件是append-only，过期的副本通常返回的是过早的结尾???而不是过期的数据。
介绍客户端、master和chunkserver之间如何交互来实现数据变化、原子追加写和快照的。
使用租约的方式维护多个副本间一致的mutation order。master授权租约给副本中的一个，称之为primary。primary为chunk的mutaions选择一个顺序，所有副本都按照这个顺序apply。
租约机制最小化了master的管理overhead。租约初始的超时时间是60s，如果chunk一直在变化过程中，primary可以申请续租。这些授权和续租请求由master和chunkserver之间的心跳信息携带。master也可以尝试撤销租约，即使它与primary失去了联系，也可以等租约过期后安全地授权给另外一个副本。
在Figure2中，跟随着写入控制流展示了处理过程：
如果一个写请求比较大或者超出了chunk边界，GFS客户端将它拆为多个写操作，但是多个操作可能与其它客户端并发交叉写入，因此共享的fie region最终可能包含多个不同客户端的碎片，这会造成 一致性模型 中所描述的file region处于consistent but undefined状态。
数据以pipline的机制在chunkserver链上线性传输，而控制流是从客户端到primary再到所有的其它副本。分离数据流和控制流可以更高效地使用网络。可以带来以下好处：
GFS提供原子的append operaton叫作 record append 。传统的write中，客户端指定offset，并发写相同region时不是serializable，最终region可能包含多个客户端的碎片数据。而对于record append，客户端仅指定数据，GFS保证至少一次成功的原子append，offset由GFS选定，与Unix的O_APPEND模式相似。
多个客户端并发操作相同文件是比较重的。如果处理传统的write，客户端需要额外复杂和昂贵的同步逻辑，像分布式锁。而record append仅需要primary增加一点额外的逻辑：primary检查是否并发append数据的chunk会超出max size，如果会超出则将chunk填充到max size，并且告诉所有二级副本同样操作，然后回应客户端指出这个操作应该选择另一个chunk重试；大多数情况下记录是在max size内的，primary将数据append到自己的副本，并告诉所有二级副本按照确切的offset写数据，最后回应给客户端。
如果中间出现错误，客户端重试，相同chunk的副本可能包含不同的数据，可能包含相同的记录或者一部分相同，GFS不保证bytewise identical，仅仅保证数据至少有一次被成功地原子写入。从report success逻辑可以容易得出，数据必须是在某个chunk的所有副本上以相同的offset写入。在此之后，所有副本都与记录end一样长，即使后面不同的副本成为primary，任何将来的记录也将分配到更高的offset或者不同的chunk。根据上述的一致性保证，成功的record append的region是defined和一致的，而中间的region是不一致的(undefined)。GFS的应用可以处理这种不一致的region(2.7.2)。
snapshot 操作拷贝一份文件或者目录树，几乎是实时的，同时最大程度减少对正在进行中的mutation的干扰。
像AFS一样，使用标准的COW技术实现snapshot。当master接收到一个snapshot请求，首先将所有涉及到chunks的租约撤销，这保证了这些chunks后续的write将会先请求master查找租约持有者，master会创建一个新的副本来回应。
租约被撤销或者过期后，master将这个操作记录日志到disk。新创建的snapshot引用元数据相同的chunks。
当snapshot操作完成后，客户端第一次要写chunk C，发送请求给master查询持有租约者，master察觉到chunk C的引用大于1，则让每个含有当前chunk副本的chunkserver创建一个新的chunk叫作C'，所有创建都使用本地的副本，相比100Mb的网络本地速度大约是三倍速度。master授权租约给新的chunk C'中的一个并且回复给客户端，之后正常地写chunk。整个过程对客户端是透明的。
master执行所有的namespace操作。另外，它管理整个系统的chunk副本：
接下来，详细探讨这些细节。
许多master操作可能花费较长一段时间，比如snapshot操作需要撤销相关的所有chunks的租约。因此为了不delay其它master操作，在namesapce的regions上使用locks来确保串行化。
GFS没有按目录列出该目录中所有文件的结构，也不支持文件和目录的别名(unix中的硬链和软链)。GFS将完整的路径名到元数据的映射表作为它的逻辑namespace。使用前缀压缩，这个表可以有效保存在内存中。namespace tree中的每个节点都有一个关联的读写锁。
每个master操作在运行前都会获取一组锁。如果涉及到/d1/d2/../dn/leaf，它将获取目录名称/d1、/d1/d2、...、/d1/d2/.../dn上的读锁，完整路径/d1/d2/../dn/leaf的读锁或者写锁。leaf可以是文件或者目录。
创建文件不需要对父级目录加锁，因为没有"目录"的概念不会修改它，而加读锁是防止它被删除、重命名或者snapshot。这种锁机制的好处是允许相同目录下并发的mutations。
一个GFS集群通常具有分布在多个机架上的数百个chunkserver，这些chunkserver也会被相同或者不同机架的数百个客户端访问。不同机架上的两台计算机之间的通信可能会跨越一个或者多个网络交换机。另外进出机架的带宽可能小于机架内所有计算机的总带宽。多级分布式对如何分发数据以实现可伸缩性、可靠性和可用性提出了独特的挑战。
副本放置策略有两个目的：最大化数据可靠性和可用性，最大化网络带宽利用率。不仅要在多台机器上放置，还要在多个racks上，即使整个racks损坏也可以确保部分副本保持可用。也可以利用多个racks的总带宽。
chunk副本创建有三个原因：
当master创建新的chunk时，根据几个因素考虑如何放置新的副本：
当chunk可用副本的数量低于用户指定时，master会重新复制。可能发生在几种情况：
需要重新复制的chunk根据以下几个因素确定优先级：
master限制集群和每一个chunkserver内的活跃的clone数量，另外chunkserver通过限制其对源chunkserver的读请求来限制在每个clone操作上花费的带宽。
master会定期重新平衡副本：检查当前副本的分布，迁移副本以获得更好的磁盘空间利用率和负载平衡。同样通过此过程，master逐渐填充一个新的chunkserver。另外，master通常更倾向于移除具有低磁盘利用率chunkservers上的副本，以平衡空间使用。
当文件被删除时，master记录日志，但不会立即回收资源，而是将文件重命名为包含删除时间戳标记的隐藏名称。如果这些文件存在时间超过三天(时间可配置)，master巡检时会将其删除。在此之前，仍然可以用特殊名称来读取文件，并且可以重命名为正常名称来取消删除。当从namesapce中删除隐藏文件时，其内存元数据将被删除，这有效切断了所有chunk的连接，在对chunk namespace的扫描中，master识别出孤立的chunk并清除元数据。在心跳信息中，每个chunkserver报告其拥有的chunks子集，而master将回应不在存在于master元数据中的所有的chunk的标识。chunkserver可以自由删除此类chunk的副本。
这种gc机制相比立即删除有以下几个优点：
这种机制主要的缺点是当存储空间紧张时，延迟有时会影响用户的使用，重复创建和删除临时文件的应用可能无法立即重用存储。如果删除的文件再次被明确删除，GFS将通过加快存储回收来解决这些问题。还允许用户将不同的复制和回收策略应用于不同的namespace的不同部分中。
如果一个chunkserver故障或者chunk丢失了mutations，这个chunk副本可能是过期的。对于每个chunk，master都维护了一个chunk版本号。
当master授权租约给一个chunk时，这个chunk的版本号增加1，如果一个副本当前不可用了，则其版本号将不会领先。当chunkserver重新启动并报告其chunks集合和相关联的版本号时，master将检测到该chunkserver上具有过期的副本。如果master看到的版本号大于它记录的版本号，则认为在授权租约时失败了，因此将较高的版本号更新。
master在常规gc中删除旧的副本。另一个保护措施，在master回应客户端哪个chunk持有租约或者clone操作中chunkserver从另一个chunkserver读取chunk时会包含chunk的最新版本号。客户端或者chunkserver在执行操作时会验证版本号。
这个系统最大的挑战之一是处理经常故障的组件。组件的质量和数量造成的问题会超出预期，组件故障可能造成系统不可能，甚至数据错误。接下来讨论GFS如何应对这些挑战，还有系统如何诊断不可避免问题。
使用两个简单有效的方式保证系统的高可用：快速恢复和复制。
master和chunkserver的恢复都是秒级别的。
master维护每个chunk的副本数量，当chunkserver下线或者checksum检测出错误副本时，master会通过已有副本来复制。尽管复制提供了很好的解决方式，但仍在探索其它形式的跨服务器冗余方案，例如奇偶校验或者纠删码，以适应不断增长的只读存储需求。在非常松耦合的系统中实现这些更复杂的冗余方案更具有挑战性。
master的操作日志和checkpoint会被复制到多台机器上，状态的变化只有在本地和所有副本上都持久化以后才可以commit。master进程负责所有的mutations以及后台任务，当它宕机时可以很快重启，如果机器或者磁盘故障，GFS的外部监控将使用日志在其它节点重启新的master进程。在master宕机时，master的备节点只提供只读服务，它们不与master保持强一致，可能会落后于master，通常在1/4秒内。它们保证了那些不介意读到过期数据的应用的高可用读。类似于chunk的primary机制，master的备按照相同的序列应用日志。与master一样，在启动时从每个chunkserver拉取chunks的位置信息，与它们频繁交换握手消息来监控其状态。
每个chunkserver使用checksum来检测存储数据的损坏。数据损坏的chunk可以通过其它的副本来恢复，但是通过副本间比较来检验数据是不切实际的。正常的副本也不是完全一样的，如前文所讲，原子的append并不能保证完全一样的副本。因此每个chunkserver会维护自己的checksum。
每个chunk分为多个64kb的blocks，每个block包含一个32位的checksum，与其它元数据一样，checksum保存在内存中，依靠log持久化，与用户数据分离。
对于读，chunkserver在返回数据给请求者前先检测checksum，确保不会将出错的数据传输给其它chunkservers或者客户端。如果数据是坏的，chunkserver将错误返回给请求者并报告给master，请求者将会去读其它副本， master将会根据其它副本重新克隆一份。当新的副本创建以后，master指示chunkserver将错误的副本删除。checksum的计算不涉及I/O，对读的影响比较小，客户端通常尝试使用对齐block边界读来减少overhead。
为append写是做了checksum计算上的优化的，因为append写是主要的负载(相比于overwrite)。GFS只增量地更新最后部分block的checksum，为新的block的计算新的checksum。这样即使block已经损坏，新的checksum将与存储的数据不会匹配，下次读时将会与正常一样被检测出来。
如果一个写请求要写一个chunk中已存在的region，必要要先检验region的第一个和最后一个block的checksum，然后再重写，最后计算新的checksums。因为第一个和最后一个block可能含有不被重写的内容，如果这部分数据是损坏的，则新的checksum将包含错误的数据。
在idle时，checkserver可以扫描并检查不活跃的chunks，可以检测到冷chunks的错误，一旦错误被检测到，master可以创建一个新的副本。
GFS在设计上与传统文件系统有很多不同，这些点是基于对当时应用负载和技术环境的观察所重新设计，将组件故障看作平常的事件而非异常，为大文件的读取和追加写做优化，扩展和放宽了标准的文件系统接口以改善整个系统。通过监控、复制以及快速恢复能力提供容错能力，使用checksum机制来校验数据的正确性。通过将控制流和数据流分离，数据直接在chunkservers、客户端之间传输，为许多并发的各种任务的读取和写入提供了高吞吐量。大chunk size和租约机制使得master的操作足够轻量化，使得这样一个简单中心化的master不会成为瓶颈。
GFS成功地满足了google的存储需求，作为研究、开发和数据处理的存储平台广泛地应用于google内部。
⑽ 介绍一下云计算的核心技术
云计算系统运用了许多技术，其中以编程模型、数据管理技术、数据存储技术、虚拟化技术、云计算平台管理技术最为关键。
(1)编程模型
MapRece是Google开发的java、Python、C++编程模型，它是一种简化的分布式编程模型和高效的任务调度模型，用于大规模数据集（大于1TB）的并行运算。严格的编程模型使云计算环境下的编程十分简单。MapRece模式的思想是将要执行的问题分解成Map(映射)和Rece(化简)的方式，先通过Map程序将数据切割成不相关的区块，分配（调度）给大量计算机处理，达到分布式运算的效果，再通过Rece程序将结果汇整输出。
(2) 海量数据分布存储技术
云计算系统由大量服务器组成，同时为大量用户服务，因此云计算系统采用分布式存储的方式存储数据，用冗余存储的方式保证数据的可靠性。云计算系统中广泛使用的数据存储系统是Google的GFS和Hadoop团队开发的GFS的开源实现HDFS。
GFS即Google文件系统（Google File System），是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。GFS的设计思想不同于传统的文件系统，是针对大规模数据处理和Google应用特性而设计的。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。
一个GFS集群由一个主服务器（master）和大量的块服务器(chunkserver)构成，并被许多客户（Client）访问。主服务器存储文件系统所以的元数据，包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，块服务器间的块迁移。主服务器定期通过HeartBeat消息与每一个块服务器通信，给块服务器传递指令并收集它的状态。GFS中的文件被切分为64MB的块并以冗余存储，每份数据在系统中保存3个以上备份。
客户与主服务器的交换只限于对元数据的操作，所有数据方面的通信都直接和块服务器联系，这大大提高了系统的效率，防止主服务器负载过重。
(3) 海量数据管理技术
云计算需要对分布的、海量的数据进行处理、分析，因此，数据管理技术必需能够高效的管理大量的数据。云计算系统中的数据管理技术主要是Google的BT(BigTable)数据管理技术和Hadoop团队开发的开源数据管理模块HBase。
BT是建立在GFS, Scheler, Lock Service和MapRece之上的一个大型的分布式数据库，与传统的关系数据库不同，它把所有数据都作为对象来处理，形成一个巨大的表格，用来分布存储大规模结构化数据。
Google的很多项目使用BT来存储数据，包括网页查询，Google earth和Google金融。这些应用程序对BT的要求各不相同：数据大小（从URL到网页到卫星图象）不同，反应速度不同（从后端的大批处理到实时数据服务）。对于不同的要求，BT都成功的提供了灵活高效的服务。
（4）虚拟化技术
通过虚拟化技术可实现软件应用与底层硬件相隔离，它包括将单个资源划分成多个虚拟资源的裂分模式，也包括将多个资源整合成一个虚拟资源的聚合模式。虚拟化技术根据对象可分成存储虚拟化、计算虚拟化、网络虚拟化等，计算虚拟化又分为系统级虚拟化、应用级虚拟化和桌面虚拟化。
（5）云计算平台管理技术
云计算资源规模庞大，服务器数量众多并分布在不同的地点，同时运行着数百种应用，如何有效的管理这些服务器，保证整个系统提供不间断的服务是巨大的挑战。
云计算系统的平台管理技术能够使大量的服务器协同工作，方便的进行业务部署和开通，快速发现和恢复系统故障，通过自动化、智能化的手段实现大规模系统的可靠运营。
我是从IT号外知道的。