云存储

大规模数据存储面临的新问题与挑战？

成本问题
容量问题
可靠问题
使用问题

GFS体系结构？

一 个GFS集群由一个master和大量的chunkserver构成，并被许多客户（Client）访问。

采用中心服务器模模式
不缓存数据

在用户态下实现

提供专用的访问接口

GFS的容错机制？

Master容错
• 三类元数据：命名空间（目录结构）、Chunk与文件名的映射以及Chunk副本的位置信息
• 前两类通过日志提供容错，Chunk副本信息存储于Chunk Server，Master出现故障时可恢复

Chunk Server容错
• 每个Chunk有多个存储副本（通常是3个），分别存储于不通的服务器上

• 每个Chunk又划分为若干Block（64KB），每个Block对应一个32bit的校验码，保证数据正确（若某个Block错误，则转移至其他Chunk副本

Paxos协议？

Paxos协议用于解决多个节点之间的一致性问题。多个节点之间通过操作日志同步数据，如果只有一个节点为主节点，那么，很容易确保多个节点之间操作日志的一致性。考虑到主节点可能出现故障，系统需要选举出新的主节点。Paxos协议正是用来实现这个需求。只要保证了多个节点之间操作日志的一致性，就能够在这些节点上构建高可用的全局服务，例如分布式锁服务，全局命名和配置服务等。
为了实现高可用性，主节点往往将数据以操作日志的形式同步到备节点。如果主节点发生故障，备节点会提议自己成为主节点。这里存在的问题是网络分区的时候，可能会存在多个备节点提议（Proposer，提议者）自己成为主节点。Paxos协议保证，即使同时存在多个proposer，也能够保证所有节点最终达成一致，即选举出唯一的主节点。
大多数情况下，系统只有一个proposer，他的提议也总是会很快地被大多数节点接受。Paxos协议执行步骤如下：
1）批准（accept）：Proposer发送accept消息要求所有其他节点（acceptor，接受者）接受某个提议值，acceptor可以接受或者拒绝。
2）确认（acknowledge）：如果超过一半的acceptor接受，意味着提议值已经生效，proposer发送acknowledge消息通知所有的acceptor提议生效。
当出现网络或者其他异常时，系统中可能存在多个proposer，他们各自发起不同的提议。这里的提议可以是一个修改操作，也可以是提议自己成为主节点。如果proposer第一次发起的accept请求没有被acceptor中的多数派批准（例如与其他proposer的提议冲突），那么，需要完整地执行一轮Paxos协议。过程如下：
1）准备（prepare）：Proposer首先选择一个提议序号n给其他的acceptor节点发送prepare消息。Acceptor收到prepare消息后，如果提议的序号大于他已经回复的所有prepare消息，则acceptor将自己上次接受的提议回复给proposer，并承诺不再回复小于n的提议。
2）批准（accept）：Proposer收到了acceptor中的多数派对prepare的回复后，就进入批准阶段。如果在之前的prepare阶段acceptor回复了上次接受的提议，那么，proposer选择其中序号最大的提议值发给acceptor批准；否则，proposer生成一个新的提议值发给acceptor批准。Acceptor在不违背他之前在prepare阶段的承诺的前提下，接受这个请求。
3）确认（acknowledge）：如果超过一半的acceptor接受，提议值生效。Proposer发送acknowledge消息通知所有的acceptor提议生效。
Paxos协议需要考虑两个问题：正确性，即只有一个提议值会生效；可终止性，即最后总会有一个提议值生效。Paxos协议中要求每个生效的提议被acceptor中的多数派接受，并且每个acceptor不会接受两个不同的提议，因此可以保证正确性。Paxos协议并不能够严格保证可终止性。但是，从Paxos协议的执行过程可以看出，只要超过一个acceptor接受了提议，proposer很快就会发现，并重新提议其中序号最大的提议值。因此，随着协议不断运行，它会往“某个提议值被多数派接受并生效”这一最终目标靠拢

Chubby锁机制？

1、主要用于解决分布式一致性问题
• 在一个分布式系统中，有一组的Process，它们需要确定一个Value。于是每个Process都提出了一个Value，一致性就是指只有其中的一个Value能够被选中作为最后确定的值，并且当这个值被选出来以后，所有的Process都需要被通知到
2、粗粒度的分布式锁服务
• Chubby是Google为解决分布式一致性问题而设计的提供粗粒度锁服务的文件系统
• 其他分布式系统可以使用它对共享资源的访问进行同步

Chubby的通信协议？

Bigtable数据结构？

Bigtable是一个多维度的有序的map。由行列关键字和时间戳索引。行关键字可以是任意字符串，对一行的读写操作是原子的，不管该行有多少列。按行划分table，产生一些tablets，一般是连续的几行有一定的相关性，这样可以获得局部好的特性。列关键字可以分组归类，列族。一个列族内的数据一般具有相同的类型，可以进行压缩。列关键字命名使用“列族：标识”的形式。时间戳用来标识数据的不同版本。

。

Bigtable优化机制？

局部性群组(Locality Group)
• 根据需要，将原本不存储在一起的数据，以列族为单位存储至单独的子表
• 如用户对网站排名、语言等分析信息感兴趣，那么可以将这些列族放至单独的子表，减少无用信息读取，改善存取效率
布隆过滤器(Bloom Filter)
•用于判断列键是否位于SSTable中，快速确定某个列键的位置

合并压缩
• tablet含有多个SSTable导致查询效率低
• 合并压缩操作读取多个SSTable，创建一个新的SSTable来保持其中的最新数据

---旧的SSTable删除

---如果合并压缩操作完成

云存储应用的特点？

通用的设备支持（云存储的浏览端）
数据同步与共享
任意格式/大小文件
免费+付费