分布式能提高演算法算力嗎

Ⅰ 集中式數據處理和分布式數據處理的優缺點

集中式數據處理優點：

1、部署結構簡單。

2、數據容易備份，只需要把中央計算機上的數據備份即可。

3、不易感染病毒，只要對中央計算機做好保護，終端一般不需要外接設備，感染病毒的幾率很低。

4、總費用較低，中央計算機的功能非常強大，終端只需要簡單、便宜的設備。

缺點：

1、中央計算機需要執行所有的運算，當終端很多時，會導致響應速度變慢。

2、如果終端用戶有不同的需要，要對每個用戶的程序和資源做單獨的配置，在集中式系統上做起來比較困難，而且效率不高。

分布式數據處理優點：

1、分布式網路中的每台機器都能存儲和處理數據，降低了對機器性能的要求，所以不必購買昂貴的高性能機器，這大大降低了硬體投資成本。

2、擴展性極佳。在當前系統存儲或計算能力不足時，可以簡單地通過增加廉價PC機的方式來增加系統的處理和存儲能力。

3、處理能力極強。龐大的計算任務可以在合理分割後由分布式網路中的機器並行地處理

缺點

1、計算程序全負荷運行時仍會對計算機的各個部件造成一定壓力。

2、對項目方來說，參加分布式計算的志願者不是項目方自己的人員，不是全體可信任，因此必須引入一定的冗餘計算機制，才能防止計算錯誤、惡意作弊等。

(1)分布式能提高演算法算力嗎擴展閱讀

分布式計算為信息不只分布在一個軟體或計算機上，而是分布於多個軟體上，可以用多台或一台計算機同時運行若干個軟體，通過網路實現信息的共享。與其他演算法相比，分布式演算法有明顯的優勢：

1、共享資源更加方便。

2、能夠實現計算負載的平衡，用多台計算機同時處理任務。

3、可以根據實際需要合理選擇適當的計算機運行該程序。計算機分布式計算的靈魂是平衡負載和共享資源。分布式計算具有高效、快捷、准確的優勢

Ⅱ 如何知道電腦是否具有並行計算能力（就剩下這么點家底了，希望大家原諒）

你說PC嗎？ 我個人認為， 任何電腦都具有並行計算的能力。看你如何定義了。並行計算和分布式系統同樣都是一種計算方法，並不是硬體規格。

你的操作系統里每個任務都一個有個process， 而每個process都是由很多threads。如果你上過操作系統的課應該遇到過multi-threads programming. 你讓不同的threads去合作完成同一個task, 這其實就可以叫並行計算. 分布式處理嘛.

你看那些並行計算的課的project, 也都是拿普通計算機跑演算法, 重點是你會去模擬這個環境. 就像那些跑網路演算法的用socket來模擬, 也是用一台PC模擬出了N台workstations的網路.

如果你說多核CPU, 來分布式處理事情. 關於Firmware的東西平民是很難實現的. 首先你並沒有access to 那些普通的主板的firmware. 所以你必須要買一塊general purpose的 programmable的板子. 這個不難, 但你要買個多核的基本可以說找不到吧...只有實驗室里才有可能有...就算被你找到... 我覺得那塊板子的錢估計也是你去讀研然後進實驗室的學費的好幾倍...

總而言之, 軟體實現的話今天的PC應該都沒什麼問題. 硬體的話, 首先你自己做不到, 要人家官方預設了這個選項. 而至於如何啟動並行計算模式, 你要去讀這塊板子的datasheet.

我不同意上面那位說必須兩個核, 有兩個大腦的人確實可以做到並行. 但一個大腦的左腦與右腦也同樣是並行. 在細化不同的神經元相對另外一個完全independent的神經元也同樣是並行. 並行是一種解決問題的方式, 一種思想. 並行計算最早被提出的是1912年, 多核處理器是哪年才出現的, 我記不得了, 但2000年以後了吧至少...

Ⅲ 分布式計算系統 Maekawa演算法 13個進程怎麼劃分子集

第一個進程子集是（1.2.4.10）；第二個進程子集是（2.3.5.11）；以後每一列數字遞增，13以後從1重新開始。

分布式系統的類型，大致可以歸為三類：

1、分布式數據，但只有一個總資料庫，沒有局部資料庫。

2、分層式處理，每一層都有自己的資料庫。

