网络存储技术结课报告

第1章从淘宝网技术发展浅谈其成功与经验教训 (1)
1.1 引言 (1)
1.2 淘宝网浅谈 (1)
1.2.1 个人网站 (1)
1.2.2 Java时代 (2)
1.2.3 创造技术 (3)
1.2.4 分布式时代 (4)
1.2.5 中间件 (4)
1.2.6 Session框架 (5)
1.2.7 开放平台 (6)
1.3 总结 (6)
第2章大型云存储中心设计 (6)
2.1 引言 (6)
2.2 云存储中心设计 (7)
2.2.1 Hadoop平台 (7)
2.2.1.1 Hadoop分布式文件系统 (8)
2.2.1.2 MapReduce编程 (9)
2.2.1.3 Hbase分布式数据库 (10)
2.2.2 文件系统的设计 (11)
2.2.3文件块存储策略及副本策略设计 (12)
2.2.4 文件块更新算法设计 (14)
2.2.5事务故障恢复系统设计 (16)
2.2.6 目录存储与负载均衡设计 (16)
2.3 总结 (17)
参考文献 (17)
第1章从淘宝网技术发展浅谈其成功与经验教训
1.1 引言
至2011年年底，淘宝网拥有全国最大的Hadoop分布式计算集群之一，日新增数据50TB，有40PB海量数据存储，分布在全国各地80多个节点的CDN网络，支撑的流量超过800Gbps。

淘宝的搜索引擎能够对数十亿的商品数据进行实时搜索，另外，还拥有自主研发的文件存储系统和缓存系统，以及Java中间件和消息中间件系统，这一切组成了一个庞大的电子商务操作系统。

从商业数据上看，mazon的财报显示2011年完成了大约 480亿美元的交易额，eBay的2011年财报显示全年完成了大约600亿美元的交易额（不包括其独立的汽车交易平台）。

无论从交易额、商品数量还是从同比增速等指标上看，淘宝网均远超于此，是目前全球最大的电子商务平台。

如今淘宝网的流量已经是全球排名第12、国内排名第3）。

淘宝网的系统也从使用一台服务器，到采用万台以上的服务器。

淘宝网在整个发展过程中，经历了许多主动和被动的技术变革，笔者将根据这些浅谈淘宝系统的成功及经验教训。

1.2 淘宝网浅谈
本节中，笔者将淘宝的技术发展分为个人网站、Java时代、创造技术、分布式时代、中间件、Session框架、开放平台等七个阶段，并就每个阶段展开分析，浅谈淘宝系统的成功与经验教训。

1.2.1 个人网站
2003年4月7日，马云在杭州成立了淘宝网，这个创业团队的成员：三个开发工程师、一个UED工程师、三个运营工程师、一个经理，以及马云和他的秘书。

他们买了这样一个架构的网站：LAMP（Linux+Apache+MySQL+PHP），这个直到现在还是一个很常用的网站架构模型，其优点是：无须编译，发布快速，PHP语言功能强大，能做从页面渲染到数据访问所有的事情，而且用到的技术都是开源、免费的。

他们对这个网站进行了很多本地化的修改，其中最有技术含量的是对数据库进行了一个修改，原来是从一个数据库进行所有的读写操作，现在把它拆分成一个主库、两个从库，并且读写分离。

这么做的好处有几点：
存储容量增加了，有了备份，使得安全性增加了，读写分离使得读写效率得以提升。

在接下来的大半年时间里，这个网站迅速显示出了它的生机。

随着用户需求和流量的不断增长，系统做了很多日常改进，服务器由最初的一台变成了三台，一台负责发送Email、一台负责运行数据库、一台负责运行WebApp。

一段时间之后，商品搜索的功能占用数据库资源太大了，2003年7月，又把阿里巴巴中文站的搜索引擎iSearch搬了过来。

随着访问量和数据量的飞速上涨，问题很快就出来了，第一个问题出现在数据库上。

MySQL当时是第4版的，淘宝用的是默认的存储引擎MyISAM，这种存储引擎在写数据的时候会把表锁住。

