分布式系統和計算機網路系統的共同點是：多數分布式系統是建立在計算機網路之上的，所以分布式系統與計算機網路在物理結構上是基本相同的。
他們的區別在於：分布式作業系統的設計思想和網路作業系統是不同的，這決定了他們在結構、工作方式和功能上也不同。網路作業系統要求網路使用者在使用網路資源時首先必須了解網路資源，網路使用者必須知道網路中各個計算機的功能與配置、軟體資源、網路檔案結構等情況，在網路中如果使用者要讀乙個共享檔案時，使用者必須知道這個檔案放在哪一台計算機的哪乙個目錄下；分布式作業系統是以全域性方式管理系統資源的，它可以為使用者任意排程網路資源，並且排程過程是「透明」的。當使用者提交乙個作業時，分布式作業系統能夠根據需要在系統中選擇最合適的處理器，將使用者的作業提交到該處理程式，在處理器完成作業後，將結果傳給使用者。在這個過程中，使用者並不會意識到有多個處理器的存在，這個系統就像是乙個處理器一樣。
分布式系統的缺點
儘管分布式系統有許多優點，但也有缺點。本節就將指出其中的一些缺點。我們前面已經提到了最棘手的問題：軟體。就目前的最新技術發展水平，我們在設計、實現及使用分布式系統上都沒有太多的經驗。什麼樣的作業系統、程式語言和應用適合這一系統呢？使用者對分布式系統中分布式處理又應該了解多少呢？系統應當做多少而使用者又應當做多少呢？專家們的觀點不一（這並不是因為專家們與眾不同，而是因為對於分布式系統他們也很少涉及）。隨著更多的研究的進行，這些問題將會逐漸減少。但是我們不應該低估這個問題。
第二個潛在的問題是通訊網路。由於它會損失資訊，所以就需要專門的軟體進行恢復。同時，網路還會產生過載。當網路負載趨於飽和時，必須對它進行改造替換或加入另外乙個網路擴容。在這兩種情況下，乙個或多個建築中的某些部分必須花費很高的費用進行重新佈線，或者更換網路界面板（例如用光纖）。一旦系統依賴於網路，那麼網路的資訊丟失或飽和將會抵消我們通過建立分布式系統所獲得的大部分優勢。
最後，上面我們作為優點來描述的資料易於共享性也是具有兩面性的。如果人們能夠很方便地訪問整個系統中的資料，那麼他們同樣也能很方便地訪問與他們無關的資料。換句話說，我們經常要考慮系統的安全性問題。通常，對必須絕對保密的資料，使用乙個專用的、不與其它任何機器相連的孤立的個人計算機進行儲存的方法更可取。而且這個計算機被儲存在乙個上鎖的十分安全的房間中，與這台計算相配套的所有軟盤都存放在這個房間中的乙個保險箱中.
分布式系統的測試
在測試執行過程中，對測試結果的分析是乙個需要進行深入思考的重點問題。分布式系統測試的重點在於對後端伺服器集群的測試，而判定系統中是否存在bug則是我們需要解決的重要問題。那麼應該如何確定是否存在bug呢？
對於測試結果的分析，我們通常觀察下面幾種情況。
觀察前端應用的返回結果。這裡需要分兩種情況來考慮：第一，按照前端應用業務功能點及流程進行操作，觀察返回結果是否符合業務方的需求預期；第二，操作後端的伺服器（通常是重啟、宕機、斷網等操作），觀察前端應用的返回結果是否符合系統的設計需求。
分析伺服器日誌。在功能測試過程中，當我們在啟動伺服器的時候，需要將日誌級別定義為debug級別（最低級別）。這樣做的主要目的是為了能便於測試工程師來分析日誌和定位問題。為了能更好地定位問題，常常需要在伺服器程式**中進行日誌打樁，把程式中的一些重要資料通過日誌的方式展現出來。通常情況下，我們需要對日誌的格式進行約定，在日誌行中增加一些關鍵字來進行分類，這將便於測試工程師進行日誌分析，也有利於開展分布式系統的自動化測試。另外，值得注意的是，我們盡可能地將打樁**放在debug**中，避免影響系統**，引入新問題。
分析作業系統的一些重要資訊。我們測試的分布式系統絕大多數是基於linux作業系統開發的，在測試的過程中，除了詳細分析程式日誌以外，還需要對作業系統的一些重要資料資訊進行分析，從而來診斷伺服器程式是否存在異常。以linux作業系統為例，我們常常會使用top命令、netstat命令及sar命令來檢視作業系統的一些資料資訊。例如，可以通過netstat命令檢查伺服器程式是否正確地監聽了指定的埠等。
借助其他分析工具。例如，如何判斷伺服器程式是否產生了記憶體洩漏？通常需要借助於記憶體檢測工具來進行分析。在linux環境下，我們常用valgrind來進行記憶體檢測。這是一款非常好用、功能強大的分析工具，可以幫助測試或者開發工程師快速發現很多隱藏的程式bug，尤其是在記憶體檢測方面（同時它還具有很多其他優秀的功能，讀者可以自己檢視官網中的使用手冊）。
分布式系統壓力測試與效能測試
對於分布式系統而言，壓力測試和效能測試非常重要。在進行壓力測試和效能測試的時候，可能會碰到下面一些難點。
資料準備。如何準備海量的測試資料並保證模擬資料的真實性？以乙個分布式的檔案系統為例，預先存入100gb的資料還是存入100tb的資料、存入的檔案是大小基本一致差別不大還是各不相同甚至差異很大（例如，從幾十位元組至幾十兆位元組不等），這些因素對於分布式系統的效能影響是有很大差異的。另外，如果需要預先存入100tb的資料，若按每秒寫入100mb資料來計算，寫入100tb資料需要100×1024×1024/100=1048576秒=291.27小時=12天。我們是否能忍受這麼長時間的資料準備工作？為了解決這樣的問題，我們需要對系統架構設計進行深入分析，設計好測試場景，並提前進行測試用例的設計，以盡早開始準備測試資料。
效能或壓力測試工具。通常來說，分布式系統的測試需要開發一些測試工具來滿足效能測試的需求。如果可以的話，建議這樣的測試工具最好由測試工程師自己來實現，因為測試工程師更清楚自己的測試需求。當需要自己開發測試工具的時候，有兩個關鍵問題需要重點關注：第一，一些關鍵資料的收集方式與計算將成為效能測試工具的關鍵，例如，tps（每秒請求數）、throughput（吞吐量）計算的準確性；第二，要保證效能測試工具的效能，如果工具本身的效能不好，將無法給予分布式系統足夠強大的壓力來進行測試。另外，當考慮到多併發（例如有10萬客戶端同時併發連線）時，如果效能測試工具在一台測試機器上只能執行50個或者更少的話，那麼需要的測試機器數量也將會很龐大（例如2000臺測試機），這個成本或許是許多公司不能承受的。因此，效能測試工具本身的效能必須要足夠好才能滿足需求、降低測試成本。
分布式系統自動化測試
自動化測試是測試行業發展的必然趨勢，對於分布式系統測試而言也不例外。在實施分布式系統自動化測試的過程中，我們可能會碰到下面兩個難點問題。
涉及平台多且硬體雜，測試流程控制困難。在實施自動化測試的過程中，測試指令碼需要控制的作業系統和應用程式很多，而且存在跨平台的特性，同時還有可能需要控制一些網路裝置。因此，選擇乙個優秀的自動化測試框架成為了非常重要的工作之一。以我們的實踐經驗來看，staf是乙個不錯的選擇，它的平台（windows及linux各版本）支援及開發語言的支援都很全面。
測試結果驗證複雜。對於分布式系統的自動化測試來說，我們需要通過測試指令碼來收集各種測試結果資料以驗證測試結果的正確性。在實施自動化測試的過程中，我們可以將測試結果資料收集部分模組化，通過各子模組來檢測各項資料是否正確。例如，我們會設計乙個日誌分析模組，主要負責從伺服器應用程式的日誌中收集相應資料進行對比驗證.
分布式系統
分布式，一來就直接看書，除非你有比較深厚的技術功底，要不還是很晦澀難懂的。先想想為什麼會有分布式，分布式怎麼來的。傳統的電信 銀行業，當業務量大了之後，普通伺服器cpu io 網路到了100 請求太慢怎麼辦？最直接的做法，公升級硬體，反正也不缺錢，ibm小型機，大型機，採購了堆硬體。但是網際網路不能...
分布式系統
zookeeper讓服務配置變得更簡單 zookeeper是hadoop下的乙個子專案，它是乙個針對大型分布式系統的可靠的協調系統，提供的功能包括 配置維護 名字服務 分布式同步 組服務等。zookeeper是可以集群複製的，集群間通過zab zookeeper atomic broadcast 協...
分布式系統
集中式 集中式只有乙個伺服器或者多個伺服器 只能有乙個機架 組成乙個整體 處理所有的業務 分布式系統是由硬體和軟體組分布在不同的網路計算機中 ip網段可能不一樣 彼此之間僅僅通過訊息傳遞 協調整個系統服務 分布式系統與概念設計 缺點 節點故障 計算程式是分布式的，如果乙個maptask掛了會導致hd...