3、充分分散的分布式網路，沒有中央控制部分，各節點之間的聯接方式又可以有多種，如鬆散的聯接，緊密的聯接，動態的聯接，廣播通知式聯接等。

(3)分布式能提高演算法算力嗎擴展閱讀

衡量分布式系統的指標

1、性能：系統的吞吐能力，指系統在某一時間可以處理的數據總量，通常可以用系統每秒處理的總的數據量來衡量；系統的響應延遲，指系統完成某一功能需要使用的時間。

系統的並發能力，指系統可以同時完成某一功能的能力，通常也用QPS(query per second)來衡量。上述三個性能指標往往會相互制約，追求高吞吐的系統，往往很難做到低延遲；系統平均響應時間較長時，也很難提高QPS。

2、可用性：系統的可用性(availability)指系統在面對各種異常時可以正確提供服務的能力。

系統的可用性可以用系統停服務的時間與正常服務的時間的比例來衡量，也可以用某功能的失敗次數與成功次數的比例來衡量。可用性是分布式的重要指標，衡量了系統的魯棒性，是系統容錯能力的體現。

3、可擴展性：系統的可擴展性(scalability)指分布式系統通過擴展集群機器規模提高系統性能（吞吐、延遲、並發）、存儲容量、計算能力的特性。

好的分布式系統總在追求「線性擴展性」，也就是使得系統的某一指標可以隨著集群中的機器數量線性增長。

4、一致性：分布式系統為了提高可用性，總是不可避免的使用副本的機制，從而引發副本一致性的問題。越是強的一致的性模型，對於用戶使用來說使用起來越簡單。

Ⅳ 分布式和雲計算有區別嗎

「雲是一個更上層、更抽象、更玄乎的概念。
而分布式是一個很具體的概念。
若沒有分布式，雲就無從談起。但分布式計算卻不一定都是雲。」

分布式是通過應用設計，將任務進行分解。
雲計算是通過類似網格的東西，由系統自動進行資源組合。