当Master同步数据到Slave的时候，会引起Slave写，这样在Slave的读操作都要等待。

还有一点是会发生Slave上的主键冲突，经常会导致同步停止，这样，发布的一些东西明明已经成功了，但就是查询不到。

另外，当年的MySQL不比如今的MySQL，在数据的容量和安全性方面也有很多先天的不足，于是把MySQL换成Oracle就成了顺理成章的事情。

数据一开始是放在本地的，淘宝对Oracle做调优的工作，也对SQL进行调优。

后来数据量变大后，本地存储无法满足了，就买了NAS，NetApp的NAS作为数据库的存储设备，加上Oracle RAC来实现负载均衡。

在把数据的连接放在SQL Relay之后，这个代理服务经常会死锁，如同之前的MySQL死锁一样。

虽然做了很多修改，但当时那个版本内部处理的逻辑不对，问题很多，最快的解决办法就是“重启”它的服务。

在2003年10月，淘宝网上线了一个功能，叫做“安全交易”，卖家如果选择支持这种功能，买家就会把钱交给淘宝网，等他收到货之后，淘宝网再把钱给卖家，这就是现在的“支付宝”。

一年之后，几乎所有的卖家都选择担保交易，到后来干脆所有的交易都必须走担保交易。

在2012年支付宝的年会上，支付宝公布2011年的交易笔数已经是PayPal的两倍。

1.2.2 Java时代
在上一节，我们谈到淘宝SQL Relay的问题始终没有得到解决，而数据库必须要用Oracle，淘宝便决定更换开发语言。

把一个庞大的网站的开发语言换掉，无异于脱胎换骨。

现在摆在他们面前的问题是用什么办法把一个庞大的网
站从PHP语言迁移到Java，而且要求在迁移的过程中，不停止服务，原来系统的bugfix和功能改进不受影响。

项目组的大致方案是给业务分模块，一个模块一个模块地渐进式替换。

阿里巴巴18个创始人之一的架构师周悦虹，在Jakarta Turbine的基础上做了很多扩展，打造了一个阿里巴巴自己用的MVC框架WebX，这个框架易于扩展，方便组件化开发，它的页面模板支持JSP和Velocity等，持久层支持ibatis和hibernate等，控制层可以用EJB和Spring。

于是淘宝选择了这个强大的框架。

淘宝MVC框架是阿里的WebX，控制层是EJB，持久层是ibatis。

“支付宝”也是用同样的架构做出来的网站。

随着数据量的上涨，数据的存储方面就不得不考虑使用小型机，然后Oracle就运行在了小型机上，存储方面，从EMC低端CX存储到Sun oem hds高端存储，再到EMC dmx高端存储，然后淘宝的架构师们便开始研究数据库的扩展性。

一台Oracle的处理能力是有上限的，它的连接池有数量限制，查询速度与容量成反比。

要突破这种极限，最简单的方式就是多用几个Oracle数据库。

淘宝的做法是把用户的信息按照ID来存放到两个数据库中，把商品的信息和卖家信息放在两个对应的数据库中，把商品类目等通用信息放在第三个库中。

数据量的增长给数据存储带来了很大压力，于是，淘宝的架构师做了一个基于 Berkeley DB 的缓存系统，把很多不太变动的只读信息放了进去。

在这个稳定的版本下，淘宝网的业务有了突飞猛进的发展。

1.2.3 创造技术
淘宝网有很多文件需要存储，最主要的就是图片、商品描述、交易快照，一个商品要包含几张图片和一长串的描述信息，而每一张图片都要生成几张规格不同的缩略图。

图片在交易系统中非常重要，淘宝网的商品照片，尤其是热门商品图片的访问流量是非常大的。

从2006年开始，淘宝决定自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题。

这标志着淘宝网从使用技术到了创造技术的阶段。

2007年，Google公布了GFS的设计论文，这给淘宝带来了很多借鉴的思路，并随后开发出了适合淘宝使用的图片存储系统TFS。

