分布式演算法原理

1. 分布式計算怎麼出現的

分布式計算可以分為以下幾類：

傳統的C/S模型。如HTTP/FTP/SMTP/POP/DBMS等伺服器。客戶端向伺服器發送請求，伺服器處理請求，並把結果返回給客戶端。客戶端處於主動，伺服器處於被動。這種調用是顯式的，遠程調用就是遠程調用，本地調用就是本地調用，每個細節你都要清楚，一點都含糊不得。

集群技術。近年來PC機的計算能力飛速發展，而伺服器的計算能力，遠遠跟不上客戶端的要求。這種多對一的關系本來就不公平，人們已經認識到靠提高單台伺服器的計算能力，永遠滿足性能上的要求。一種稱集群的技術出現了，它把多台伺服器連接起來，當成一台伺服器來用。這種技術的好處就是，不但對客戶來說是透明的，對伺服器軟體來說也是透明的，軟體不用做任何修改就可以在集群上運行。集群技術的應用范圍也僅限於此，只能提高同一個軟體的計算能力，而對於多個不同的軟體協同工作無能為力。

通用型分布式計算環境。如CORBA/DCOM/ RMI/ DBUS等，這些技術(規范)差不多都有具有網路透明性，被調用的方法可能在另外一個進程中，也可能在另外一台機器上。調用者基本上不用關心是本地調用還是遠程調用。當然正是這種透明性，造成了分布式計算的濫用，分布式計算用起來方便，大家以為它免費的。實際上，分布式計算的代價是可觀的，據說跨進程的調用，速度可能會降低一個數量級，跨機器的調用，速度可能降低兩個數量級。一些專家都建議減少使用分布式計算，即使要使用，也要使用粗粒度的調用，以減少調用的次數。

還其一些混合形式(SOAP?)，這里不再多說。我們主要介紹第三種分布式模型，這類分布式模型即適用於企業級應用，也適用於桌面應用。有的專注於企業級應用（如CORBA），有的專注於桌面環境（如DBUS）。它們的實現原理都差不多，基本上都基於傳統的RPC或者仿RPC實現的，下面介紹一下它們的基本原理。

我們先看一下分布式的最簡模型：

在傳統的方法中，調用一個對象的函數很簡單：創建這個對象，然後調用它的函數就行了。而在分布式的環境中，對象在另外一個進程中，完全在不同的地址空間里，要調用它的函數可能有點困難了。

看看傳統的C/S模型的請求方式，客戶端把參數通過網路發給伺服器，伺服器根據參數要求完成相應的服務，然後把結果返回給客戶端，客戶端拿到結果了，一次請求算完成。由此看來，調用遠程對象似乎並不難，問題在於這種方式不是網路透明的，每一個細節你都要自己處理，非常復雜。

要簡化軟體的設計，當然是網路操作透明化，調用者和實現者都無需關心網路操作。要做到這一點，我們可以按下列方法：

在客戶端要引入一個代理(Proxy)對象。它全權代理實際對象，調用者甚至都不知道它是一個代理，可以像調用本地對象一樣調用這個對象。當調用者調用Proxy的函數時，Proxy並不做實際的操作，而是把這些參數打包成一個網路數據包，並把這個數據包通過網路發送給伺服器。

在伺服器引入一個樁(Stub)對象，Stub收到Proxy發送的數據包之後，把數據包解開，重新組織為參數列表，並用這些參數就調用實際對象的函數。實際對象執行相關操作，把結果返回給Stub，Stub再把結果打包成一個網路數據包，並把這個數據包通過網路發送給客戶端的Proxy。

Proxy收到結果數據包後，把數據包解開為返回值，返回給調用者。至此，整個操作完成了。怎麼樣，簡化吧。

Proxy隱藏了客戶端的網路操作，Stub隱藏了伺服器端的網路操作，這就實現了網路透明化。你也許會說，根本沒有簡化，只是把網路操作隔離開了，仍然要去實現Proxy和Stub兩個對象，一樣的麻煩。

