云存储系统调研课件.pptx

1、 云存储系统调研2l NAS&SAN系统系统p 软硬件结合的系统p 基于特殊硬件，价格昂贵p 主要依靠特殊硬件保证性能与可靠性p 现已原生支持Hadoopp 硬件厂商设计制造p EMC、IBM、HP、Dell、NetAppl 分布式存储系统分布式存储系统p 中间件系统p 基于普通硬件，性价比高p 主要依靠集群扩展保证性能与可靠性p 互联网公司&开源项目p Google、亚马逊、雅虎、Facebook、淘宝、人人网3l 分布式分布式存储系统存储系统p 企业内部系统企业内部系统（GFS、Dynamo、Nuclear等），用以支持企业的各种前端业务系统。p 开放开放云存储服务云存储服务（S3、阿里云

2、、Dropbox、金山快盘等），开发者可基于其进行应用与系统开发，专心于业务逻辑。p 开开源源项目项目（Hadoop、FastDFS、OpenStack、Ceph等）。l 架构分类架构分类 中心化中心化架构架构 对称对称架构架构4l Master/Slave架构架构l 典型系统典型系统p GFS（Google）HDFS（雅虎）p CloudStore MooseFSp GfarmPNFS p PVFSOrangeFSp Lustre（SUN）p MapRp TFS（淘宝）p FastDFS5l 去去中心化中心化架构架构l 典型典型系统系统p Dynamo（亚马逊）S3（亚马逊）p Cassan

3、dra（Facebook）Voldemort（Linkedin)p Nuclear（人人网）beansDB（豆瓣）p Swift（OpenStack）p Ceph（源于高校科研项目）p Tair（淘宝）p GlusterFS6l 中心化架构中心化架构p HDFS（雅虎）p TFS（淘宝）p FastDFSl 对称架构对称架构p Dynamo（亚马逊）p Swift（OpenStack）p Ceph（源于高校科研项目）p Tair（淘宝）p GlusterFS7 调研总结调研总结8l 每个流行每个流行的云存储系统都的云存储系统都有自己的有自己的侧重点侧重点l 可选的架构很多，关键是要针对可选的架

4、构很多，关键是要针对特定的应用特定的应用场景场景p 系统规模大小p 业务类型与压力p 实时/非实时p 大文件/中等文件/小文件p 连续读写/随机读写p 吞吐率/低延迟p 强一致性/弱一致性p 性能&可靠性p 扩展性&单节点问题p 是否要求目录结构p 可配置&快速部署p 大数据离线/在线分析p 电子商务p 社交网络p 网络硬盘p 邮件服务p 图片服务p 语音视频服务p 虚拟机调度与镜像存储p 开放云存储平台9l 离线型数据分析系统离线型数据分析系统p 数据总量大，单个文件大，更注重系统吞吐率，而非低延迟。p 为适应流行的MapReduce模型，需要文件分块，并配合上层逻辑，采用大块顺序读写的方式

5、提升性能。l 线上服务系统线上服务系统p 根据服务类型而采用差异化的存储方式。p 针对语音视频等大文件大文件，可能会采用与离线系统相同的方式，文件分块顺序读写，从而达到更高的传输速度。由于文件数量相对较少，有可能完全实现传统文件系统的目录结构与权限等功能。p 电子商务、社交网络等应用场景，多为小文件小文件（小图片与小视频、记录与评价信息等），文件数量庞大，增长快速，用户基数大，实时性要求高，读写随机性强，对性能与扩展性的要求很高。10应用场景应用场景可行系统可行系统大数据离线大数据离线/在线分析在线分析HDFS、Swift、GlusterFS电子商务电子商务TFS、FastDFS、Dynamo

6、、Swift、Tair社交网络社交网络TFS、FastDFS、Dynamo、Swift、Tair网络硬盘网络硬盘HDFS、FastDFS、Swift、GlusterFS邮件服务邮件服务TFS、FastDFS、Dynamo、Swift、Tair图片服务图片服务TFS、FastDFS、Dynamo、Swift、Tair语音视频服务语音视频服务HDFS、FastDFS、Swift、GlusterFS虚拟机调度虚拟机调度和镜像存储和镜像存储HDFS、Swift、GlusterFS11l 不同的应用场景，不同的性能考量，不同的存储架构，似乎似乎没有一种通没有一种通用的方法解决所用的方法解决所有问题有问题