淘宝TFS文件系统在核心设计上最大的取巧在于，传统的集群系统中元数据只有1份，通常由管理节点来管
理，因而很容易成为瓶颈。

而对于淘宝网的用户来说，图片文件究竟用什么名字来保存他们并不关心，因此，TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如，图片的大小、时间、访问频次等信息，包括所在的逻辑块号。

同时研发部对搜索引擎iSearch也进行了一次升级，之前的搜索引擎是把数据分到多台机器上，但是每份数据只有一份，现在是每份数据变成多份，整个系统从一个单行的部署变成了矩阵，能够支撑更大的访问量，并且做到很高的可用性。

1.2.4 分布式时代
在这之前的时间内，淘宝的商品分类都是按照树状一级一级的节点来分的，随着商品数量的增长，类目也变得越来越深，且越来越复杂，这样，买家如果要查找一件商品，就要逐级打开类目，找商品之前要弄清商品的分类。

为解决这个问题，从系统的角度来看，淘宝建立了“属性”这样一个数据结构，由于除了类目的子节点有属性外，父节点也可能有属性，于是类目属性合起来也是一个结构化的数据对象。

淘宝把它独立出来作为一个服务，叫做Catserver。

跟类目属性密切关联的商品搜索功能独立出来，叫做Hesper。

Catserver和Hesper供淘宝的前后台系统调用。

有了类目属性，给运营工作带来了很大的便利。

Catserver还用于提供卖家授权、品牌服务、关键词等相关的服务）。

类目属性的服务化是淘宝在系统服务化方面做的第一个探索。

此时，淘宝高管提出一切要以稳定为中心，所有影响系统稳定的因素都要解决掉。

在这种要求下，淘宝这个复杂的系统进行了肢解和重构，其中复用性最高的一个模块——用户信息模块开始拆分出来，并把交易这个核心业务模块拆分出来。

原来的淘宝交易除了跟商品管理耦合在一起，还在支付宝和淘宝之间转换，跟支付宝耦合在一起。

类目属性、用户中心、交易中心，随着这些模块的逐步拆分和服务化改造，淘宝的工程师在系统架构方面也积累了不少经验。

2008年年底，淘宝所有的业务都进行了模块化。

1.2.5 中间件
服务的提供者启动时通过HSF框架向ConfigServer注册服务信息，这样
ConfigServer上面就定义了所有可供调用的服务；服务调用者启动的时候向ConfigServer注册对哪些服务感兴趣，当服务提供者的信息变化时，ConfigServer向相应的感兴趣的服务调用者推送新的服务信息列表；调用者在调用时则根据服务信息的列表直接访问相应的服务提供者，而无须经过ConfigServer。

ConfigServer并不会把服务提供者的IP地址推送给服务的调用者，HSF框架会根据负载状况来选择具体的服务器，返回结果给调用者，这不仅统一了服务调用的方式，也实现了“软负载均衡”。

在HSF的支持下，服务集群对调用者来说是“统一”的，服务之间是“隔离”的，这保证了服务的扩展性和应用的统一性。

再加上HSF本身能提供的“软负载均衡”，服务层对应用层来说就是一片“私有云”了。

HSF旨在为淘宝的应用提供一个分布式的服务框架，HSF从分布式应用层面以及统一的发布/调用方式层面为大家提供支持，从而可以很容易地开发分布式的应用以及提供或使用公用功能模块，而不用考虑分布式领域中的各种细节技术。

1.2.6 Session框架
Session在网络应用中称为“会话”，借助它可提供客户端与服务系统之间必要的交互。

因为HTTP协议本身是无状态的，所以经常需要通过Session来解决服务端和浏览器的保持状态的解决方案。

Session中存储的内容包括用户信息：昵称、用户ID、登录状态等。

解决集群Session共享的问题，通常有两种办法：（1）硬件负载：将用户请求分发到特定的服务器；（2）Session复制：将用户的Session复制到集群内所有的服务器。

