分布式系統一、基礎原理

一、分布式系統簡介

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之類，它們是叢集檔案系統，但可能不是并行檔案系統。

實際中，三者概念搞理清後，分析清楚檔案系統的特征，應該還是容易正确地為其劃分類别的。

轉載于:https://blog.51cto.com/xiexiaojun/1728371