7、，一切都应取决于支撑的业务需求是怎么样的。相对于专用系统，通用系统难以达到预期的效果，同时增加了开发和调优方面的复杂性。l 中心化架构与对称架构并不是完全对立的，两者都可能存储大文件和小文件，区别只是相对而言的。在大数据存储、分析领域在大数据存储、分析领域，中心化架构较多，HDFS仍然被广泛使用或模仿。而在互联网应用中而在互联网应用中（电子商务、社交网络、APP），以中小文件的存储为主，对称架构较多，Dynamo和BigTable的设计理念被广泛地参考。l 大多数系统都抛弃了目录结构。因为目录树的开销非常大，去掉之后，集群的性能和扩展性被极大地提高。l 疑惑在于，像阿里云这种开放云存储服务，如

8、何同时解决大文件和小文件的存储需求。12l 云存储系统的架构大同小异架构大同小异，成功的关键在于细节：操作系统级优化、文件系统级优化、优秀的代码实现、稳定性l 关注个性化关注个性化：p 策略、代码和性能的优化。p 数据分布方案&副本分布方案，文件去重。p 模块化&插件化，可热拔插&动态替换。p 抽象的存储引擎层，灵活地切换持久化存储或缓存。p 融合SSD与机械硬盘，权衡性能与成本。p 底层文件系统的选择与优化。p 文件分块/聚合，增量同步，标准化接口（RESTfull、POSIX）。p 系统部署与扩展的便捷性，自动化程度。l 分布式环境下特别需要关注一致性问题一致性问题，权衡性能与一致性等级。

9、并发操作、各种版本冲突、机器故障、机器恢复、数据迁移与用户访问并存集群状态不断变化，如何确保一致性约束。Thank You!14 HDFS雅虎，开源雅虎，开源（中心化架构）（中心化架构）15HDFS是Mater/Slave架构，集群包含一个NameNode和多个DataNode。从最终用户的角度来看，它和传统的文件系统一样，可以通过目录路径目录路径对文件执行CRUD（Create、Read、Update和Delete）操作。l NameNode是主服务器（单节点）是主服务器（单节点）p 维护系统命名空间，管理目录树结构的元数据，提供文件目录操作；负责权限管理、集群管理、副本策略、故障检测与恢复

10、等。p 所有客户端请求都要经过所有客户端请求都要经过NameNode处理处理。l DataNode是存储结点是存储结点（可扩展（可扩展）p 管理磁盘存储空间；处理来自用户的文件读写请求；执行块创建、删除以及来自NameNode的操作命令（如复制、传输、迁移）。l HDFS被设计用来可靠地保存大文件被设计用来可靠地保存大文件1617l NameNode磁盘上包含两个重要的持久化文件：FsImage和EditLog。FsImage是内存中元数据的磁盘镜像，EditLog是元数据修改操作的日志。默认将所有元数据缓存在内存中。l 运行中将元数据修改操作写入EditLog日志，并周期性地将内存中元数据存

11、储到FsImage中，正常关闭系统前会刷新FsImage。l 正常启动时，将FsImage中的元数据加载到内存中。若系统崩溃或异常关闭，则FsImage可能并未被刷新，所以加载完FsImage后需要检查EditLog日志，并更新相应操作。l 面向大文件面向大文件，其元数据量有限其元数据量有限；充分利用内存的高性能充分利用内存的高性能。18HDFS架构分类架构分类中心化架构，重量级的Master（热备）；数据分布策略数据分布策略Master采用目录树结构集中管理元数据（镜像文件+日志）；目录结构支持目录结构支持支持完整的目录结构与操作（修改目录文件名时无需迁移）；单节点问题单节点问题Master

12、存在单节点问题（内存限制、性能瓶颈、单点故障）；一致性一致性强一致性，Master集中管理，实现同步操作；扩展性扩展性Master不可扩展，Slave扩展性较好，扩展时无需数据迁移；适用场景适用场景大数据存储（总量可达PB级，单个文件较大，元数据个数有限）；大文件分块存储，并发连续读写，适合MapReduce；流式访问，高延迟，高数据吞吐量；其他其他不适合海量小文件存储；不适合小文件随机读写；目前仍是传统并行计算中的主流，被许多系统借鉴；19 TFS淘宝，开源淘宝，开源（中心化架构）（中心化架构）20TFS（Taobao FileSystem）是一个高可扩展、高可用、高性能、面向互联网服务的分

13、布式文件系统，主要针对海量的非结构化数据。TFS借鉴了GFS与HDFS的设计理念，在架构上存在很多相似点。它同样采用了Mater/Slave结构，同时又根据自身业务特点（海量小文件存储海量小文件存储）进行改进。21l 业务背景业务背景p 为淘宝各项应用提供海量小文件存储海量小文件存储，文件大小通常不超过1MB。p 主要存储淘宝网的图片、描述信息、交易快照等内容。p 用户对目录结构和文件名服务没有需求。p 800+台服务器，PB级数据量，百亿数据级别，150+种应用。l 业务需求业务需求p 文件小文件小，并发并发量量高高，读读操作远大于写操作远大于写操作操作。p 访问随机，几乎没有几乎没有文件文