什麼是分布式計算？所謂分布式計算是一門計算機科學，它研究如何把一個需要非常巨大的計算能力才能解決的問題分成許多小的部分，然後把這些部分分配給許多計算機進行處理，最後把這些計算結果綜合起來得到最終的結果。 最近的分布式計算項目已經被用於使用世界各地成千上萬位志願者的計算機的閑置計算能力，通過網際網路，您可以分析來自外太空的電訊號，尋找隱蔽的黑洞，並探索可能存在的外星智慧生命；您可以尋找超過1000萬位數字的梅森質數；您也可以尋找並發現對抗艾滋病病毒的更為有效的葯物。這些項目都很龐大，需要驚人的計算量，僅僅由單個的電腦或是個人在一個能讓人接受的時間內計算完成是決不可能的。
分布式計算是利用互聯網上的計算機的 CPU 的閑置處理能力來解決大型計算問題的一種計算科學。下面，我們看看它是怎麼工作的：
首先, 要發現一個需要非常巨大的計算能力才能解決的問題。這類問題一般是跨學科的、極富挑戰性的、人類急待解決的科研課題。其中較為著名的是:
1.解決較為復雜的數學問題，例如：GIMPS（尋找最大的梅森素數）。
2.研究尋找最為安全的密碼系統，例如：RC-72（密碼破解）。
3.生物病理研究，例如：Folding@home（研究蛋白質折疊，誤解，聚合及由此引起的相關疾病）。
4.各種各樣疾病的葯物研究，例如：United Devices（尋找對抗癌症的有效的葯物）。
5.信號處理，例如：SETI@Home（在家尋找地外文明）。
從這些實際的例子可以看出，這些項目都很龐大，需要驚人的計算量，僅僅由單個的電腦或是個人在一個能讓人接受的時間內計算完成是決不可能的。在以前，這些問題都應該由超級計算機來解決。但是, 超級計算機的造價和維護非常的昂貴，這不是一個普通的科研組織所能承受的。隨著科學的發展，一種廉價的、高效的、維護方便的計算方法應運而生——分布式計算！
隨著計算機的普及，個人電腦開始進入千家萬戶。與之伴隨產生的是電腦的利用問題。越來越多的電腦處於閑置狀態，即使在開機狀態下CPU的潛力也遠遠不能被完全利用。我們可以想像，一台家用的計算機將大多數的時間花費在「等待」上面。即便是使用者實際使用他們的計算機時,處理器依然是寂靜的消費，依然是不計其數的等待（等待輸入，但實際上並沒有做什麼）。互聯網的出現, 使得連接調用所有這些擁有限制計算資源的計算機系統成為了現實。
那麼，一些本身非常復雜的但是卻很適合於劃分為大量的更小的計算片斷的問題被提出來，然後由某個研究機構通過大量艱辛的工作開發出計算用服務端和客戶端。服務端負責將計算問題分成許多小的計算部分，然後把這些部分分配給許多聯網參與計算的計算機進行並行處理，最後將這些計算結果綜合起來得到最終的結果。
當然，這看起來也似乎很原始、很困難，但是隨著參與者和參與計算的計算機的數量的不斷增加, 計算計劃變得非常迅速，而且被實踐證明是的確可行的。目前一些較大的分布式計算項目的處理能力已經可以達到甚而超過目前世界上速度最快的巨型計算機。
您也可以選擇參加某些項目以捐贈的 Cpu 內核處理時間,您將發現您所提供的 CPU 內核處理時間將出現在項目的貢獻統計中。您可以和其他的參與者競爭貢獻時間的排名，您也可以加入一個已經存在的計算團體或者自己組建一個計算小組。這種方法很利於調動參與者的熱情。
隨著民間的組隊逐漸增多, 許多大型組織(例如公司、學校和各種各樣的網站)也開始了組建自己的戰隊。同時，也形成了大量的以分布式計算技術和項目討論為主題的社區，這些社區多數是翻譯製作分布式計算項目的使用教程及發布相關技術性文章，並提供必要的技術支持。
那麼誰可能加入到這些項目中來呢? 當然是任何人都可以! 如果您已經加入了某個項目，而且曾經考慮加入計算小組, 您將在中國分布式計算總站及論壇里找到您的家。任何人都能加入任何由我站的組建的分布式計算小組。希望您在中國分布式總站及論壇里發現樂趣。
參與分布式計算——一種能充分發揮您的個人電腦的利用價值的最有意義的選擇——只需要下載有關程序，然後這個程序會以最低的優先度在計算機上運行，這對平時正常使用計算機幾乎沒有影響。如果你想利用計算機的空餘時間做點有益的事情，還猶豫什麼？馬上行動起來吧，你的微不足道的付出或許就能使你在人類科學的發展史上留下不小的一筆呢！
專業定義 （中國科學技術信息研究所對分布式計算的定義）
分布式計算是近年提出的一種新的計算方式。所謂分布式計算就是在兩個或多個軟體互相共享信息，這些軟體既可以在同一台計算機上運行，也可以在通過網路連接起來的多台計算機上運行。分布式計算比起其它演算法具有以下幾個優點：
1、稀有資源可以共享，
2、通過分布式計算可以在多台計算機上平衡計算負載，
3、可以把程序放在最適合運行它的計算機上，
其中，共享稀有資源和平衡負載是計算機分布式計算的核心思想之一。
實際上，網格計算就是分布式計算的一種。如果我們說某項工作是分布式的，那麼，參與這項工作的一定不只是一台計算機，而是一個計算機網路，顯然這種「螞蟻搬山」的方式將具有很強的數據處理能力。網格計算的實質就是組合與共享資源並確保系統安全。

狹義雲計算是指IT基礎設施的交付和使用模式，指通過網路以按需、易擴展的方式獲得所需的資源（硬體、平台、軟體）。 提供資源的網路被稱為「雲」。「雲」中的資源在使用者看來是可以無限擴展的，並且可以隨時獲取，按需使用，隨時擴展，按使用付費。這種特性經常被稱為像水電一樣使用IT基礎設施。

2、廣義雲計算