沒錯。不過仔細研究一下Proxy和Stub的功能，我們會發現，對於不同對象，這些操作都差不多，無非就是打包和解包而已，單調重復。單調重復的東西必然有規律可循，有規律可循就可以用代碼產生器自動產生代碼。

像DCOM和CORBA等也確實是這樣做的，先用IDL語言描述出對象的介面，然後用IDL編譯器自動產生Proxy和Stub代碼，整個過程完全不需要開發人員操心。

打包和解包的專業術語叫做marshal和unmarshal，中文常用翻譯為列集和散集。不過這兩個詞太專業了，翻譯成中文之後更加讓人不知所雲。我想還是用打包和解包兩個詞更通俗一點。

在以上模型中，調用對象的方法，確實做到了網路透明化。讀者可以會問，我要訪問對象的屬性怎麼辦呢？對象的屬性就是變數，變數就一塊內存區域，內存區域在不同的進程里完全是獨立的，這看起來確實是一個問題。還記得很多關於軟體設計書籍裡面講過的嗎：不要暴露對象屬性，調用者若要訪問對象的屬性，通過get/set方法去訪問。這樣不行了嗎，對屬性的訪問轉換為對對象方法的調用。

OK，調用對象的方法和訪問對象的屬性都解決了。還有重要的一點，如何創建對象呢。因為實際的對象並不固定在某台機器上，它的位置可能是動態的。甚至Proxy本身也不知道Stub運行在哪裡。如果要讓調用者來指定，創建對象的過程仍未達到網路透明化。通常的做法是引入一個第三方中介，這個第三方中介是固定的，可以通過一定的方法找到它。第三方中介負責在客戶端的Proxy和伺服器的Stub之間穿針引線。第三方中介通常有兩種：一種是只負責幫客戶端找到伺服器，之後客戶端與伺服器直接通信。另外一種就是不但負責找到伺服器，而且負責轉發所有的請求。

以上的模型仍然不完整，因為現實中的對象並不是一直處理於被動的地位。而是在一定的條件下，會主動觸發一些事件，並把這些事件上報給調用者。也就是說這是一個雙向的動作，單純的C/S模型無法滿足要求，而要採用P2P的方式。原先的客戶端同時作為一個伺服器存，接受來自己伺服器的請求。像COM里就是這樣做的，客戶端要注冊對象的事件，就要實現一個IDispatch介面，給對象反過來調用。

自己實現時還要考慮以下幾點：

l 傳輸抽象層。分布可能是跨進程也可能是跨機器。在不同的情況下，採用不同的通信方式，性能會有所不同。做一個傳輸抽象層，在不同的情況下，可選用不同的傳輸方式，是一種好的設計。

l 文本還是二進制。把數據打包成文本還是二進制？打包成文本的好處是，可移植性好，由於人也可以看懂，調試方便。壞處是速度稍慢，打包後的數據大小會明顯變大。採用二進制的好處是，速度快，打包後的數據大小與打包前相差不大。壞處是不易調試，可移植性較差。

l 位元組順序和位元組對齊。若採用二進制方式傳輸，可移植性是個問題。因為不同的機器上，位元組順序和位元組對齊的方式都有些差異，在數據包中要加入這些說明，以提高可移植性。

2. 分布式系統範式是什麼如何系統學習分布式計算