这两种方法的弊端也很明显：成本较高，性能差。

当访问量增大的时候，带宽增大，而且随着机器数量的增加，网络负担成指数级上升，不具备高度可扩展性，性能随着服务器数量的增加急剧下降，而且容易引起广播风暴。

于是淘宝采用了集中式的缓存区的Session方式。

致力于解决以下问题：（1）Session的客户端存储，将Session信息存储到客户端浏览器Cookie中。

（2）实现服务端存储，减少Cookie使用，增强用户信息的安全性，避免浏览器对Cookie数量和大小的限制。

（3）Session配置统一管理起来，集中管理服务端
Session和客户端Cookie的使用情况，对Cookie的使用做有效的监管。

（4）支持动态更新，Session的配置动态更新。

1.2.7 开放平台
2006年年底：阿里巴巴提出了Workatalibaba的战略，做一个支持二次开发的工作平台，半开放式地满足各种卖家的长尾管理需求。

但经过一年的平台建设，发现开发者非常难利用平台做二次开发，抱着尝试的态度，与阿里软件合作试水开放平台。

2008年年底，平台开放淘宝服务30个，每天调用量2000次，这一年开放平台的开发者面向的客户主要是阿里巴巴上的中小企业和淘宝C店卖家。

开放平台建设初期要解决的就是三个问题：服务路由、服务接口标准化、授权。

此时两个互联网的新兴技术Memcached和Hadoop开始在开放平台中尝试。

到2009年年底，平台开放淘宝服务100多个，每天调用量为4000次，这一年开放平台的开发者面对的主要是淘宝C店卖家，卖家工具成为服务市场的主流，淘宝正式开始自己的开放之路。

到2010年年底，平台开放淘宝服务300多个，每天调用量为8亿次，这一年淘宝正式开始对外宣传开放。

1.3 总结
任何网站的发展都不是一蹴而就的，它在发展过程中会遇到各种各样的问题和业务带来的压力，正是这些问题和压力推动着技术的进步和发展，而技术的发展反过来又会促进业务的更大提升。

从个人网站到开放平台，从MySQL到Oracle，从简单的买卖到第三方担保交易，从PHP语言到Java语言，从使用技术到创造技术……在不断发展的过程中，淘宝遇到了很多问题，而不断地寻求解决方式，刻苦钻研，不轻言放弃，最终使淘宝变得越来越成功。

第2章大型云存储中心设计
2.1 引言
近年来，随着社交网络、网络新闻媒体和娱乐视频等各种信息化服务的开展产生了大量的数据，使得数据存储规模也呈现爆炸性增长。

云计算和物联网的迅速发展，越来越多的个人和企业选择将自己的业务迁移到大规模的数据中
心，以此来降低本地的硬件成本和系统维护费用。

由于数据中心存储的数据量十分庞大，管理系统的复杂性较高；从存储设备级别上看，由于数据中心为了控制成本，大量采用廉价存储设备，致使数据极易因硬件设备故障而丢失。

这些都对海量数据存储性能、可靠性等方面带来了挑战。

云存储是解决海量数据存储的最有效手段。

谷歌公司提出的MapReduce，作为一种新的编程模型，能有效地并行处理海量的数据，其采用的文件系统和数据管理模式分别是GFS和BigTable。

近些年，作为MapReduce的开源实现，Hadoop得到了企业和研究机构的广泛关注。

本章基于Hadoop平台，提出了一种云存储系统设计，并分析了实现应用系统需要实现的关键技术和管理技术，并有针对性地提出海量数据存储策略、网络存储架构、可靠性保障策略和安全保障策略。

2.2 云存储中心设计
2.2.1 Hadoop平台
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。

用户可以在不了解分布式底层细节的情况下，开发分布式程序。

充分利用集群的威力进行高速运算和存储。

在Hadoop系统中，应用程序可以并行运行在由大规模廉价硬件构成的分布式系统中。

Hadoop在内部实现了容错和扩展机制，可以构建成高可靠性和高扩展性的分布式系统。