廣義雲計算是指服務的交付和使用模式，指通過網路以按需、易擴展的方式獲得所需的服務。這種服務可以是IT和軟體、互聯網相關的，也可以是任意其他的服務。
解釋：
這種資源池稱為「雲」。「雲」是一些可以自我維護和管理的虛擬計算資源，通常為一些大型伺服器集群，包括計算伺服器、存儲伺服器、寬頻資源等等。雲計算將所有的計算資源集中起來，並由軟體實現自動管理，無需人為參與。這使得應用提供者無需為繁瑣的細節而煩惱，能夠更加專注於自己的業務，有利於創新和降低成本。
有人打了個比方：這就好比是從古老的單台發電機模式轉向了電廠集中供電的模式。它意味著計算能力也可以作為一種商品進行流通，就像煤氣、水電一樣，取用方便，費用低廉。最大的不同在於，它是通過互聯網進行傳輸的。
雲計算是並行計算(Parallel Computing)、分布式計算(Distributed Computing)和網格計算(Grid Computing)的發展，或者說是這些計算機科學概念的商業實現。雲計算是虛擬化(Virtualization)、效用計算(Utility Computing)、IaaS(基礎設施即服務)、PaaS(平台即服務)、SaaS(軟體即服務)等概念混合演進並躍升的結果。
總的來說，雲計算可以算作是網格計算的一個商業演化版。早在2002年，我國劉鵬就針對傳統網格計算思路存在不實用問題，提出計算池的概念：「把分散在各地的高性能計算機用高速網路連接起來，用專門設計的中間件軟體有機地粘合在一起，以Web界面接受各地科學工作者提出的計算請求，並將之分配到合適的結點上運行。計算池能大大提高資源的服務質量和利用率，同時避免跨結點劃分應用程序所帶來的低效性和復雜性，能夠在目前條件下達到實用化要求。」如果將文中的「高性能計算機」換成「伺服器集群」，將「科學工作者」換成「商業用戶」，就與當前的雲計算非常接近了。
雲計算具有以下特點：
(1) 超大規模。「雲」具有相當的規模，Google雲計算已經擁有100多萬台伺服器， Amazon、IBM、微軟、Yahoo等的「雲」均擁有幾十萬台伺服器。企業私有雲一般擁有數百上千台伺服器。「雲」能賦予用戶前所未有的計算能力。
(2) 虛擬化。雲計算支持用戶在任意位置、使用各種終端獲取應用服務。所請求的資源來自「雲」，而不是固定的有形的實體。應用在「雲」中某處運行，但實際上用戶無需了解、也不用擔心應用運行的具體位置。只需要一台筆記本或者一個手機，就可以通過網路服務來實現我們需要的一切，甚至包括超級計算這樣的任務。
(3) 高可靠性。「雲」使用了數據多副本容錯、計算節點同構可互換等措施來保障服務的高可靠性，使用雲計算比使用本地計算機可靠。
(4) 通用性。雲計算不針對特定的應用，在「雲」的支撐下可以構造出千變萬化的應用，同一個「雲」可以同時支撐不同的應用運行。
(5) 高可擴展性。「雲」的規模可以動態伸縮，滿足應用和用戶規模增長的需要。
(6) 按需服務。「雲」是一個龐大的資源池，你按需購買；雲可以象自來水，電，煤氣那樣計費。
(7) 極其廉價。由於「雲」的特殊容錯措施可以採用極其廉價的節點來構成雲，「雲」的自動化集中式管理使大量企業無需負擔日益高昂的數據中心管理成本，「雲」的通用性使資源的利用率較之傳統系統大幅提升，因此用戶可以充分享受「雲」的低成本優勢，經常只要花費幾百美元、幾天時間就能完成以前需要數萬美元、數月時間才能完成的任務。
雲計算可以徹底改變人們未來的生活，但同時也用重視環境問題，這樣才能真正為人類進步做貢獻,而不是簡單的技術提升。

Ⅳ kmeans傳統演算法和分布式演算法的區別

演算法還是R語言擅長。java可以直接調用R語言的，有一個rJava的包。如果要分布式計算，可以基於hadoop調用R，，另外還有RHadoop等可參考。

Ⅵ 區塊鏈技術中的分布式演算法的特點是什麼

重慶金窩窩分析：大數據的分析挖掘是數據密集型計算，需要巨大的分布式計算能力。節點管理、任務調度、容錯和高可靠性是關鍵技術。

Ⅶ 分布式與集群的區別是什麼

分布式與集群的區別

經常聽到的名詞，這是兩個概念，你可以簡單這樣理解：分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
形象說明：

如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。

採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。

而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整身來看，還是1小時內完成一個任務!
集群概念：

1. 兩大關鍵特性

集群是一組協同工作的服務實體，用以提供比單一服務實體更具擴展性與可用性的服務平台。在客戶端看來，一個集群就象是一個服務實體，但事實上集群由一組服務實體組成。與單一服務實體相比較，集群提供了以下兩個關鍵特性：

