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

一  眼下业界存在的几种分布式系统

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

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

     眼下对数据訪问的几大问题： 高吞吐，高并发，低延迟

几个文件系统的分析：

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应用的方面，百度走在了国内同行的前面。） ，完毕统一的平台管理

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

经过这一系列的分析，我们能够看到，不管是哪一种分布式系统，都是以应用为中心，环绕它展开：便有了数据可用性，数据安全性，数据的读写效率，以及方便的管理，自己主动化的

References：

Key Value 数据模型:

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

EAV 数据模型： Entity – Attribute – Value 的缩写，是数据库模型的一种，使用eav建模的优点是能够动态为数据模型添加或移除属性。比方: 最早用于医学用途，医生在就诊时须要记录非常多病人的參数，如体温，年龄，过敏药等情况，而这些參数并非每一个病人都须要记录的。

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)

尽管关系型数据库已经在业界的数据存储方面占领不可动摇的地位，可是因为其天生的几个限制，比方扩展困难、读写慢、成本高和有限的支撑容量等，使其非常难满足上面这几个需求。