復旦大學計算機專業全國排第6左右，所以要靠它的研究生是有難度的 計算機專業方向及其代碼 081201計算機系統結構 01計算機網路與分布式系統 02嵌入式系統及應用 03分布式系統的監測與性能分析 04並行處理 081202計算機軟體與理論 01資料庫與知識庫 02軟體工程 03Web數據處理 04計算機支持的協同工作 05計算機生物信息處理 06數據挖掘與數據倉庫 07電子商務 08網路協議與分布式軟體 09密碼與信息安全 10演算法與程序理論 11人工智慧與認知科學 12信息安全與信息編碼 13量子信息與計算 14服務計算 081203計算機應用技術 01大規模中文文本處理 02多媒體信息處理與檢索 03計算機圖形圖像處理 04網路與信息工程 05計算機控制與智能系統 06模式識別與人工智慧 07信息安全、網路安全 08寬頻網路應用技術 初試科目： ①101政治理論②201英語③301數學一④879數據結構與操作系統 復試的筆試要考很多科目. 1. 離散數學 2. 計算機原理 3. 概率論與數理統計 4. 軟體工程 5. 計算機體系結構 6. 資料庫引論 7. 編譯 8. 數據通信與計算機網路 9. 演算法設計與分析 10. 計算機圖形學 08年起，初試計算機專業課實行全國統考。 復試這10門都要考的， 08年復旦計算機復試筆試回憶題 面試很怪異今年，牛人什麼時候都不怕。普通平民還是以專業知識為出發點吧，下面給出8門課的復習思路。 1.離散。離散我的復習思路是代數系統，正規子群的證明，圖論，歐拉和哈密頓圖，範式 ，推導。這都是大概的章節名稱，要求掌握的，結果考了正規子群，命中。 2.原理。定址，數的計算，補碼，反碼，移碼，原碼，還有就是浮點數的乘法。在這些課 的復習中肯定會有加速比的概念，看一遍就非常明白了。我沒學過原理，就復習了這些， 這是在賭博，結果算是命中了。 3.概率。不解釋，考研怎麼復習這個就怎麼復習。 4.軟工。大方向著手，譬如瀑布模型，重點在測試，白盒，黑盒，還有耦合和內聚，今年 考耦合，明年考內聚。Yes！命中。 5.體系結構。我只看了cpi的計算方法，還有mips的計算方法，流水線的東西，以及流水線 的三個相關。別的東西都是操作系統上的，考好了初試這個就沒問題。命中一半。不算命 中。 6.資料庫。Sql語言，關系演算，模式內模式外模式，2個映像，2個獨立性，還有就是無損 連接，這個最好網路一下，網上有關於怎麼證明是無損連接的。命中一半。 7.網路。香農奈奎斯特公式，還有就是數通方面的計算利用率的，不只是停等，滑動窗口 的利用率也要會算，7層協議，TCP IP了解，掌握IP地址的概念，還有就是區域網的組建， 這個都是本科學過的東西，很多專業都學過，相信大家都不會陌生，總之，命中。 8.演算法。NP方面的各種問題。我就看這么多。動態規劃一點沒看，因此未命中。 總結下來大概就50分命中的，對於我這個10門科有7門沒有學過的人來說，相當相當牛了

3. 《分布式實時計算框架原理及實踐案例》pdf下載在線閱讀全文，求百度網盤雲資源

《分布式實時計算框架原理及實踐案例》網路網盤pdf最新全集下載:
鏈接: https://pan..com/s/1mRd2oGCC97YKNMTjSpr37Q

4. 分布式存儲中，怎樣使用paxos演算法保證數據的一致性

在分布式系統中，我們經常遇到多數據副本保持一致的問題，在我們所能找到的資料中該問題講的很籠統，模模糊糊的，把多個問題或分類糅合在一起，難以理解。在思考和翻閱資料後，通俗地把一致性的問題可分解為2個問題：
1、任何一次修改保證數據一致性。
2、多次數據修改的一致性。
在弱一致性的演算法，不要求每次修改的內容在修改後多副本的內容是一致的，對問題1的解決比較寬松，更多解決問題2，該類演算法追求每次修改的高度並發性，減少多副本之間修改的關聯性，以獲得更好的並發性能。例如最終一致性，無所謂每次用戶修改後的多副本的一致性及格過，只要求在單調的時間方向上，數據最終保持一致，如此獲得了修改極大的並發性能。
在強一致性的演算法中，強調單次修改後結果的一致，需要保證了對問題1和問題2要求的實現，犧牲了並發性能。本文是討論對解決問題1實現演算法，這些演算法往往在強一致性要求的應用中使用。
解決問題1的方法，通常有兩階段提交演算法、採用分布式鎖服務和採用樂觀鎖原理實現的同步方式,下面分別介紹這幾種演算法的實現原理。

兩階段提交演算法