· 可擴展性--集群的性能不限於單一的服務實體，新的服務實體可以動態地加入到集群，從而增強集群的性能。

· 高可用性--集群通過服務實體冗餘使客戶端免於輕易遇到out of service的警告。在集群中，同樣的服務可以由多個服務實體提供。如果一個服務實體失敗了，另一個服務實體會接管失敗的服務實體。集群提供的從一個出 錯的服務實體恢復到另一個服務實體的功能增強了應用的可用性。

2. 兩大能力

為了具有可擴展性和高可用性特點，集群的必須具備以下兩大能力：

· 負載均衡--負載均衡能把任務比較均衡地分布到集群環境下的計算和網路資源。

· 錯誤恢復--由於某種原因，執行某個任務的資源出現故障，另一服務實體中執行同一任務的資源接著完成任務。這種由於一個實體中的資源不能工作，另一個實體中的資源透明的繼續完成任務的過程叫錯誤恢復。

負載均衡和錯誤恢復都要求各服務實體中有執行同一任務的資源存在，而且對於同一任務的各個資源來說，執行任務所需的信息視圖(信息上下文)必須是一樣的。

3. 兩大技術

實現集群務必要有以下兩大技術：

· 集群地址--集群由多個服務實體組成，集群客戶端通過訪問集群的集群地址獲取集群內部各服務實體的功能。具有單一集群地址(也叫單一影像)是集群的一個基 本特徵。維護集群地址的設置被稱為負載均衡器。負載均衡器內部負責管理各個服務實體的加入和退出，外部負責集群地址向內部服務實體地址的轉換。有的負載均 衡器實現真正的負載均衡演算法，有的只支持任務的轉換。只實現任務轉換的負載均衡器適用於支持ACTIVE-STANDBY的集群環境，在那裡，集群中只有 一個服務實體工作，當正在工作的服務實體發生故障時，負載均衡器把後來的任務轉向另外一個服務實體。

· 內部通信--為了能協同工作、實現負載均衡和錯誤恢復，集群各實體間必須時常通信，比如負載均衡器對服務實體心跳測試信息、服務實體間任務執行上下文信息的通信。

具有同一個集群地址使得客戶端能訪問集群提供的計算服務，一個集群地址下隱藏了各個服務實體的內部地址，使得客戶要求的計算服務能在各個服務實體之間分布。內部通信是集群能正常運轉的基礎，它使得集群具有均衡負載和錯誤恢復的能力。
分布式概念：
所謂分布式計算是一門計算機科學，它研究如何把一個需要非常巨大的計算能力才能解決的問題分成許多小的部分，然後把這些部分分配給許多計算機進行處理，最後把這些計算結果綜合起來得到最終的結果。分布式網路存儲技術是將數據分散的存儲於多台獨立的機器設備上。分布式網路存儲系統採用可擴展的系統結構，利用多台存儲伺服器分擔存儲負荷，利用位置伺服器定位存儲信息，不但解決了傳統集中式存儲系統中單存儲伺服器的瓶頸問題，還提高了系統的可靠性、可用性和擴展性。
分布式是指將不同的業務分布在不同的地方。而集群指的是將幾台伺服器集中在一起，實現同一業務。分布式中的每一個節點，都可以做集群。而集群並不一定就是分布式的。分布式的每一個節點，都完成不同的業務，一個節點垮了，哪這個業務就不可訪問了。

Ⅷ 為什麼分布式演算法比集中式演算法優越

分布式計算是一種計算方法，和集中式計算是相對的。隨著計算技術的發展，有些應用需要非常巨大的計算能力才能完成，如果採用集中式計算，需要耗費相當長的時間來完成。分布式計算將該應用分解成許多小的部分，分配給多台計算機進行處理。

Ⅸ 「分布式」與「集群」的區別是什麼

（1）另外一位博主的觀點（http://blog.csdn.net/bluishglc/article/details/5483162）

博主有對他的表述有作一點修改補充，方便各位猿友明了他的意思。

簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。

例如：

如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。

採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是Hadoop的Map/Rece分布式計算模型）

而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整身來看，還是平均1小時完成一個任務！（注意這里的任務和子任務的區別）

（2）知乎（https://www.hu.com/question/20004877）

這個猿友描述得很簡單明了：