Hadoop主要有三部分组成：HDFS(HadoopDistributed File System)、MapReduce分布式计算模型和Hbase(Hadoop Database)。

Hadoop的结构如图1所示。

图 1 Hadoop结构图
根据本平台功能设计，存储平台最主要的部分是数据处理层，而在实现数据处理层时，数据的并行加载存储模块成为了整个平台实现的核心，Hadoop分
布式技术为该平台提供了数据存储和数据处理的模型及方法。

使用Hadoop分布式文件系统存储海量源数据，通过MapReduce分布式计算模型来处理这些海量源数据，然后采用Hbase分布式数据库存储处理后的海量数据，以此来实现对海量海洋科学数据的存储管理。

2.2.1.1 Hadoop分布式文件系统
HDFS是分布式计算的存储基础，布署在廉价的硬件设备上，是Hadoop的最底层。

HDFS可以存储TB级(甚至PB级)的海量数据，并为应用程序提供高吞吐率的数据访问。

HDFS采用Master/Slave的体系结构，集群中由一个NameNode和很多个Datanode组成。

NameNode是主控服务器，管理文件系统元数据。

它执行文件系统的命名空间操作，比如打开、关闭、重命名文件或目录，还决定数据块到Datanode的映射。

Datanode存储实际的数据，负责处理客户的读写请求，依照NameNode的命令，执行数据块的创建、复制、删除等工作。

一个集群只有一个NameNode的设计大大简化了系统架构。

体系结构如图2所示：
图 2 HDFS体系结构
NameNode使用事务日志（EditLog）来记录HDFS元数据的每次变化，使用映像文件（FsImage）存储文件系统的命名空间，包括数据块到文件的映射、文件的属性等等。

事务日志和映像文件是HDFS的核心数据结构。

NameNode启动时，它将从磁盘中读取映像文件和事务日志，把事务日志的事务都应用到内存中的映像文件上，然后将新的元数据刷新到本地磁盘新的映像文件中。

HDFS还设计
有特殊的Secondary NameNode节点，辅助NameNode处理映像文件和事务日志。

它会定期从NameNode上复制映像文件和事务日志到临时目录，合并生成新的映像文件后再重新上传到NameNode，NameNode更新映像文件并清理事务日志，使得事务日志的大小始终控制在某个特定的限度下。

2.2.1.2 MapReduce编程
MapReduce就是“任务的分解与结果的汇总”。

Map把任务分解成为多个任务，Reduce把分解后多任务处理的结果汇总起来，得到最终结果。

把从HDFS中读取的待处理的海量海洋科学数据分解成许多小数据集，每一个小数据集都并行处理，处理后存储到分布式数据库。

归纳如下：数据集分割<k1,v1>map<k2,v2>combine<k2,list(v2)>reduce<k3,v3>结果输出。

计算模型如图3所示．将海量海洋科学数据分割M个片段进行并行Map操作，然后形成中间态键值对<k,value>，接着以k值进行Group操作，形成新的<k,list(value)>元组，对这些元组分割成R个片段进行并行的Reduce操作，最后输出到分布式数据库中保存起来。

MapReduce计算模型的实现是由JobTracker和TaskTracker这两类服务调度的。

JobTracker是主控服务器，只有一个，负责调度和管理TaskTracker，把Map任务和Reduce任务分配给空闲的TaskTracker，并负责监控任务的运行情况；TaskTracker是从服务，可以有多个，负责执行任务．通常MapReduce和HDFS是运行在一组相同的节点上的，即计算机点和存储节点通常在一起，方便高效地调度任务。

图 3 MapReduce计算模型
2.2.1.3 Hbase分布式数据库
Hbase是一个功能强大的分布式数据存储系统，基于列存储数据记录。

数据行有3种基本类型定义：行关键字（Row Key），时间戳（Time Stamp）和列（Column）。

每行包括一个可排序的行关键字，是数据行在表中的唯一标示。

一个可选的时间戳，每次数据操作都有一个相关联的时间戳。