在兩階段提交協議中，系統一般包含兩類機器（或節點）：一類為協調者（coordinator），通常一個系統中只有一個；另一類為事務參與者（participants，cohorts或workers），一般包含多個，在數據存儲系統中可以理解為數據副本的個數。兩階段提交協議由兩個階段組成，在正常的執行下，這兩個階段的執行過程如下所述：
階段1：請求階段（commit-request phase，或稱表決階段，voting phase）。
在請求階段，協調者將通知事務參與者准備提交或取消事務，然後進入表決過程。在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。
階段2：提交階段（commit phase）。
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。參與者在接收到協調者發來的消息後將執行響應的操作。
舉個例子：A組織B、C和D三個人去爬長城：如果所有人都同意去爬長城，那麼活動將舉行；如果有一人不同意去爬長城，那麼活動將取消。用2PC演算法解決該問題的過程如下：
首先A將成為該活動的協調者，B、C和D將成為該活動的參與者。
階段1：A發郵件給B、C和D，提出下周三去爬山，問是否同意。那麼此時A需要等待B、C和D的郵件。B、C和D分別查看自己的日程安排表。B、C發現自己在當日沒有活動安排，則發郵件告訴A它們同意下周三去爬長城。由於某種原因，D白天沒有查看郵件。那麼此時A、B和C均需要等待。到晚上的時候，D發現了A的郵件，然後查看日程安排，發現周三當天已經有別的安排，那麼D回復A說活動取消吧。
階段2：此時A收到了所有活動參與者的郵件，並且A發現D下周三不能去爬山。那麼A將發郵件通知B、C和D，下周三爬長城活動取消。此時B、C回復A「太可惜了」，D回復A「不好意思」。至此該事務終止。
兩階段提交演算法在分布式系統結合，可實現單用戶對文件（對象）多個副本的修改，多副本數據的同步。其結合的原理如下：
1、客戶端（協調者）向所有的數據副本的存儲主機（參與者）發送：修改具體的文件名、偏移量、數據和長度信息，請求修改數據，該消息是1階段的請求消息。
2、存儲主機接收到請求後，備份修改前的數據以備回滾，修改文件數據後，向客戶端回應修改成功的消息。 如果存儲主機由於某些原因（磁碟損壞、空間不足等）不能修改數據，回應修改失敗的消息。
3、客戶端接收發送出去的每一個消息回應，如果存儲主機全部回應都修改成功，向每存儲主機發送確認修改的提交消息；如果存在存儲主機回應修改失敗，或者超時未回應，客戶端向所有存儲主機發送取消修改的提交消息。該消息是2階段的提交消息。
4、存儲主機接收到客戶端的提交消息，如果是確認修改，則直接回應該提交OK消息；如果是取消修改，則將修改數據還原為修改前，然後回應取消修改OK的消息。
5、 客戶端接收全部存儲主機的回應，整個操作成功。
在該過程中可能存在通信失敗，例如網路中斷、主機宕機等諸多的原因，對於未在演算法中定義的其它異常，都認為是提交失敗，都需要回滾，這是該演算法基於確定的通信回復實現的，在參與者的確定回復（無論是回復失敗還是回復成功）之上執行邏輯處理，符合確定性的條件當然能夠獲得確定性的結果哲學原理。

分布式鎖服務

分布式鎖是對數據被外界修改持保守態度，在整個數據處理過程中將數據處於鎖定狀態，在用戶修改數據的同時，其它用戶不允許修改。
採用分布式鎖服務實現數據一致性，是在操作目標之前先獲取操作許可，然後再執行操作，如果其他用戶同時嘗試操作該目標將被阻止，直到前一個用戶釋放許可後，其他用戶才能夠操作目標。分析這個過程，如果只有一個用戶操作目標，沒有多個用戶並發沖突，也申請了操作許可，造成了由於申請操作許可所帶來的資源使用消耗，浪費網路通信和增加了延時。
採用分布式鎖實現多副本內容修改的一致性問題， 選擇控制內容顆粒度實現申請鎖服務。例如我們要保證一個文件的多個副本修改一致， 可以對整個文件修改設置一把鎖，修改時申請鎖，修改這個文件的多個副本，確保多個副本修改的一致，修改完成後釋放鎖；也可以對文件分段，或者是文件中的單個位元組設置鎖， 實現更細顆粒度的鎖操作，減少沖突。
常用的鎖實現演算法有Lamport bakery algorithm （俗稱麵包店演算法）， 還有Paxos演算法。下面對其原理做簡單概述。

