- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
* 在数据被充分的传播到所有的存放节点之前返回给用户的仍是原数据 要想构建一个灵活且可扩展的系统,低耦合度是很有必要的。因为只有系统各个组件之间的关联度尽可能低才可以根据系统需要随时从系统中增加或者删除某些组件。但松散的耦合度也带来了组建之间的通信问题,如何实现安全、高效的通信是设计一个低耦合度的分布式系统所必须考虑的问题。简单队列服务(Simple Queue Service,以下简称SQS)是亚马逊为了解决其云计算平台之间不同组件的通信而专门设计开发的 * * * * * * * Cassandra Gossip通讯 Gossip 协议主要用来管理集群信息 还用来管理各种系统状态. 每个节点的状态以及其他节点的活动状态等. 通讯效率非常高,只需要Log(N)回合就可以将状态传递给集群的N个节点 每隔T秒,每个节点都会自增自己的Heartbeat信息并通过Gossip传递给其他节点 Cassandra Gossip通讯 Gossip-初始状态 Cassandra Gossip通讯 Gossip-第一回合 Cassandra Gossip通讯 Gossip-第二回合 Cassandra Gossip通讯 Gossip-第三回合 Cassandra Gossip通讯 Gossip-第四回合 故障检测 Cassandra使用Accrual 故障检测器 在系统管理,复制,负载均衡等领域应用广泛 它的输出值为一个数值(Phi, Φ),表示此节点面临故障的可疑级别 它也被称为自适应故障检测器,可根据网络环境做自适应调整 应用设置相应的Phi值,触发可疑节点并做针对性的处理 在Cassandra中,默认的Phi值为5,检测到故障的时间在10-15秒 具体设置的Phi值表明达到这个可疑级别的节点被认为已经出现故障 * * Jeff Barr认为,云计算是分层次和类别的,每一类公司提供的云计算的服务都不一样,亚马逊是IT基础架构云计算服务提供商。在网络互联的需求之上,直接就是亚马逊的最底层的IT基础架构AWS(Amazon Web Services),包括计算、存储、内容分发等;在AWS的基础上,用户才可以构建自己的应用层,这些应用层包括构建数据库、应用服务器;最上一层才是应用软件。他表示,目前市场上很多云计算服务提供商所提供的服务,仅仅是不同层面的一部分解决方案。 * * * 完成数据迁移后,由于不需再考虑基础设施问题,SmugMug将公司的主要精力集中在提高服务质量上。目前SmugMug向用户提供了三种照片访问方式[35]: SmugMug以代理的身份处理用户访问请求 SmugMug对用户访问请求进行重定向 利用有关API直接对存储在S3中的数据进行访问。 在这三种访问方式中,以第一种方式访问的用户超过99%。也就是说几乎所有的用户都选择这种访问方式,这也正是SmugMug所期待的结果,因为它希望S3对于普通用户来说是透明的。SmugMug公司还引入了EC2服务,使客户可以利用EC2来完成图片的在线编辑和处理。 将基础设施部分外包给亚马逊后,SmugMug的基础架构如图 4?33所示。几乎所有的用户都是采用直接访问SmugMug的方式处理照片,实际的照片处理过程对于用户是透明的。SmugMug的系统后台则如虚线框所示。主要包括三个部分[37]:队列服务,亚马逊AWS和控制器。目前使用的AWS包括EC2和S3。而队列服务和控制器则由SmugMug提供。SmugMug并没有采用SQS而是建立了自己的队列服务,控制器每隔固定的时间就会自动决定增加还是减少EC2实例。整个SmugMug 的系统具有高度的智能型,绝大部分操作都会自动完成。这也是为什么SmugMug仅用几十人就可以完成如此巨大的工作量。 * * * * Dynamo 的冗余副本读写策略比较有趣,它定义了:N,W,R三个参数。其中N代表系统中每条记录的副本数,W代表每次记录成功写操作需要写入的副本数,R代表每次记录读请求最少需要读取的副本数。只要W+R N就可以保证数据的一致性。因为W+RN时读写总会有交集——必定最少有W+R-N个读请求会落到被写的副本上,所以必然会读到“最后”被更新的副本数据(至于谁“最后”的判断需采用时间戳或者时钟向量等技术完成——有逻辑关系先后由时钟向量判断,否则简单的用时间戳先后判断.详情去看dynamo论文吧)。这种做法相比我们最朴素的想法——我们直观的想法一定认为如果系统要求记录冗余N份,那么每次就写入N份,而在读请求时读取任意一份可用记录即可——要更安全,也更灵活。说其更安全是指数据一致性更能被保证:比如说客户写入一条记录,该记录有三个副本在三个不同点上,但是其中一个点临时故障了,因此记录没有被写入/更新。那么在对该记录再读
原创力文档


文档评论(0)