Windows Azure Storage设计原理

小提示：您能找到这篇{Windows Azure Storage设计原理}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Windows Azure Storage设计原理内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">Windows Azure Storage(WAS)是微软提供的云存储服务。

< font-size: 16px;">WAS设计的主要目标

< font-size: 16px;">强一致性，号称CAP都能满足

< font-size: 16px;">提供全球统一的存储服务

< font-size: 16px;">提供完善的异地容灾支持

< font-size: 16px;">WAS的名字空间

< font-size: 16px;">WAS提供三种存储抽象，分别是表格（Table）、消息队列（Queue）、文件（Blob），WAS存储的每个对象（表格里的一行、队列里的一条消息、一个文件）都对应一个全局唯一的资源URI，其中AccountName为用户账户，service为存储服务类型（table、queue、blob中的一种）。

< font-size: 16px;">http(s)://https://AccountName.1.core.windows.net/PartitionName/ObjectName

< font-size: 16px;">对于Table，PartitionName为表名，ObjectName为表内行的primary key

< font-size: 16px;">对于Queue，PartitioinName为队列名字，ObjectName为队列里消息的id

< font-size: 16px;">对于Blob，ObjectName为文件名，PartitionName与ObjectName相同

< font-size: 16px;">WAS总体架构

< font-size: 16px;">

< font-size: 16px;">WAS借助DNS服务来实现全局存储服务，Location Service负责管理用户的账户信息，当用户注册了一个WAS账户后，Location Service会为用户分配一或多个stamp来提供存储服务，同时更新DNS里的记录，将https://AccountName.1.core.windows.net解析到stamp对应的访问入口。

< font-size: 16px;">WAS里stamp类似于集群的概念，请看下图，MS在全球有多个机房，每个机房会部署多个WAS存储集群（stamp），stamp内部通过副本机制来保证数据安全性，stamp间会有数据备份机制，用于异地容灾，比如stamp-001在美国、欧洲、亚洲的机房各有一份数据，任意一个机房故障，都能从其他机房的对等stamp里读到用户数据。

< font-size: 16px;">

< font-size: 16px;">一个stamp典型的规模，10-20个机架，每个机架18个存储节点，约提供2PB的存储空间；下一代WAS，每个stamp将提供30PB的存储空间（猜想主要是单块盘存储空间增加）。

< font-size: 16px;">Stamp内部架构

< font-size: 16px;">单个stamp内部，主要分为三个层次

< font-size: 16px;">Stream Layer：提供可靠的文件存储（类比GFS)

< font-size: 16px;">Partion Layer:提供Table、Queue、Blob存储的逻辑抽象，实际数据存储依赖Stream Layer(类比bigtable）

< font-size: 16px;">Front End：存储资源访问代理，接受用户的请求，通过Partition Layer获取到数据，返回给用户

< font-size: 16px;">Stream Layer设计

< font-size: 16px;">Stream Layer可以理解为提供可靠存储的分布式文件系统，提供层次性的命名空间，如下图，Stream Layer存储的Foo文件。

< font-size: 16px;">

< font-size: 16px;">Foo文件由多个extent组成（类似GFS里的block的概念，但非定长，每个extent存储时对应一个NTFS文件），extent由多个block组成。extent创建时，会对应多个副本，客户端可以不断以block为单位（1或多个block）向extent追加数据，每个block会计算一份校验信息用于检查数据完整性，每次从extent读取数据时，都需要读取整个block的数据来校验数据完整性；每个extent还对应一个inde危机公关针对对象x文件，用于映射[extent，offset]到block。（partition layer来说，它会维护每个对象存储在stream layer的[文件，extent，offset]作为对象的位置索引信息。）

< font-size: 16px;">Stream Layer主要包含Stream Manager(SM，相当于元数据服务器)和Extent Node（EN，相当于存储节点）。

< font-size: 16px;">

< font-size: 16px;">SM的主要职责：

< font-size: 16px;">维护名字空间以及所有文件及extent的状态

< font-size: 16px;">管理所有EN的运行状态

< font-size: 16px;">为EN创建和分配extent

< font-size: 16px;">当有EN宕机时，复制缺少副本的extent

< font-size: 16px;">对只读的extent进行earsure code编码