Lamport麵包店演算法

是解決多個線程並發訪問一個共享的單用戶資源的互斥問題的演算法。 由Leslie Lamport（英語：Leslie Lamport）發明。
Lamport把這個並發控制演算法可以非常直觀地類比為顧客去麵包店采購。麵包店只能接待一位顧客的采購。已知有n位顧客要進入麵包店采購，安排他們按照次序在前台登記一個簽到號碼。該簽到號碼逐次加1。根據簽到號碼的由小到大的順序依次入店購貨。完成購買的顧客在前台把其簽到號碼歸0. 如果完成購買的顧客要再次進店購買，就必須重新排隊。
這個類比中的顧客就相當於線程，而入店購貨就是進入臨界區獨占訪問該共享資源。由於計算機實現的特點，存在兩個線程獲得相同的簽到號碼的情況，這是因為兩個線程幾乎同時申請排隊的簽到號碼，讀取已經發出去的簽到號碼情況，這兩個線程讀到的數據是完全一樣的，然後各自在讀到的數據上找到最大值，再加1作為自己的排隊簽到號碼。為此，該演算法規定如果兩個線程的排隊簽到號碼相等，則線程id號較小的具有優先權。
把該演算法原理與分布式系統相結合，即可實現分步鎖。

Paxos演算法

該演算法比較熱門，參見WIKI，http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95
Paxos演算法解決的問題是一個分布式系統如何就某個值(決議)達成一致。一個典型的場景是，在一個分布式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。一個通用的一致性演算法可以應用在許多場景中，是分布式計算中的重要問題。節點通信存在兩種模型：共享內存(Shared memory)和消息傳遞(Messages passing)。Paxos演算法就是一種基於消息傳遞模型的一致性演算法。BigTable使用一個分布式數據鎖服務Chubby，而Chubby使用Paxos演算法來保證備份的一致性。

採用樂觀鎖原理實現的同步