分布式：一個業務分拆多個子業務，部署在不同的伺服器上
集群：同一個業務，部署在多個伺服器上

另外一位猿友從另外一個角度去表述：

集群是個物理形態，分布式是個工作方式。

這位猿友的描述也很簡潔，但是比較抽象：

按照我的理解，集群是解決高可用的，而分布式是解決高性能、高並發的

（3）網路（http://ke..com/view/4804677.htm、http://ke..com/view/3022776.htm）

集群：

集群是一組相互獨立的、通過高速網路互聯的計算機，它們構成了一個組，並以單一系統的模式加以管理。一個客戶與集群相互作用時，集群像是一個獨立的伺服器。集群配置是用於提高可用性和可縮放性。

分布式：

一種基於網路的計算機處理技術，與集中式相對應。由於個人計算機的性能得到極大的提高及其使用的普及，使處理能力分布到網路上的所有計算機成為可能。分布式計算是和集中式計算相對立的概念，分布式計算的數據可以分布在很大區域。

看完這些是不是有種似懂非懂的感覺？博主也是一樣！所以我們接下來繼續了解。

上面博主有說過自己有接觸過分布式服務框架Dubbo，那麼我們看看它為什麼說自己是分布式服務架構？（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF）

分布式服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。

偶然之間，有發現據說「Git就是分布式版本控制系統」，為什麼它是分布式的呢？

Git就是分布式版本控制系統，對應的是集中式的版本控制如SVN。簡單的說，分布式的版本控制就是每個人都可以創建一個獨立的代碼倉庫用於管理，各種版本控制的操作都可以在本地完成。每個人修改的代碼都可以推送合並到另外一個代碼倉庫中。而像SVN這樣，只有一個中央控制，所有的開發人員都必須依賴於這個代碼倉庫。每次版本控制的操作也必須鏈接到伺服器才能完成。很多公司喜歡用集中式的版本控制是為了更好的控制代碼。如果個人開發，就可以選擇Git這種分布式的。

從一般開發者的角度來看，git有以下功能：

1、從伺服器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。
2、在自己的機器上根據不同的開發目的，創建分支，修改代碼。
3、在單機上自己創建的分支上提交代碼。
4、在單機上合並分支。
5、把伺服器上最新版的代碼fetch下來，然後跟自己的主分支合並。
6、生成補丁（patch），把補丁發送給主開發者。
7、看主開發者的反饋，如果主開發者發現兩個一般開發者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然後再由其中一個人提交。如果主開發者可以自己解決，或者沒有沖突，就通過。
8、一般開發者之間解決沖突的方法，開發者之間可以使用pull 命令解決沖突，解決完沖突之後再向主開發者提交補丁。

看了分布式服務框架Dubbo和分布式版本控制系統Git的這些描述後，細想一下，似乎和上面的「分布式：一個業務分拆多個子業務，部署在不同的伺服器上，集群：同一個業務，部署在多個伺服器上」的觀點些相似。

Dubbo將核心業務抽取出來，作為獨立的服務模塊，各個模塊之間只需要依賴介面，介面實現分離，那麼開發人員可以各自完成自己負責的服務模塊，最後完成一個完整的系統。他們的目標是完成一個系統，而各個子服務模塊相當於子業務。Git也類似。

事實上，分布式很多時候都開不了集群的，在Dubbo、Hadoop、Elasticsearch都有體現。

現在分布式概念可能我們相對比較清晰了，集群概念可能還比較模糊。另外，集群是如何跟分布式配合的呢，接下來我們繼續了解集群。

集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）

高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)

1、高可用集群(High Availability Cluster)

常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如」雙機熱備」, 「雙機互備」, 「雙機」。

高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。

2、負載均衡集群(Load Balance Cluster)

負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。

負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。

3、科學計算集群(High Performance Computing Cluster)

高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。

高性能計算分類：

3.1、高吞吐計算(High-throughput Computing)

有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。

這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。

所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。

3.2、分布計算(Distributed Computing)

另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。

下面說說這幾種集群的應用場景：

高可用集群這里不多作說明。

想Dubbo是比較偏向於負載均衡集群，用過的猿友應該知道（不知道的可以自行了解一下），Dubbo同一個服務是可以有多個提供者的，當一個消費者過來，它要消費那個提供者，這里是有負載均衡機制在裡面的。