< font-size: 16px;">extent一旦创建，便不可更改，只能追加数据，当extent到达一定长度时，客户端（Partition Layer）可以将extent封装(seal)起来，封装后的extent不能再被更新，如果文件要继续追加数据，客户端可以向SM请求创建新的extent，然后往新的extent里追加数据，在SM看来，文件就是由多个extent顺序连接而成。

< font-size: 16px;">extent的多个副本中，有一个是master，其它的副本是slave，每次针对extent的追加操作，客户端都会将请求发送至master，由master完成整个追加过程，master负责对所有的追加操作进行排序，然后决定追加操作在extent上的偏移（offset信息），同时请求多个slave在同样的offset上往extent追加数据，当所有副本都追加成功时，才认为追加操作成功。

< font-size: 16px;">如果在追加的过程种出现错误（只有部分副本追加成功），Stream Layer与客户端（Partition Layer）的约定是，客户端进行重试或是封装当前extent（以多个副本中extent的commit length最小的为准，commit length表示当前extent追加了多少数据），创建新的extent来追加数据。这个约定也意味着，同一个条记录可能在extent上追加多次，这就要求上层业务能够处理这种重复的记录。

< font-size: 16px;">Stream Layer的一些优化：

< font-size: 16px;">对封装后的extent（只读）进行earsure code编码，用于节省存储空间。

< font-size: 16px;">接收到读请求产品广告动画时，如果当前EN有很多请求在排队，或是有请求排队超过一定时间，则直接拒绝服务，让客户端重试其它副本

< font-size: 16px;">每个EN使用一块单独的盘（通常是ssd）做日志盘（cache），当EN执行追加操作时，会将请求的数据先追加到日志盘，同时写到EN上的数据盘（不刷盘，等待OS后台刷盘）。

< font-size: 16px;">Partition Layer设计

< font-size: 16px;">Partition Layer在Stream Layter的基础上抽象出Table、Queue存储逻辑，主要由Partition Manager（PM)和Partition Server（PS)组成，PM是管理节点，负责维护一个全局的试图，而实际的读写操作都由PS完成。

< font-size: 16px;">

< font-size: 16px;">为了方便描述，这里以存储Table为例说明。为了向用户提供表格的语义，在Partition layer会有一个有序的大表，存储所有用户的所有数据，每一行对应用户存储的一条表记录，考虑这张表非常大，单个server不可能服务过来，这张表被划分成很多个Range，然后均分到多个PS上，而PM维护一张Range==&gt;PS的映射表，Front End接受到用户请求时，会先从PM拿到映射表，然后将请求定向至负责对应range的PS上，Front End拿到映射表后会缓存在本地，并在映射表变化时更新。

< font-size: 16px;">

< font-size: 16px;">每个PS会负责多个Range的数据，PS实际不存储数据，数据存储是由底层的Stream Layer完成，每个Range包含一个用于存储操作日志的Commit Log文件和一个存储行数据的Row Data文件；同时Range被加载后，还会产生一些内存的数据结构。

< font-size: 16px;">Memory Table：内存表，记录对于该range的每一次更新。

< font-size: 16px;">Index Cache：表索引的缓存，索引每行数据在Row Data文件里的偏移位置。

< font-size: 16px;">Row Data Cache:行缓存，缓存行数据，与I酒店危机公关管理制度ndex Cache分离的原因主要是尽量让所有Index的数据都能加载到内存。

< font-size: 16px;">

< font-size: 16px;">当有新的行要写到某个Range时，首先会将行数据追加到Commit Log里，然后将行数据写到Memory Table，这时就可以向客户端(Front End）返回写成功。当Memory Table使用的内存超出阈值时，会做一次checkpoint操作，将Memory Table里的数据写至Row Data文件。

< font-size: 16px;">当Range里的数据太多时，会导致负责该Range的PS负载很高，这时PM可以将一些大的Range进行分裂，就部分Range交由负载较低的PS负责（PS本身不持久化数据，PS只需要加载Range对应的元数据即可服务针对该Range的请求）；相反，当某些Range由于数据删除导致数据很少时，PM可以将相邻的Range进行合并；最终使得各个PS的负载尽量均衡。