14、件修改操作修改操作。p 考虑到成本和备份，需要用廉价的存储设备。p 考虑到容灾，需要能平滑扩容。22l 面向海量小文件存储，采用适合小文件的存储方案。l 改变元数据管理方案，划分两级元数据，简化内容，并全部缓存。l 扁平化的数据组织结构，抛弃传统文件系统的目录结构。l 采用EXT4文件系统，减少EXT3中数据碎片的性能损耗。l 单进程管理单块磁盘，摒除RAID5机制。l 带有HA机制（热备）的中心节点，在稳定和性能之间取得平衡。l 跨机架和IDC的负载均衡与冗余安全策略。l 完全平滑扩容。l 无文件数据缓存，由前端系统负责数据缓存。l 最新版的TFS开始支持大文件存储、文件去重、目录结构。23

15、l TFS集群由两个NameServer(NS)节点（热备）、多个DataServer(DS)节点以及一个AdminServer(AS)节点组成。l TFS将许多小文件合并成为一个大文件，称为块（块（Block），每个Block拥有集群内唯一的编号（Block ID）。NS在创建Block时分配Block ID，并维护所有Block与DS的对应关系，即一级元数据一级元数据。Block的实际数据存储在DS上，DS会维护本机所有Block与小文件的对应关系，即二级二级元数据元数据。分级元数据机制使得TFS能支持非常庞大的元数据量。l NS负责集群管理与维护，包括DS心跳信息，DS加入/退出，建立/

16、解除Block与DS的对应关系，管理Block的创建、删除、复制、均衡。NS不负责实际数据的存储和读写。l DS负责实际数据的存储和读写，管理Block与小文件的对应关系，向NS发送心跳信息（报告自己的Block列表及机器状态），接受NS的管理操作指令。24l AS作为系统管理工具，通过与两个NS的通信来监控并向工作人员报告集群的运行状态。当主NS宕机时，AS迅速将备用NS切换为主机，继续对外提供服务。25l TFS以Block的方式进行文件存储，Block大小可以配置项，通常设为64MB，每个Block中中会存储会存储许多小许多小文件文件。l DS会给Block中的每个小文件分配一个编号（F

17、ile ID，在每个Block中唯一），然后将本机所有Block与File的对应关系（二级元数据）缓存在内存中，并持久化到磁盘上。l 每个Block都存储在多个DS中以保证数据的冗余。TFS的备份是基于Block的，同一个Block的多个副本具有一致的多个副本具有一致的Block ID。Block（Info）Block（Info）Block（Info）Block（Info）Block（Info）File（info）File（info）File（info）26l NS维护着Block与DS的对应关系（一级元数据），包括Block完整列表、可写Block列表、DS列表、修改中的Block列表。l

18、支持支持多个用户并发读并发读同一个文件，不支持不支持多个用户并发并发写写同一个文件。l 即一个Block同时只能有一个写或者更新操作。（强一致性约束强一致性约束）27l TFS文件名的最大长度为18字节，固定以T开头，第2字节为集群编号(取值范围19)，余下的由Block ID和File ID通过一定的编码方式得到。文件名文件名由由Client进行进行编码和编码和解码解码。l Client读文件时将文件名转换为Block ID和File ID信息，然后在NS处取得该Block所在DS的信息（若Client已缓存缓存，则直接从缓存中取），然后与DS进行交互。28l 读文件读文件1.Client从

19、文件名中解析出Block ID和File ID。2.然后向NS发送查询请求（Block ID），得到Block所在的DS地址。3.最后将Block ID、File ID和offset信息发送到指定的DS，DS会查询二级元数据，得到Block文件和File在Block中的偏移量，并根据offset信息将到正确的文件内容返回给Client。l 写文件写文件1.Client向NS发起写请求。NS根据DS负载情况在可写Block列表中选择一个Block，并在其多副本中选择一个DS作为写入写入的的Master（根据DS负载和作为Master的次数），每个Block的Master一旦选定就不再改变。NS返