搜索引擎Elasticsearch比較偏向於科學計算集群的分布計算。

而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。

我們以Dubbo為例：

集群容錯（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）

Dubbo提供了這些容錯策略：

集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展

Failover Cluster
失敗自動切換，當出現失敗，重試其它伺服器。(預設)
通常用於讀操作，但重試會帶來更長延遲。
可通過retries="2"來設置重試次數(不含第一次)。

Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。
通常用於非冪等性的寫操作，比如新增記錄。

Failsafe Cluster
失敗安全，出現異常時，直接忽略。
通常用於寫入審計日誌等操作。

Failback Cluster
失敗自動恢復，後台記錄失敗請求，定時重發。
通常用於消息通知操作。

Forking Cluster
並行調用多個伺服器，只要一個成功即返回。
通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks="2"來設置最大並行數。

Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一台報錯則報錯。(2.1.0開始支持)
通常用於通知所有提供者更新緩存或日誌等本地資源信息。

負載均衡（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）

Dubbo提供了這些負載均衡策略：

Random LoadBalance
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒掛，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。

LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。

ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。
當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
演算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
預設只對第一個參數Hash，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />
預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />

還有比較好奇它們是怎麼通信的？

像早期版本的Elasticsearch的話，自動發現節點機制，ES是一個基於p2p的系統，它先通過廣播尋找存在的節點，再通過多播協議來進行節點之間的通信，同時也支持點對點的交互。

而Dubbo是有個注冊中心，它支持多個注冊中心，但是推薦使用ZooKeeper。關於ZooKeeper可以自行了解，很多集群相關的框架都有使用到它。當然像Elasticsearch是自己有相應的機制實現的。

Ⅹ lamport分布式互斥演算法和Ricart-Agrawala 演算法的區別是什麼

我來回答一下吧，現在這些參考資料還真不多

Lamport 演算法

請求臨界區時：向所有其他進程發送 $REQUEST(t_i, i)$，將這個請求保存到本地請求隊列里；

如果收到了一個請求，那麼按時間戳將請求加入到本地請求隊列，然後返回一個 $REPLY(t_j)$，也是當前的時間戳；

發送了請求以後進程就等啊等啊，直到

• 收到了所有其他進程返回的 $REPLY(t*)$，期望是對本地的 $t_i$進行相應，所以要求 $t* > t_i$，也就是說，是我發了消息後，對方才回復的消息；

• 並且本地的 $t_i$ 在本地隊列的隊頭

那麼就執行，可以進入臨界區

退出臨界區時，從本地隊列里刪掉自己的請求，帶著時間戳發一個廣播，通知所有隊列都可以刪掉$i$ 請求了；

因此Lamport演算法的消息開銷為3(N-1)，分別是對除自己以外的其他進程進行資源請求、接收通知、和通知釋放

Ricart-Agrawala 演算法

主要就是來優化上一個演算法里的消息通信機制的

上一個演算法的冗餘主要有：

• 1.沒有申請臨界區資源的進程是沒必要知道你是否進行了 $RELEASE$ 操作的；

  1.1 同樣，早早的回復REPLY也是沒用的，回復了也進不去

  1.2 所以，不如等到RELEASE的時候再REPLY

• 2.同樣，它們也是沒必要知道你是否要申請臨界區資源的，這和它沒有任何關系；

這個演算法就針對1進行了優化

這個演算法去掉了 $RELEASE$ 消息，$RELEASE$ 不需要發送了；

為什麼呢？根據我們前邊的分析，將$RELEASE$發送給那些未申請臨界區的進程是沒有必要的，因此我們不想給他們發送，而申請臨界區的進程就是給我們發送了$REQUEST$ 消息的進程。因此我們只需要給我們需要$REPLY$的那些進程發送$RELEASE$就可以了。

繼續分析一下，其實馬上回復$REPLY$也是沒必要的，反正回復了它也不能馬上進行訪問，不如等到它可以訪問的時候再回復他（對請求方進程來說沒差別，對吧）。

基於這樣的想法，我們把 $REPLY$ 延遲到釋放資源時再發送。我們可以發現，但凡是我們發送 $REPLY$ 時，都沒有在繼續佔用臨界區資源了，也就是說，將這兩個消息合並成了一個消息，減少了 1/3 的消息復雜度。

因此，演算法消息開銷減少為2(N-1)