某些列中可以有数据也可以没有。

列定义为：<family>：<lable>（<列族>：<标签>），通过这两部分唯一指定一个数据的存储列。

海量的数据经过MapReduce计算以后就可以按其K值作为行关键字进行分布式存储，实现存储和管理海量数据功能。

Hbase主要由主服务器、子表服务器和客户端3部分组成。

主服务器作为Hbase的中心，管理整个集群中的所有子表服务器，监控每个子表服务器的运行情况等。

子表服务器接收来自主服务器的分配的子表、处理客户端的读写请求、缓冲区回收、压缩和分割子表等功能。

客户端主要负责查找用户子表所在的子表服务器地址信息。

平台还可以整合现有的关系型数据库，通过去异构化处理共同提供海量数据存储服务。

图 4 海量数据存储和管理框架图
2.2.2 文件系统的设计
节点主要分为两部分：一种是数据节点，另外一种是非数据结点，其中系统中的主要成分都是数据节点(如图5所示的DataNode节点)，非数据节点主要指管理节点和监控节点统一由Master节点表示，如图5所示。

1）Client节点。

这个节点主要是指需要获取海量分布式文件系统数据文件的应用程序(访问客户)，可以是Web应用业务服务器(如社交网络、娱乐视频、网络虚拟银行等)，也可以是其他通过当前海量数据存储系统的访问接口进行访问的其他主机和服务器。

2）DataNode节点。

作为系统的主要构成部分，DataNode节点负责了系统正常运行的大部分任务，其中包括：数据存储、提供查询和事务处理，并且在必要时根据系统的需求提供计算能力。

其中所有Node节点之间的关系也不完全是
相同的，可以根据地域划分邻居节点和非邻居节点，一般使得同一地域内的节点都是邻居节点，基于这种设计主要考虑到系统规模可能会随着分布式数据应用不断增大，如果只有一层关系管理节点，将会变得很困难，并且在实际使用中，同一地域的节点之间的通信单价和质量都是比较好的，所以让系统的管理分为3层，一个Master以每个组的关系看待节点，而节点自己能够区分是邻居节点(同一组)还是远程节点(不同组的)。

图 5 云存储系统结构示意图
3）Master节点。

Master主要负责系统的整体状态的监控其中包括：整个系统的节点状态、提供局部数据节点的查询、保持文件块的地址信息等。

这里需要注意的是，根据系统负载能力的需求Master节点本身不一定是单个PC机器，也可能有几台机器组成一个集群共同提供服务，这样才能保证系统不会因为管理节点的瓶颈而受到限制。

2.2.3文件块存储策略及副本策略设计
在文件块存储设计时，规定每个文件块都用一个主副本，即每次每个事务处理本文件块的所有副本的更新都由主副本控制。

每个文件块除了本身包含的信息之外必须有以下控制信息块：
1）主副本所在节点编号。

每个节点在加入系统时都从Master那里得到自己的唯一编号并且和自己的地址组成一个节点编号。

2）副本个数。

副本个数包括主副本和其他副本，如果为1说明没有其他副本，如果为0说明此文件块不存在。

3）副本所在节点编号列表。

保存所有节点编号，在必要的时候可以根据这里的节点编号找到保存了副本的节点的地址和系统编号以进行访问。

在Master里面有一个根据系统的客户信息生成的一个客户编号的快照，并且有此快照构成系统文件块保存的地址信息的索引，在进行全局查询的时候，Maser就是根据这个快照表的信息进行客户信息定位的。

然后根据算法把相应的文件块的地址返回到应用服务器，让它自行直接去访问相应的节点。

Master快照表结构如表1。

表格 1 Master客户编号快照表
Master快照表中多个客户的信息有可能保存在同一文件块中，文件块出现重复是完全正常的。

除了客户快照表之外，Master还保存了另外一重要的表——文件块副本表，这个表借用了Google的Big table的思想，主要包括文件块编号表项和节点信息表项，如表2所示。

表格 2 文件块副本信息表。