20、回Block ID和一个DS列表（用于保存多个副本）。2.Client向Master DS发送Block ID，请求写入数据。Master DS在Block中分配File ID并将数据写入相应位置，然后将数据发给其他DS，只有当只有当所有所有DS写入成功写入成功后后，Master DS才才会会向向NS和和Client返回返回操操作成功的信息作成功的信息。最后Client进行文件名编码。29l NS与DS之间使用心跳机制心跳机制通信，扩容时只需启动新的DS即可，NS通过心跳信息得知新的DS加入集群。l 在集群负载较轻时，NS会对DS上的Block进行再均衡再均衡，使所有DS的容量尽早达到平衡。均

21、衡时，计算每台DS中Block的平均数量，然后将机器分为两堆，超过平均数的作为移动源；低于平均数的作为移动目的。l Block的迁移需遵循一定的规则，移动源和目的的选择过程较为复杂。p 保证Block的副本被不同的DS进程管理。p 保证Block的副本存储在不同的机器上。p 保证Block的副本存储在不同的机柜、数据中心上。p 保证Block的副本存储在不同的子网段内。30l 集群集群容错容错p 主主/辅辅集群集群，一般会在两个不同的机房中。主集群提供所有功能，辅集群只可读，主集群会把所有写操作更新到辅集群上。主集群故障时，辅集群可接替其工作，同时也提供了负载均衡。l NameServer容错

22、容错p NS采用HA机制机制，一主一备，主NS会把所有写操作更新到备NS上。如果主NS出现问题，可以实时切换到备NS。p DS可以通过心跳信息把自己拥有的Block信息发送给NS，NS可根据这些信息重建Block与DS之间的关系。l DataServer容错容错p Block会保存多份，一般为3份，且分布在跨网段、跨机柜、跨数据中心的不同DS上。所有所有Block副本副本写入成功后写请求才写入成功后写请求才算成功算成功。DS宕机时TFS会启动复制流程。此外，TFS记录每个文件的校验CRC，当Client发现CRC和文件内容不匹配时，会切换到其他副本，并通知DS修复那个损坏的副本。31l 传统集

23、群系统中的元数据只有1份，由中心节点来管理，易成为瓶颈。对淘宝的用户来说，实际上并不关心图片文件用什么并不关心图片文件用什么名字保存名字保存。因此，TFS在实际图片文件的文件名中加入部分元数据信息，如大小、时间、访问频次等。这使得两级元数据的结构内容非常简单，单个元数据占用的字节数也很少，从而两级元数据能够全部缓存。l 由于大量的元数据信息隐藏在文件名中，所以TFS完全抛弃了传统的目完全抛弃了传统的目录树结构录树结构。目录树的开销非常大，去掉之后，集群的性能和扩展性被极大地提高。l 为了提升访问速度并减少碎片产生，DS目前在EXT4文件系统文件系统上运行。每个Block在文件系统上可能会由多个

24、实际的物理文件组成，包括1个主主块块和N个扩展扩展块块（主块的大小会远大于扩展块），扩展块是为了满足文件更新操作时文件大小的变化。l 通常一台服务器上会运行多个DS进程，每个进程管理一块硬盘，由应用层实现数据冗余，而不使用RAID5。RAID卡的工作原理导致无法优化TFS注重的随机I/O特性。32l 淘宝的部署环境中，前端有两层缓存系统，到达TFS的请求在时间上非请求在时间上非常常离散而平均离散而平均，所以TFS内部没有任何文件数据缓存。l TFS前端包括一级缓存（整体系统中心点）、二级缓存（各运营商中心点）、图片文件服务器（用于生成缩略图的运算）。33l TFS通过增加一个独立的集群来提供目

25、录结构和自定义文件名服务，同时支持大文件存储。l 新增ResourceCenterServer。多集群互备时，Client只需在RcServer中注册，RcServer会根据Client地址选择离它较近的集群以供访问。34TFS架构分类架构分类中心化架构，重量级的Master（热备）；数据分布策略数据分布策略两级元数据结构，分别由Master和Slave管理，并全部缓存；目录结构支持目录结构支持不支持目录结构；单节点问题单节点问题Master存在单节点问题（性能瓶颈、单点故障、内存限制问题较小）；一致性一致性强一致性，Master进行协调管理；为Block选定写入操作的主Slave，写请求要求

26、所有副本均写成功；扩展性扩展性Master不可扩展，Slave扩展性较好，扩展时无需数据迁移，支持再均衡；适用场景适用场景海量小文件存储；访问随机，读操作远多于写操作，几乎没有文件修改操作；其他其他在实际文件的文件名中保存部分元数据信息；Block机制，小文件合并存储；采用适合Block机制的EXT4文件系统；单进程管理单块磁盘，而不采用RAID5；35 FastDFS开源开源（中心化中心化架构）架构）36FastDFS是一款开源的分布式文件系统，它是为互联网应为互联网应用量身定做用量身定做的，特别适合以文件为载体的在线服务，如相册网站、视频网站等。它充分考虑了冗余备份、负载均衡、线性扩容等机

