一、分布式系统简介

1、什么是分布式系统?

      分布式这个词听起来很高大上, 实际上在我们以前经常构建分布式系统, 从最初的分离LAMP中的MySQL 到引入Varnish缓存页面, 再到使用LVS负载均衡Nginx|Apache, Nginx负载均衡Tomcat等等, 广义上都算是分布式系统.

       简单来说分布式就是将一个系统的各个组件(MySQL、PHP、Apache …)分布在网络上的各台主机, 并且各组件之间仅通过消息传递来通信并协调工作

定义：

        系统的各组件分布于网络上多台计算机，各组件彼此直接仅仅通过消息传递来通信并协调行动

2、分布式系统存在的意义

单机垂直（向上）扩展的性价比不高（比越来越低）

单机扩展存在性能上升临界点

出于稳定性及可用性考虑，单机会存在多方面的问题

3、单机扩展的方式

对单机进行垂直扩展无非通过扩展CPU,内存，IO来扩展单机的性能：

多CPU：

      多线程编程：

             互不通信的线程模型

             基于共享容器（消息队列）协同工作的模型

             通过事件协调的多线程模型

      多进程模型：

I/O：

     网络I/O机制：

            多进程：每个进程相应一个请求

            多线程：多进程，每个进程生成多个线程，每个线程响应一个用户请求

            多线程：每个线程直接响应多个请求

网络I/O机制又可以分为三类模式：      

       基于socket实现网络通信开发，其实现方式：

            BIO：Blocking IO  阻塞IO    一个socket套接字需要一个进程或一个线程来处理

                      一个进程或一个线程处理一个请求

            NIO：Nonblocking IO  

                       基于事件驱动（epool）思想，采用Reactor模式，每个socket套接字分配一个线程，一个线程可以处理多个套接字处理的工作

    AIO：异步 IO

                      基于事件驱动思想，采用Proactor模式

4、如何把应用从单机扩展至多机？

输出设备的变化？

输出设备的变化？

控制器的变化？

      独立的节点，

      实现模式：

             透明代理：

                   lvs的nat模式

                   haproxy,nginx

                   旁路模式

            名称服务：

                   DNS

    规则服务：

          Master/Slave机制：

运算器的变化？         

       独立的节点    

存储器的变化？

5、分布式系统实现的难点

缺乏全局时钟

面对故障时的独立性

很难处理单点故障

很难实现事务

事务要具有ACID（事务的测试标准）. 但是这在分布式系统中很难实现：

A: Atomicity          原子性

C: Consistency      一致性

I: Isolation             隔离性

D: Durability         持久性

     很多数据库都能实现单机事务, 但是一旦构建为分布式系统, 单机的ACID就不能实现了, 

有两种选择： 1、放弃事务 2、引入分布式事务;

二、分布式事务的实现

1、一次事务中的主要角色

事务的参与者

支持事务的服务器

资源服务器

事务管理器

2、分布式事务的模型和规范

分布式事务的模型和规范: Distributed Transaction Processing: The XA Specification 

X/Open DTP: Distribution Transaction Process        #分布事务处理

X/Open(组织)：XA（分布式事务规范）