我們舉個例子說明該演算法的實現原理。如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進行修改時（如更改用戶帳戶余額），如果採用前面的分布式鎖服務機制，也就意味著整個操作過程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾百上千個並發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（ Version）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 「version」 欄位來實現。讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交數據的版本數據與資料庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於資料庫表當前版本號，則予以更新，否則認為是過期數據。
對於上面修改用戶帳戶信息的例子而言，假設資料庫中帳戶信息表中有一個 version 欄位，當前值為 1 ；而當前帳戶余額欄位（ balance ）為 $100 。
操作員 A 此時將其讀出（version=1 ），並從其帳戶余額中扣除 $50（$100-$50 ）。
在操作員 A 操作的過程中，操作員B也讀入此用戶信息（ version=1 ），並從其帳戶余額中扣除 $20 （ $100-$20 ）。
操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣除後余額（ balance=$50 ），提交至資料庫更新，此時由於提交數據版本大於資料庫記錄當前版本，數據被更新，資料庫記錄 version 更新為 2 。
操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向資料庫提交數據（ balance=$80 ），但此時比對資料庫記錄版本時發現，操作員 B 提交的數據版本號為 2 ，資料庫記錄當前版本也為 2 ，不滿足 「 提交版本必須大於記錄當前版本才能執行更新 「 的樂觀鎖策略，因此，操作員 B 的提交被駁回。這樣，就避免了操作員 B 用基於 version=1 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。
樂觀鎖機制與分布式系統相結合上， 我整理了偽代碼如下：
obj 操作的目標
vlaue 修改的值
atom_update_ver 每個目標上的版本，每次修改該值遞增
set( obj, value)
{
//從每個節點上取出修改前的對象版本
get original_ver = obj.atom_update_ver from each node;
//將值賦到每個節點的obj目標
set obj = value from each node;
//條件修改每個節點的obj版本，目標版本加一
//比較和修改操作是原子操作
result = (set obj.atom_update_ver = original_ver + 1
where original_ver + 1 > obj.atom_update_ver
for each node);
if(result == ok)
return set_ok;
else
return set(obj, value);//不成功遞歸修改

該演算法未考慮節點下線、失效等問題，在後續我將分析採用樂觀鎖原理實現一致性演算法，解決問題2、節點失效、通信失敗等問題。

5. 雲計算與分布式計算有區別嗎

分布式技術其實質上是一種基於網路的計算機處理技術。一個分布式系統（Distributed System）是一組邏輯和物理上互聯的處理單元的集合。其實質就是對資源的系統范圍的分散控制，以達到應用程序的協同執行。這種系統不要求單台計算機的功能十分強大，故能降低成本。分布式系統具有快速訪問、多用戶使用的優點。系統中的每台計算機可以方便快捷的訪問其他內部節點的信息文件，它既可以為本地用戶的特殊要求服務，也可以為網路中其他用戶服務，實現不同計算機之間的通信與協同工作。

雲計算（Cloud Computing）是分布式處理、並行處理、網格計算的發展，是虛擬化、效用計算、IaaS、PaaS、SaaS等概念混合躍升的結果。基本原理是將計算任務分布在雲端的大量的分布式計算機上、數據也存儲在雲端，使得企業將有限的資源切換到需要的應用上，降低企業運行的成本。這樣帶來的結果是中小企業不需要購置專門的計算機系統去滿足某一應用需求，只需要想雲計算中心支付服務費即可獲得響應服務，而雲計算中心則大規模的雲，以向用戶提供服務。總的來說雲計算具有如下的特點：超大規模雲計算集群、虛擬化、高可靠性、通用性、按需服務、極其廉價。

6. 雲計算操作系統和分布式操作系統有什麼區別

分布式操作系統負責管理分布式處理系統資源和控制分布式程序運行。它和集中式操作系統的區別在於資源管理、進程通信和系統結構等方面。運行於分布式計算機系統上的分布式程序由若干個可以獨立執行的程序模塊組成,它們分布於一個分布式處理系統的多台計算機上被同時執行。它與集中式的程序設計語言相比有三個特點：分布性、通信性和穩健性。

雲計算操作系統是以分布式操作系統為基礎的，提供資源的網路稱為「雲」。其基本原理是，使計算分布在大量的分布式計算機上，而非本地計算機或遠程伺服器中。這樣可以有效降低對客戶端的要求，通過「雲」網路，無論是移動設備、數碼產品還是台式PC，都可以獲得類似的有效服務。

7. 分布式計算是誰提出的研究到什麼程度了未來有哪些可研究方向目前的發展狀態如何

沒有誰提出，估計是總結出來的
最早概念應該是谷歌的技術就有。比如maprece
目前原理框架進步很少，而是技術實現的優化，新框架太少，本質上是分工計算模型太少，

8. 分布式系統常用的一致性演算法有哪些

有一些系統設計基礎的話，給你推薦幾本書吧： 《面向模式的軟體架構 卷4：分布式計算的模式語言》出版社：人民郵電出版社 主要講分布式計算系統軟體的設計和實現。 偏軟體方向，相對較專業。 《分布式計算（第二版）》出版社：電子工業出版社 主要介紹分布式計算的數學基礎和理論，揭示設計分布式系統的底層問題（通信、協調、同步及不確定）和基本的演算法概念及下界技術。 容易理解，適合自學。 《分布式系統原理與范型》出版社：清華大學出版社 全書的第一部分討論了分布式系統的原理、概念和技術，其中包括通信、進程、命名、同步、一致性和復制、容錯以及安全。第二部分給出了一些實際的分布式系統：基於對象的分布式系統、分布式文件系統、基於文檔的分布式系統以及基於協作的分布式系統，介紹了一些實際系統的設計思想和實現技術。 容易理解，適合自學。