27、制，并注重简介、高可用、高性能等指标。它借鉴了GFS的设计，同时对架构和设计理念有独到的见解，主要体现在轻量级轻量级、分组分组存储存储、对等性对等性三个方面。有人这样评价：“FastDFS是穷人的解决方案是穷人的解决方案”。意在表明FastDFS把简洁和高效做到了极致，非常节约资源，中小网站完全用得起，这是对FastDFS的极大认可和褒奖。37FastDFS集群中包含两种角色：Tracker Server(TS，跟踪，跟踪器器)和Storage Server(SS，存储节点，存储节点)。l TS和SS分别是两个小集群。l TS负责调度与定位的工作，并起到负载均衡的作用。l SS负责文件的存储、

28、管理、同步等功能，并提供文件读写接口。38l FastDFS采用分组存储分组存储。集群由多个组构成，每个组由多台SS组成，同组内的SS之间是完全的互备关系，不同组的SS存储着不同的文件。同组内的SS之间会进行文件同步，不同组的SS之间不会相互通信。l 动态分配副本位置的方式使得逻辑上复杂而不易管理。分组存储的优点是灵活灵活、可控性强可控性强。组内增加SS可提升读服务能力（纵向扩容）；增加新分组可扩充存储总容量（横向扩容）。39l 各个TS之间是相互独立的，不存在直接联系。l SS会定时地向集群中所有的TS报告其状态信息（即心跳信息心跳信息），包括磁盘剩余空间、文件同步状况、文件上传下载次数等。

29、一个分组内包含哪些SS不是由配置文件设定的，而是从TS中获取的。l 其实FastDFS完全中没有元数据的概念没有元数据的概念，TS不会记录文件索引信息，只在内存中记录分组和SS的状态等信息，因而占用的内存很少。Client和SS访问TS时，TS扫描内存中的分组和SS信息，然后给出应答。l 可以通过文件上传与下载的交互过程来理解TS的集群化和轻量级。40l 文件上传流程文件上传流程1.Client向TS请求空闲的SS。2.TS返回一台可用的SS，返回数据为该SS的IP和端口。3.Client与该SS建立连接，进行文件上传，SS返回新生成的文件ID，文件上传结束。文件文件ID包含分组包含分组名、文

30、件相对路径和名、文件相对路径和文件名文件名。41l 文件下载流程文件下载流程1.Client向TS发送发送文件文件ID信息信息（包含分组名和文件名），请求可以下载文件的SS。2.TS返回该分组内一台可用的SS。3.Client与该SS建立连接，完成文件下载。42l FastDFS集群中的TS可以有多台，TS和SS均不存在单点问题。l TS之间是对等关系，每个分组内的SS之间也是对等关系。43l FastDFS不会对文件进行分块存储不会对文件进行分块存储，Client上传的文件和SS中存储的文件是一一对应的。l 基于如下考虑：多数网站需要存储用户上传的文件，如图片、视频、电子文档等。出于降低带宽

31、和存储成本的考虑，网站通常会限制上传文件的大小，如图片不超过5MB、视频不超过100MB等。对于多数互联网应用，文件分块存储没有太大的必要。它没有带来多少好处，却增加了系统的复杂性。FastDFS不对文件进行分块存储，显得更加简洁高效，并且完全能够满足绝大多数互联网应用的实际需要。l 在无文件分块的情况下，其支持的文件大小有限，且不支持多个分块的多线程上传下载，对性能有所影响。但考虑到目前的互联网带宽普遍较低，并结合互联网应用的实际需求，这是一种折中而有意义的做法。44l 副本同步只在同组内的SS之间进行，采用采用push方式方式，即源服务器同步给目标服务器。l SS中采用binlog日志文件

32、记录文件上传、删除等更新操作，并由专门的线程根据binlog进行副本同步。为了最大程度地避免相互影响，以及出于系统简洁性考虑，SS会为分组内除自己以外的每台服务器启动一个线程，来进行副本同步。l 副本同步采用增量同步方式，其实就是会自动检查，同步那些存在更新操作，但未被同步的文件，并不是文件内部的增量同步（即同步文件中被修改的内容）。45l Client上传文件时只写入一台SS，之后由该SS根据binlog中的记录将文件同步到同组的其他SS。这种异步的副本同步方式异步的副本同步方式带来了同步延迟问题。上传文件后，若Client向未被同步的SS请求该文件，就无法找到。Client写入写入读取读取