X/Open DTP(分布式事务处理参考规范）定义了三个组件：

           AP：应用程序，即使用DTP模型的程序

           RM：Resource Manager,资源管理器,即DBMS系统

           TM：Transaction Manager,事务管理器，负责协调和管理事务条例，提供给AP应用程序编程接口并管理资源管理器   

2PC

2PC : 两段式提交
     Two Phase Commitment Procotol

    如图: 一次事务首先要准备资源, 所有节点的资源都准备好后, 同时进行Commit（提交）, 如果中途中断则会一起ROLLBACK（回滚）, 从而实现数据一致性

CAP

CAP：2000年7月 由 Eric Brewer提出, 并经过他人证明, 分布式系统不能同时满足CAP

     C：Consistency   一致性   所有主机的数据都是同步的

           任何一个读操作总是能够读取之前完成的写操作

      A：Availability   可用性   (指的是快速获取数据）   能够保证系统的可用性(有主机宕机不影响用户)

            每一次操作总是能够在确定的时间返回

      P：Tolerance of network Parttion    分区容错性： 即使网络出现故障从而分区, 不影响系统运行

任何一种分布式系统最多只能同时满足上述三项中的两项，因此分布式系统的目标加强A和P，在C上进行妥协

AP：放弃C，大多数分布式系统都选择此项（并不是真正放弃，而是通过其它方式实现）

CA：放弃p

CP：放弃A

一般情况下的分布式系统都是在C(Consistency)进行妥协

BASE     加强A和P，放弃C的模型

BASE模型：可替代ACID

   BA：Basically Availibale             基本可用性

       S: Soft state                            接受一段时间内的状态不同步

       E：Eventually Consisstent      最终一致性

相比于ACID而言, BASE并没有那么苛刻, BASE允许部分的失败但是不会引起系统的故障 
DNS就是最著名的Eventually Consistent的实现

3、一致性

强一致性：

     ACID

     在单机环境中，强一致性可以由数据库的事务来保证

     在多机环境中，强一致性很难做到

     分布式事务：性能太差，在互联网的应用中不适合

弱一致性（包括最终一致性）：

      通过提交处理的半同步、半异步或全异步，取得最终一致性效 果

      最终一致性使得数据的提交具有延时性，而在一定范围的延时 性范围内(比如一秒)，应用的可用性是正常的

服务器一致性：

N：节点的个数

W:更新的时候需要确认已经被更新的节点个数

R：读数据的时候读取数据的节点个数

W+R>N  强一致性（通常N=3,W=R=2）

W=N,R=1 最佳读

W=1,R=N  最佳写

W+R<=N 弱一致性

三、分布式存储和分布式文件系统

1、存储一般分为两种类型

集中式: 
       NAS: Network Attached Storage; 文件系统级别, 例如NFS, FTP, SAMBA… 
       SAN: Storage Aera Network; 块级别, 例如IP SAN, FC SAN…

分布式: 
       中心节点存储: 每个集群中有节点专门用来存储元数据, 其他节点则存储部分数据 
       无中心节点存储: 每个集群各节点都存储元数据和部分数据

2、分布式存储和分布式文件系统

存储: 无文件系统接口, 通过API访问

文件系统: 有文件系统接口

3、分布式系统挑战

节点间通信

数据存储

数据空间平衡

容错

文件系统支持

4、分布式文件系统设计目标

访问透明      

位置透明

并发透明（加锁）

失效透明（冗余）

硬件透明

可扩展性

复制透明：

迁移透明：                           

四、分布式文件系统或存储解决方案

GFS：Google File System              #适合存储少量大文件

      Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。

下面分布式文件系统都是类 GFS的产品。

HDFS：Hadoop Distributed File System （hadoop 分布式文件系统）       #适合存储少量大文件

      namenode：名称节点  中心节点（存储元数据）   元数据存储在内存中

      datanode：数据节点

使用场景：数量不太多的大文件。百万级没问题，通常所说的海量指亿级别

       Hadoop是Apache Lucene创始人Doug Cutting开发的使用广泛的文本搜索库。它起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是Luene项目的一部分。Aapche Hadoop架构是MapReduce算法的一种开源应用，是Google开创其帝国的重要基石。

TFS：Taobao FS  将元数据存储于关系型数据库或其它高性能存储中，从而能维护海量文件元数据

使用场景：海量小文件

      TFS（Taobao !FileSystem）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器 集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用 在淘宝各项应用中。它采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化 了文件的访问流程，一定程度上为TFS提供了良好的读写性能。

官网 ： http://code.taobao.org/p/tfs/wiki/index/

GlusterFS：去中心化的设计模式   （越来越流行）       

ceph：linux内核级实现的文件系统，已经被直接收录进Linux内核（现在还不稳定，BUG较多）

        是加州大学圣克鲁兹分校的Sage weil攻读博士时开发的分布式文件系统。并使用Ceph完成了他的论文。

说 ceph 性能最高，C++编写的代码，支持Fuse，并且没有单点故障依赖， 于是下载安装， 由于 ceph 使用 btrfs 文件系统， 而btrfs 文件系统需要 Linux 2.6.34 以上的内核才支持。

可是ceph太不成熟了，它基于的btrfs本身就不成熟，它的官方网站上也明确指出不要把ceph用在生产环境中。

轻量级文件系统（也可以达到千万）：

MooseFS：mfs   性能效果不理想 

              1、支持FUSE，相对比较轻量级，对master服务器有单点依赖，用perl编写，性能相对较差，国内用的人比较多(豆辩在用)，适合数量少的大文件   

             2、高可用性(数据可以存储在多个机器上的多个副本)

             3、通用文件系统，不需要修改上层应用就可以使用（那些需要专门api的dfs好麻烦哦！）。
             4、可以在线扩容，体系架构可伸缩性极强。（官方的case可以扩到70台了！）
             5、部署简单。（sa们特别高兴，领导们特别happy！）
             6、体系架构高可用，所有组件无单点故障。 （您还等什么？
             7、件对象高可用，可设置任

MogileFS：大众点评，perl语言开发       

           由memcahed的开发公司danga一款perl开发的产品，目前国内使用mogielFS的有图片托管网站yupoo等。

MogileFS是一套高效的文件自动备份组件，由Six Apart开发，广泛应用在包括LiveJournal等web2.0站点上。

MogileFS由3个部分组成：

　　第1个部分是server端，包括mogilefsd和mogstored两个程序。

前者即是 mogilefsd的tracker，它将一些全局信息保存在数据库里，例如站点domain,class,host等。

后者即是存储节点(store node)，它其实是个HTTP Daemon，默认侦听在7500端口，接受客户端的文件备份请求。在安装完后，要运行mogadm工具将所有的store node注册到mogilefsd的数据库里，mogilefsd会对这些节点进行管理和监控。

　　第2个部分是utils（工具集），主要是MogileFS的一些管理工具，例如mogadm等。

　　第3个部分是客户端API，目前只有Perl API(MogileFS.pm)、PHP，用这个模块可以编写客户端程序，实现文件的备份管理功能。

FastDFS：C语言开发，元数据存储在内存中，

       国人在mogileFS的基础上进行改进的key-value型文件系统，同样不支持FUSE，提供比mogileFS更好的性能。简洁高效

     是一款类似Google FS的开源分布式文件系统，是纯C语言开发的。

FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，

功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。

特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

官方论坛  http://bbs.chinaunix.net/forum-240-1.html

FastDfs google Code     http://code.google.com/p/fastdfs/

分布式文件系统FastDFS架构剖析   http://www.programmer.com.cn/4380/

五、如何区分分布式、集群、并行文件系统

       分布式文件系统、集群文件系统、并行文件系统，这三种概念很容易混淆，实际中大家也经常不加区分地使用。总是有人问起这三者的区别和联系，其实它们之间在概念上的确有交叉重叠的地方，但是也存在显著不同之处。
 
分布式文件系统：
       自然地，“分布式”是重点，它是相对与本地文件系统而言的。

分布式文件系统通常指C/S架构或网络文件系统，用户数据没有直接连接到本地主机，而是存储在远程存储服务器上。NFS/CIFS是最为常见的分布式文件系统，
这就是我们说的NAS系统。分布式文件系统中，存储服务器的节点数可能是1个(如传统NAS)，也可以有多个(如集群NAS)。对于单个节点的分布式文件系统来说，存在单点故障和性能瓶颈问题。
除了NAS以外，典型的分布式文件系统还有AFS，以及集群文件系统(如Lustre, GlusterFS, PVFS2等)。
 
集群文件系统
     “集群”主要分为高性能集群HPC(High Performance Cluster)、高可用集群HAC(High Availablity Cluster)和负载均衡集群LBC(Load Balancing Cluster)。
集群文件系统是指协同多个节点提供高性能、高可用或负载均衡的文件系统，它是分布式文件系统的一个子集，消除了单点故障和性能瓶问题。对于客户端来说集群是透明的，
它看到是一个单一的全局命名空间，用户文件访问请求被分散到所有集群上进行处理。此外，可扩展性(包括Scale-Up和Scale-Out)、可靠性、易管理等也是集群文件系统追求的目标。
在元数据管理方面，可以采用专用的服务器，也可以采用服务器集群，或者采用完全对等分布的无专用元数据服务器架构。
目前典型的集群文件系统有SONAS, ISILON, IBRIX, NetAPP-GX, Lustre, PVFS2, GlusterFS, Google File System, LoongStore, CZSS等。
 
并行文件系统
       这种文件系统能够支持并行应用，比如MPI。在并行文件系统环境下，所有客户端可以在同一时间并发读写同一个文件。并发读，大部分文件系统都能够实现。
并发写实现起来要复杂许多，既要保证数据一致性，又要最大限度提高并行性，因此在锁机制方面需要特别设计，如细粒度的字节锁。
通常SAN共享文件系统都是并行文件系统，如GPFS、StorNext、GFS、BWFS，集群文件系统大多也是并行文件系统，如Lustre, Panasas等。
 
如何区分？
        区分这三者的重点是“分布式”、“集群”、“并行”三个前缀关键字。

简单来说，非本地直连的、通过网络连接的，这种为分布式文件系统；
分布式文件系统中，服务器节点由多个组成的，这种为集群文件系统；支持并行应用(如MPI)的，这种为并行文件系统。
在上面所举的例子中也可以看出，这三个概念之间具有重叠之处，比如Lustre，它既是分布式文件系统，也是集群和并行文件系统。
但是，它们也有不同之处。集群文件系统是分布式文件系统，但反之则不成立，比如NAS、AFS。
SAN文件系统是并行文件系统，但可能不是集群文件系统，如StorNext。GFS、HDFS之类，它们是集群文件系统，但可能不是并行文件系统。
实际中，三者概念搞理清后，分析清楚文件系统的特征，应该还是容易正确地为其划分类别的。

本文出自 “xiexiaojun” 博客，请务必保留此出处http://xiexiaojun.blog.51cto.com/2305291/1728371