分布式系统浅析
应一个朋友的承诺，整理一下当前业界存在的几种优秀的分布式系统。特别对淘宝的后台系统做了一些分析，看看在未来的几年，symantec能够在未来的云计算，云存储的浪潮中，机会点在哪里? 当然,这里主要指的是技术切入点.
一 目前业界存在的几种分布式系统
| Company using | Distributed Filesystem | Master Node (Y/N) |
| GFS&Bigtable | Y | |
| Amazon | Dynamo | N |
| Microsoft | Azure | Y |
| Yahoo | PNUTS | Y |
有中心节点的分布式架构：
无中心节点的分布式系统架构:
目前对数据访问的几大问题： 高吞吐，高并发，低延迟
几个文件系统的分析：
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)
虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位，但是由于其天生的几个限制，比如扩展困难、读写慢、成本高和有限的支撑容量等，使其很难满足上面这几个需求。