33、未未同同步步46l 对于已上传的文件，访问请求分为两种：文件更新文件更新与文件文件下载下载。文件更新包括设置文件附加属性（如大小、图片宽度与高度）和删除文件。l 在FastDFS中，文件更新文件更新操作都会优先选择操作都会优先选择源源SS（即上传时写入的那台SS）。这不仅避免了副本同步延迟问题，而且有效地避免了在多台SS上更新同一文件可能引起的时序错乱问题。为此，SS生成的文件ID中包含了源SS的IP（或编号）和文件时间戳，从而TS能够将源SS的地址返回给Client。Client写入写入更新更新47l 为了解决文件下载操作中的同步延迟问题下载操作中的同步延迟问题，TS需要准确地知道一个文件是

34、否已经被同步到另一台SS上。由于采用了分组存储，同时SS之间的副本同步使用推送方式，且每台SS都会定时地向TS发送心跳信息。所以，FastDFS采用了时间戳同步策略时间戳同步策略来确认副本同步状况。l 源SS会按照时间戳从小到大的顺序推送副本；目标SS接收副本后，会分别记录来自每个源SS的副本的最大时间戳，然后通过心跳信息发给TS。于是TS能够知道每台SS已被同步到什么程度（以时间戳衡量）。SS1SS2心跳信息心跳信息文件A时间戳100文件B时间戳200文件C时间戳300文件D时间戳400文件A时间戳100文件B时间戳200副本同步副本同步TS已同步的已同步的SS1已向已向SS2同步到时间戳同

35、步到时间戳200记录来自记录来自SS1的时间戳的时间戳20048l 面对下载操作中的问题，FastDFS提供了两种解决方案。p 最简单的解决方案和文件更新一样，优先选择选择源源SS下载下载即可。p 另一种复杂而均衡的方案是轮流选择轮流选择（Round-Robin），Clien向TS请求可供下载的SS，TS在某个组内的SS中轮流选择，只要发现满足下列条件之一的SS，就立即返回：1.此SS是存储该文件的源SS。2.此SS记录的来自源SS的时间戳大于该文件的时间戳，表示已完成副本同步。3.当前时间-该文件的时间戳（即创建时间）副本同步延迟阈值（例如把阈值设为1天，表示副本同步在一天内肯定完成）。49

36、FastDFS架构分类架构分类中心化架构，可扩展的多Master设计；数据分布策略数据分布策略无元数据，非Hash分布；采用分组存储方式，Master记录Slave及分组信息，并负责负载均衡；通过Slave生成的文件ID来定位数据；目录结构支持目录结构支持不支持目录结构；单节点问题单节点问题Master不存在单点问题，多Master结构，可扩展；一致性一致性强一致性，特有的副本同步策略；扩展性扩展性Master和Slave都具有良好的扩展性，扩展时无需数据迁移；适用场景适用场景海量中小数据的存储；可满足大多数互联网应用的需求；其他其他不适合超大文件存储，不支持文件分块；无元数据，轻量级的Mas

37、ter；对Slave分组，简单清晰的副本规则；优秀的副本同步延迟解决方案；50 Dynamo亚马逊亚马逊（对称对称架构）架构）51Dynamo是亚马逊开发的分布式存储技术，用以实现一个高性能、高可扩展、高可用的Key-Value结构存储系统。该技术旨在权衡成本、一致性、可靠性和性能，l Dynamo不直接作为Web服务暴露给外部，而是用于支撑亚马逊的业务系统。l 亚马逊发表了Dynamo的论文后，引起了很多人的关注，出现了许多基于其设计理念的开源/非开源项目。例如Facebook 开发的Cassandra，Linkedin的Voldemort，人人网的Nuclear，豆瓣的beansDB。l

38、OpenStack中的Swift存储系统也借鉴了部分Dynamo的思想。l Dynamo并未开源，且其论文以描述思想为主，对外界来说，它更像一一种值得学习的设计理念种值得学习的设计理念，而不是完整的系统平台。52l 作为全球性的电子商务服务平台，亚马逊使用分布于世界各地分布于世界各地的成千上万台服务器为数千万客户提供稳定的服务，要求永远可用。l 亚马逊有着严格的性能性能和可靠性可靠性要求，重视客户体验，要求可控的性能边界，同时即使最轻微的系统中断都有显著的经济后果。此外，为了支持业务持续增长，平台需要具有高度可可扩展性扩展性。l 在一个由数百万个组件组成的基础设施中，在任何时段，总会有相当数量

