分布式系统浅析

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/kinges/article/details/6097899

      应一个朋友的承诺,整理一下当前业界存在的几种优秀的分布式系统。特别对淘宝的后台系统做了一些分析,看看在未来的几年,symantec能够在未来的云计算,云存储的浪潮中,机会点在哪里? 当然,这里主要指的是技术切入点.

一  目前业界存在的几种分布式系统

Company using Distributed Filesystem Master Node (Y/N)
Google GFS&Bigtable Y
Amazon Dynamo N
Microsoft Azure Y
Yahoo PNUTS Y

有中心节点的分布式架构:

clip_image002

无中心节点的分布式系统架构:

     目前对数据访问的几大问题: 高吞吐,高并发,低延迟

几个文件系统的分析:

GFS&Bigtable

GFS主要有八个特点:

    1  大文件和大数据块:数据文件的大小普遍在GB级别,而且其每个数据块默认大小为64MB,这样做的好处是减少了元数据的大小,从而能使Master节点能够非常方便地将元数据都放置在内存中以提升访问效率。

    2  操作以添加为主:文件很少会被删减或者覆盖,通常只是进行添加或者读取操作,这样能充分考虑到硬盘线性吞吐量大,但随机读写慢的特点。

    3  支持容错:首先,虽然当时为了设计方便,采用了单Master的方案,但是整个系统会保证Master节点会有其相对应的替身(Shadow),以便于当Master节点出现问题

    4  时进行切换。其次,在Chunk层,GFS已经在设计上将节点失败视为常态,所以能非常好地处理Chunk节点失效的问题。

    5  高吞吐量:虽然以单个节点来看,GFS的性能无论是从吞吐量还是延迟都很普通,但因为其支持上千的节点,所以总的数据吞吐量是非常惊人的。

    6  保护数据:文件被分割成固定尺寸的数据块以便于保存,而且每个数据块都会被系统至少复制三份。

    7  扩展能力强:因为元数据偏小,使得一个Master节点能控制和管理上千个存数据的Chunk节点。

    8  支持压缩:对于那些稍旧的文件,可以通过对它进行压缩,来节省硬盘空间,并且压缩率非常惊人,有时甚至接近90%。

    9  基于用户空间:GFS主要运行于系统的用户空间(User Time),虽然在效率方面,用户空间比内核空间略低,但是更便于开发和测试,还有,就是能更好利用Linux的自带的一些POSIX API。 

      由于GFS主要是为了存储海量搜索数据而设计的,所以它在吞吐量(Throughput)和伸缩性(Scalability)这两方面表现非常优异,可谓业界的“翘楚”,但是由于其主要以64MB数据块形式存储,所以在随机访问方面速度并不优秀,虽然这点可谓是它的“软肋”,但是这本身也是其当初为了吞吐量和伸缩性所做的权衡。

 

二  淘宝分布式数据服务系统的分析和思考

三  symantec的机会点

未来几年中,symantec做为业界领先的软件提供商,机会点在哪里?

这里面有两关,必须过,一个是数据安全性,一个是收费模式(其实就是商业模式)

数据安全性,可以用一个比喻来完成,很早以前,才出现银行这个概念,但是在美国西部,银行经常被打劫,大家的钱都被抢走。但是随着银行的安全的提高,现在,大家都已经很喜欢的把钱放入银行。通过这个比喻,我们可以看到,事实上,一方面,我们确实要加强云端的数据安全性,不能再传输以及存储计算过程中被偷窥,篡改,和丢失。另外一个,需要培养客户对云端的信心,这个就需要比较长的时间了。

安全软件,无疑是symantec的强项。在云端,具体如何保护数据,可能又需要很长的一个篇幅来探讨这个问题了。我相信symantec在这个方向是,是肯定大有作为的。

再看一看商业模式的问题,早在2002年,沃达丰就已经有过这种概念的提出,极力希望能够将云设备挂在运营商的后端,然后向前端提供各种服务。也就比较类似亚马逊的EC2,PAAS。但是,关键问题来了,没有找到盈利点。这个游戏需要所有人得到好处,才可能玩的下去。因此,这个时候需要一个比较好的游戏规则。

因此,我们可以看到:运营商提供的是接入云端的网络,设备商提供的是大量的计算 存储和网络资源,而symantec可继续在软件上面大作文章。比如:帮助淘宝等 完成底层软件的构筑(与SSD裸设备直接读写,去掉文件系统那一层,速度可以提高5-6倍。业界成功的有百度的MySQL在SSD上的应用,通过修改MySQL存储引擎,实现了MySQL Flashcache的功能,通过软件与硬件结合的方式,实现了SSD性能的最大化利用,在SSD应用的方面,百度走在了国内同行的前面。) ,完成统一的平台管理

最后就是接入软件的驾驭:主要是浏览器     以及   客户端与云端的通信软件

经过这一系列的分析,我们可以看到,无论是哪一种分布式系统,都是以应用为中心,围绕它展开:便有了数据可用性,数据安全性,数据的读写效率,以及方便的管理,自动化的


References:

Key Value 数据模型:

Key-value这种数据模型在结构方面和传统的关系型相比较简单,有点类似常见的HashTable,一个Key对应一个Value,但是其能提供非常快的查询速度、大的数据存放量和高并发地操作,并非常适合通过主键(Key)来对数据进行查询和修改等操作,虽然不支持复杂的操作,但是可以通过上层的开发来弥补这个缺陷。

http://forchenyun.javaeye.com/blog/744935

http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandra/


EAV 数据模型: Entity – Attribute – Value 的缩写,是数据库模型的一种,使用eav建模的好处是可以动态为数据模型增加或移除属性。比如: 最早用于医学用途,医生在就诊时需要记录很多病人的参数,如体温,年龄,过敏药等情况,而这些参数并不是每个病人都需要记录的。

http://en.wikipedia.org/wiki/Entity-attribute-value_model


ER数据模型: 数据库模型,数据之间的relation


NoSQL(非关系型的数据库): 随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

1、High performance - 对数据库高并发读写的需求

     web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求。

2、Huge Storage - 对海量数据的高效率存储和访问的需求

对于大型的SNS网站,每天用户产生海量的用户动态,以国外的Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。

3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

      在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?

现在主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。


CAP理论:

2000年,Eric Brewer教授在ACM分布式计算年会上指出了著名的CAP理论

Brewer, E. A. 2000. Towards robust distributed systems. In Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (July 16-19, Portland, Oregon)

即分布式系统不可能满足一致性(C: Consistency),可用性(A: Availability)和分区容错性(P: Tolerance of network Partition)这三个需求。

大约两年后,Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性:

Gilbert , S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2)

虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位,但是由于其天生的几个限制,比如扩展困难、读写慢、成本高和有限的支撑容量等,使其很难满足上面这几个需求。


没有更多推荐了,返回首页