39、的服务器和网络组件故障，因此亚马逊的系统需要将故障处理故障处理当作常态化事件，并且不影响可用性和性能。l 亚马逊平台中的许多服务只需要通过主主键访问键访问数据，且多为小数据（小数据（1MB以下）以下），如提供最畅销书排行榜、购物车、客户偏好、会话管理、销售等级、产品目录。传统的关系型数据库在性能、可靠性和扩展性上存在明显不足。53l 完全对称架构，Key-Value结构的分布式存储系统。l 面向海量小数据的存储，大多不超过1MB。l 可控的性能边界，高负载下99.9%的请求响应时间低于300毫秒。l 面向高可用性，永远可写，只提供弱一致性，即最终一致性。l 不提供任何数据隔离保证，只允许单一的

40、关键字更新。l 采用基于Http协议的用户接口，RESTfull接口。l 支持用户级别的副本数配置、性能与可靠性权衡、版本冲突解决。l 提出了一系列设计理念，包括：p 基于一致性哈希、虚拟节点和分区技术的数据分布方案。p NRW策略，向量时钟，仲裁协议。p Hinted Handoff临时故障处理策略。p 基于Merkle树的副本同步。p 基于Gossip的成员和故障检测协议。54l Dynamo中，每个存储节点有三个主要的软件组件：p 协调组件协调组件：管理分布式策略，执行请求转发、数据读写、复制迁移。p 检测组件检测组件：检测集群故障和成员变化，配合协调组件工作。p 持久化组件持久化组件：

41、负责本地持久化存储，支持多种存储引擎，可热拔插。协调组件协调组件检测组件检测组件用户用户请求请求转发转发产生副本产生副本持久化组件持久化组件55l Dynamo使用一致性哈希算法一致性哈希算法将数据均衡分布到多个节点。所有物理节点（存储服务器）被放到一个圆环上，数据根据Key被Hash上去。l 结合虚拟节点技术虚拟节点技术后，为每个物理节点分配N个虚拟节点，然后将虚拟节点放到圆环上。p 负载更均衡。并且考虑到机器的性能差异，物理节点分配的虚拟节点数可根据其处理能力来决定。p 物理节点故障/维护时，其负载被均匀地分散到剩余的可用节点。p 加入新物理节点（或原节点恢复）时，新的可用节点均衡地分担其

42、他节点的负载（包括数据迁移）。数据数据虚拟虚拟节点节点56l 为了获得最佳的负载均衡，亚马逊在一致性哈希的基础上，通过实验分析了三种数据分区策略数据分区策略：p Strategy 1：虚拟节点随机分布，由相邻节点划分区域。p Strategy 2（最差）：虚拟节点随机分布，但区域等分。p Strategy 3（最佳）（最佳）：区域等分，每个虚拟节点管理一个区域。57l Dynamo会将数据复制到多台主机上（副本数N可配置）。数据被发送到首选节点后，该节点除了在本地存储外，其协调组件会将该数据复制到环上顺时针方向的N-1后继节点后继节点。58l 每个物理节点上都有协调组件，掌握集群的分布式情况。

43、加入新的物理节点时，采用均衡随机替换均衡随机替换的方式更新数据分布情况。新节点的虚拟节点会均衡地替换原节点的部分虚拟节点，原节点通过本地的协调组件向新节点迁移数据。59l 为了在并发访问过程中保持副本一致性，Dynamo使用仲裁协议仲裁协议来达到一致性。该协议需要用到NRW策略策略：p N表示数据副本数。p R表示读操作中必须参加的节点数。p W表示写操作中必须参加的节点数。l 经典配置项为：R+WN，N=3，R=2，W=2：数据有3个副本；读操作时必须能读到2个副本，否则失败；写操作时必须写入2个副本才算成功，否则失败。每次写入2个能保证2/3的副本是一致的，若另一个副本不一致，则其为旧数据

44、。读操作会读取2个副本，则一定会读到新数据。当遇到不一致时，可以采取系统内定的仲裁协议系统内定的仲裁协议，或者由用户在客户端自定义仲裁方式自定义仲裁方式，进行版本替换或合并，然后提交到集群中。l R越小读取越快，但存在版本冲突；W越小写入越快，但可靠性降低。l 此模型中，读操作的延时是由最慢的R副本决定的；写操作的延时是由最慢的W副本决定的。60l 仅有NRW策略还不足以完成仲裁协议，仲裁过程中的版本替换或合并需要有一定的依据，Dynamo将向量时钟向量时钟作为其依据。每个节点都会为数据记录本地修改版本。看似美好，实则复杂混乱。看似美好，实则复杂混乱。l 由于Dynamo的冲突合并过于复杂，后

45、来的系统（Cassandra、S3）都倾向于采用Last-write wins，即根据更新时间戳来自动处理冲突。61l Dynamo的仲裁协议遇到服务器或网络故障时（如无法成功写入两个副本），会降低系统的可用性降低系统的可用性，大量读写操作被拒绝。l 例如某数据的3个副本应该被放在B、C、D上，但写操作时发现无法连接B和C，Dynamo会在D上写入副本，然后将本属于将本属于B的副本发送到的副本发送到E。这就提高了系统的可用性和耐用性。发送到E的副本会包含一个包含一个暗示暗示，表明哪个节点才是在该副本预期的接收者（B）。E会将这种数据保存在一个单独的目录下，并定期扫描，在检测发现B恢复后，会尝试

46、将副本发给B。发送成功后，E可将暂放在本地的该数据删除。62l 为了更快地检测副本间的不一致，减少数据传输量，Dynamo采用基于基于Merkle树的副本同步树的副本同步。Merkle树的叶节点是各个文件的Hash值或MD5值，父节点值是由其所有子节点值计算出来的。优点是树的每个分支可独立检查，不需要下载整棵树。若两棵树的根值相等，则表示叶节点值都相等，不需要副本同步；若根值不相等，就意味着有些副本不同步，此时交换子节点值，直到叶节点，便可识别出不同步的副本。物理节点会为自己负责的每个每个分区分别建立分区分别建立一颗一颗Merkle树树。63l 为避免短暂故障和人工错误引起集群分区再平衡（即数

47、据迁移），Dynamo使用明确使用明确的机制来发起节点的增加的机制来发起节点的增加和移除和移除。l 管理员使用命令行工具或浏览器连接到一个节点，发出成员改变指令。该节点更新本地记录的数据分布情况，然后基于Gossip协议传播成员变动消息。每个节点每间隔一秒随机选择某个对等节点，告知其成员变动消息，类似于流言的传播。l 同时加入节点A和B，一段时间内（传播过程中），A和B可能互相不知道对方的存在，造成逻辑分裂逻辑分裂。于是需要种子节点。种子通过外部机制实现（配置文件中指定种子节点IP，或者实现动态配置服务）。所有节点都知道种子节点的存在，最终都会和种子节点协调成员关系。l 故障检测采用懒惰懒惰策

48、略策略。例如随着客户端的请求，节点A会发现节点B不响应，于是A向B的备用节点（分区级别的副本节点）请求服务，并定期检查B是否恢复。若没有客户端请求推动两个节点之间的通信，双方并不需要知道对方是否可以访问。64l 服务器驱动协调服务器驱动协调p 客户端的请求通过前端负载均衡器之后，均匀地落在集群中的节点上，节点会通过协调组件将请求转发到存储该数据的节点上。l 客户端驱动协调客户端驱动协调p 客户端在本地建立协调组件，定期（可能导致本地数据陈旧）选取一个随机节点，从中获取当前的集群状态和数据分布情况。于是，客户端就能在本地完成读操作协调，直接访问存储该数据的节点，从而避避免了额外一跳的网络免了额外

49、一跳的网络开销开销。若未使用基于时间戳的版本机制，写操作仍需要使用服务器驱动协调，来保证并发修改时的一致性。单位：ms 99%读延时 99%写延时 平均读延时 平均写延时65l 为确保后台任务（副本复制、迁移等）不会显著影响正常的关键操作（用户读写请求），所有后台任务都具备管理控制管理控制机制机制。采用一个基于前台任务监控的反馈机制来控制后台任务的可用时间片和资源。l 管理控制器不断监测前台任务对资源的访问行为，监测数据包括磁盘操作延时、数据库访问延时、请求队列等待时间等。然后将监测数据与预设阀值进行比较，从而评估资源的可用性。例如预设阀值认为99%的数据库访问延时应在50毫秒以下，而当前99

50、%的延迟在60秒以下，则表示资源压力较大，不宜启动后台任务。l 随后，管理控制器决定将多少时间片和资源提供给后台任务。66Dynamo架构分类架构分类完全对称架构，Key-Value数据结构，无传统意义上的Master；元数据管理元数据管理基于一致性哈希、虚拟节点和分区技术的数据分布方案；目录结构支持目录结构支持不支持目录结构；单节点问题单节点问题不存在单节点问题；一致性一致性弱一致性，最终一致性，一致性方案复杂而混乱；扩展性扩展性极强的扩展性，扩展时需要数据迁移；适用场景适用场景海量小文件存储，如Amazon的购物车数据；高度可写可读性，可控的性能边界，支持并发修改冲突的协调；其他其他不适合