A. 分布式Web伺服器架構
最開始，由於某些想法，於是在互聯網上搭建了一個網站，這個時候甚至有可能主機都是租借的，但由於這篇文章我們只關注架構的演變歷程，因此就假設這個時候已經是託管了一台主機，並且有一定的帶寬了，這個時候由於網站具備了一定的特色，吸引了部分人訪問，逐漸你發現系統的壓力越來越高，響應速度越來越慢，而這個時候比較明顯的是資料庫和應用互相影響，應用出問題了，資料庫也很容易出現問題，而資料庫出問題的時候，應用也容易出問題，於是進入了第一步演變階段：將應用和資料庫從物理上分離，變成了兩台機器，這個時候技術上沒有什麼新的要求，但你發現確實起到效果了，系統又恢復到以前的響應速度了，並且支撐住了更高的流量，並且不會因為資料庫和應用形成互相的影響。
這一步架構演變對技術上的知識體系基本沒有要求。
架構演變第二步：增加頁面緩存
好景不長，隨著訪問的人越來越多，你發現響應速度又開始變慢了，查找原因，發現是訪問資料庫的操作太多，導致數據連接競爭激烈，所以響應變慢，但資料庫連接又不能開太多，否則資料庫機器壓力會很高，因此考慮採用緩存機制來減少資料庫連接資源的競爭和對資料庫讀的壓力，這個時候首先也許會選擇採用squid 等類似的機制來將系統中相對靜態的頁面（例如一兩天才會有更新的頁面）進行緩存（當然，也可以採用將頁面靜態化的方案），這樣程序上可以不做修改，就能夠很好的減少對webserver的壓力以及減少資料庫連接資源的競爭，OK，於是開始採用squid來做相對靜態的頁面的緩存。
前端頁面緩存技術，例如squid，如想用好的話還得深入掌握下squid的實現方式以及緩存的失效演算法等。
架構演變第三步：增加頁面片段緩存
增加了squid做緩存後，整體系統的速度確實是提升了，webserver的壓力也開始下降了，但隨著訪問量的增加，發現系統又開始變的有些慢了，在嘗到了squid之類的動態緩存帶來的好處後，開始想能不能讓現在那些動態頁面里相對靜態的部分也緩存起來呢，因此考慮採用類似ESI之類的頁面片段緩存策略，OK，於是開始採用ESI來做動態頁面中相對靜態的片段部分的緩存。
這一步涉及到了這些知識體系：
頁面片段緩存技術，例如ESI等，想用好的話同樣需要掌握ESI的實現方式等；
架構演變第四步：數據緩存
在採用ESI之類的技術再次提高了系統的緩存效果後，系統的壓力確實進一步降低了，但同樣，隨著訪問量的增加，系統還是開始變慢，經過查找，可能會發現系統中存在一些重復獲取數據信息的地方，像獲取用戶信息等，這個時候開始考慮是不是可以將這些數據信息也緩存起來呢，於是將這些數據緩存到本地內存，改變完畢後，完全符合預期，系統的響應速度又恢復了，資料庫的壓力也再度降低了不少。
這一步涉及到了這些知識體系：
緩存技術，包括像Map數據結構、緩存演算法、所選用的框架本身的實現機制等。
架構演變第五步： 增加webserver
好景不長，發現隨著系統訪問量的再度增加，webserver機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一台webserver，這也是為了同時解決可用性的問題，避免單台的webserver down機的話就沒法使用了，在做了這些考慮後，決定增加一台webserver，增加一台webserver時，會碰到一些問題，典型的有：
1、如何讓訪問分配到這兩台機器上，這個時候通常會考慮的方案是Apache自帶的負載均衡方案，或LVS這類的軟體負載均衡方案；
2、如何保持狀態信息的同步，例如用戶session等，這個時候會考慮的方案有寫入資料庫、寫入存儲、cookie或同步session信息等機制等；
3、如何保持數據緩存信息的同步，例如之前緩存的用戶數據等，這個時候通常會考慮的機制有緩存同步或分布式緩存；
4、如何讓上傳文件這些類似的功能繼續正常，這個時候通常會考慮的機制是使用共享文件系統或存儲等；
在解決了這些問題後，終於是把webserver增加為了兩台，系統終於是又恢復到了以往的速度。
這一步涉及到了這些知識體系：
負載均衡技術（包括但不限於硬體負載均衡、軟體負載均衡、負載演算法、linux轉發協議、所選用的技術的實現細節等）、主備技術（包括但不限於 ARP欺騙、linux heart-beat等）、狀態信息或緩存同步技術（包括但不限於Cookie技術、UDP協議、狀態信息廣播、所選用的緩存同步技術的實現細節等）、共享文件技術（包括但不限於NFS等）、存儲技術（包括但不限於存儲設備等）。
架構演變第六步：分庫
享受了一段時間的系統訪問量高速增長的幸福後，發現系統又開始變慢了，這次又是什麼狀況呢，經過查找，發現資料庫寫入、更新的這些操作的部分資料庫連接的資源競爭非常激烈，導致了系統變慢，這下怎麼辦呢，此時可選的方案有資料庫集群和分庫策略，集群方面像有些資料庫支持的並不是很好，因此分庫會成為比較普遍的策略，分庫也就意味著要對原有程序進行修改，一通修改實現分庫後，不錯，目標達到了，系統恢復甚至速度比以前還快了。
這一步涉及到了這些知識體系：
這一步更多的是需要從業務上做合理的劃分，以實現分庫，具體技術細節上沒有其他的要求；
但同時隨著數據量的增大和分庫的進行，在資料庫的設計、調優以及維護上需要做的更好，因此對這些方面的技術還是提出了很高的要求的。
架構演變第七步：分表、DAL和分布式緩存
隨著系統的不斷運行，數據量開始大幅度增長，這個時候發現分庫後查詢仍然會有些慢，於是按照分庫的思想開始做分表的工作，當然，這不可避免的會需要對程序進行一些修改，也許在這個時候就會發現應用自己要關心分庫分表的規則等，還是有些復雜的，於是萌生能否增加一個通用的框架來實現分庫分表的數據訪問，這個在ebay的架構中對應的就是DAL，這個演變的過程相對而言需要花費較長的時間，當然，也有可能這個通用的框架會等到分表做完後才開始做，同時，在這個階段可能會發現之前的緩存同步方案出現問題，因為數據量太大，導致現在不太可能將緩存存在本地，然後同步的方式，需要採用分布式緩存方案了，於是，又是一通考察和折磨，終於是將大量的數據緩存轉移到分布式緩存上了。
這一步涉及到了這些知識體系：
分表更多的同樣是業務上的劃分，技術上涉及到的會有動態hash演算法、consistent hash演算法等；
DAL涉及到比較多的復雜技術，例如資料庫連接的管理（超時、異常）、資料庫操作的控制（超時、異常）、分庫分表規則的封裝等；
架構演變第八步：增加更多的webserver
在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了，突然有一天，發現系統的訪問又開始有變慢的趨勢了，這個時候首先查看資料庫，壓力一切正常，之後查看webserver，發現apache阻塞了很多的請求，而應用伺服器對每個請求也是比較快的，看來是請求數太高導致需要排隊等待，響應速度變慢，這還好辦，一般來說，這個時候也會有些錢了，於是添加一些webserver伺服器，在這個添加 webserver伺服器的過程，有可能會出現幾種挑戰：
1、Apache的軟負載或LVS軟負載等無法承擔巨大的web訪問量（請求連接數、網路流量等）的調度了，這個時候如果經費允許的話，會採取的方案是購買硬體負載，例如F5、Netsclar、Athelon之類的，如經費不允許的話，會採取的方案是將應用從邏輯上做一定的分類，然後分散到不同的軟負載集群中；
2、原有的一些狀態信息同步、文件共享等方案可能會出現瓶頸，需要進行改進，也許這個時候會根據情況編寫符合網站業務需求的分布式文件系統等；
在做完這些工作後，開始進入一個看似完美的無限伸縮的時代，當網站流量增加時，應對的解決方案就是不斷的添加webserver。
這一步涉及到了這些知識體系：
到了這一步，隨著機器數的不斷增長、數據量的不斷增長和對系統可用性的要求越來越高，這個時候要求對所採用的技術都要有更為深入的理解，並需要根據網站的需求來做更加定製性質的產品。
架構演變第九步：數據讀寫分離和廉價存儲方案
突然有一天，發現這個完美的時代也要結束了，資料庫的噩夢又一次出現在眼前了，由於添加的webserver太多了，導致資料庫連接的資源還是不夠用，而這個時候又已經分庫分表了，開始分析資料庫的壓力狀況，可能會發現資料庫的讀寫比很高，這個時候通常會想到數據讀寫分離的方案，當然，這個方案要實現並不容易，另外，可能會發現一些數據存儲在資料庫上有些浪費，或者說過於佔用資料庫資源，因此在這個階段可能會形成的架構演變是實現數據讀寫分離，同時編寫一些更為廉價的存儲方案，例如BigTable這種。
這一步涉及到了這些知識體系：
數據讀寫分離要求對資料庫的復制、standby等策略有深入的掌握和理解，同時會要求具備自行實現的技術；
廉價存儲方案要求對OS的文件存儲有深入的掌握和理解，同時要求對採用的語言在文件這塊的實現有深入的掌握。
架構演變第十步：進入大型分布式應用時代和廉價伺服器群夢想時代
經過上面這個漫長而痛苦的過程，終於是再度迎來了完美的時代，不斷的增加webserver就可以支撐越來越高的訪問量了，對於大型網站而言，人氣的重要毋庸置疑，隨著人氣的越來越高，各種各樣的功能需求也開始爆發性的增長，這個時候突然發現，原來部署在webserver上的那個web應用已經非常龐大了，當多個團隊都開始對其進行改動時，可真是相當的不方便，復用性也相當糟糕，基本是每個團隊都做了或多或少重復的事情，而且部署和維護也是相當的麻煩，因為龐大的應用包在N台機器上復制、啟動都需要耗費不少的時間，出問題的時候也不是很好查，另外一個更糟糕的狀況是很有可能會出現某個應用上的bug就導致了全站都不可用，還有其他的像調優不好操作（因為機器上部署的應用什麼都要做，根本就無法進行針對性的調優）等因素，根據這樣的分析，開始痛下決心，將系統根據職責進行拆分，於是一個大型的分布式應用就誕生了，通常，這個步驟需要耗費相當長的時間，因為會碰到很多的挑戰：
1、拆成分布式後需要提供一個高性能、穩定的通信框架，並且需要支持多種不同的通信和遠程調用方式；
2、將一個龐大的應用拆分需要耗費很長的時間，需要進行業務的整理和系統依賴關系的控制等；
3、如何運維（依賴管理、運行狀況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分布式應用。
經過這一步，差不多系統的架構進入相對穩定的階段，同時也能開始採用大量的廉價機器來支撐著巨大的訪問量和數據量，結合這套架構以及這么多次演變過程吸取的經驗來採用其他各種各樣的方法來支撐著越來越高的訪問量。
這一步涉及到了這些知識體系：
這一步涉及的知識體系非常的多，要求對通信、遠程調用、消息機制等有深入的理解和掌握，要求的都是從理論、硬體級、操作系統級以及所採用的語言的實現都有清楚的理解。
運維這塊涉及的知識體系也非常的多，多數情況下需要掌握分布式並行計算、報表、監控技術以及規則策略等等。
說起來確實不怎麼費力，整個網站架構的經典演變過程都和上面比較的類似，當然，每步採取的方案，演變的步驟有可能有不同，另外，由於網站的業務不同，會有不同的專業技術的需求，這篇blog更多的是從架構的角度來講解演變的過程，當然，其中還有很多的技術也未在此提及，像資料庫集群、數據挖掘、搜索等，但在真實的演變過程中還會藉助像提升硬體配置、網路環境、改造操作系統、CDN鏡像等來支撐更大的流量，因此在真實的發展過程中還會有很多的不同，另外一個大型網站要做到的遠遠不僅僅上面這些，還有像安全、運維、運營、服務、存儲等，要做好一個大型的網站真的很不容易
B. web程序分布式怎麼實現
這個是由中間件的集群實現的,,,tomcat,weblogic等..這些中間件能夠自動處理當前的會話信息,後端中間件自動從節點1切換到節點2,,但用戶的當前數據不會丟失..
C. 為什麼將WEB服務視為一個分布式多媒體信息系統
分布式軟體系統(Distributed Software Systems)是支持分布式處理的軟體系統,是在由通信網路互聯的多處理機體系結構上執行任務的系統。它包括分布式操作系統、分布式程序設計語言及其編譯(解釋)系統、分布式文件系統和分布式資料庫系統等。
分布式操作系統負責管理分布式處理系統資源和控制分布式程序運行。它和集中式操作系統的區別在於資源管理、進程通信和系統結構等方面。
分布式程序設計語言用於編寫運行於分布式計算機系統上的分布式程序。一個分布式程序由若干個可以獨立執行的程序模塊組成,它們分布於一個分布式處理系統的多台計算機上被同時執行。它與集中式的程序設計語言相比有三個特點：分布性、通信性和穩健性。
D. XML WEB SERVICE分布式系統優點和缺點！
分布式控制系統 (distributed control systems,簡稱DCS),又稱為分散控制系統,分散型控制系統,集散控制系統.
由多台計算機分別控制生產過程中多個控制迴路，同時又可集中獲取數據、集中管理和集中控制的自動控制系統 。分布式控制系統採用微處理機分別控制各個迴路，而用中小型工業控制計算機或高性能的微處理機實施上一級的控制 。各迴路之間和上下級之間通過高速數據通道交換信息。分布式控制系統具有數據獲取、直接數字控制、人機交互以及監控和管理等功能。分布式控制系統是在計算機監督控制系統、直接數字控制系統和計算機多級控制系統的基礎上發展起來的，是生產過程的一種比較完善的控制與管理系統。在分布式控制系統中，按地區把微處理機安裝在測量裝置與控制執行機構附近，將控制功能盡可能分散，管理功能相對集中 。這種分散化的控制方式能改善控制的可靠性，不會由於計算機的故障而使整個系統失去控制。當管理級發生故障時，過程式控制制級（控制迴路）仍具有獨立控制能力，個別控制迴路發生故障時也不致影響全局。與計算機多級控制系統相比 ，分布式控制系統在結構上更加靈活、布局更為合理和成本更低。
分散型控制系統（DCS）是以微處理機為基礎，以危險分散控制，操作和管理集中為特性，集先進的計算機技術、通訊技術、CRT技術和控制技術即4C技術於一體的新型控制系統。隨著現代計算機和通訊網路技術的高速發展，DCS正向著多元化、網路化、開放化、集成管理方向發展，使得不同型號的DCS可以互連，進行數據交換，並可通過乙太網將DCS系統和工廠管理網相連，實現實時數據上網，成為過程工業自動控制的主流。
近幾年來，生產行業進一步提高了工廠綜合自動化水平，注重信息化的建設，特別是各地的火電廠紛紛提出適合自己工廠的廠級監控信息系統（SIS）以提高生產效率，實現工廠管理信息系統與各種分散控制系統之間的數據交換。廠級實時監控信息系統以分散控制系統為基礎，以經濟運行和提高發電企業整體效益為目的，採用先進、適用、有效的專業計算方法，實現整個電廠范圍內信息共享，廠級生產過程的實時信息監控和調度，同時又提高了機組運行的可靠性。它為電廠管理層的決策提供真實、可靠的實時運行數據，為市場運作下的企業提供科學、准確的經濟性指標。
DCS是分散控制系統（Distributed Control System）的簡稱，國內一般習慣稱為集散控制系統。它是一個由過程式控制制級和過程監控級組成的以通信網路為紐帶的多級計算機系統，綜合了計算機（Computer）、通訊（Communication）、顯示（CRT）和控制（Control）等4C技術，其基本思想是分散控制、集中操作、分級管理、配置靈活、組態方便。DCS具有以下特點：
（1）高可靠性
由於DCS將系統控制功能分散在各台計算機上實現，系統結構採用容錯設計，因此某一台計算機出現的故障不會導致系統其它功能的喪失。此外，由於系統中各台計算機所承擔的任務比較單一，可以針對需要實現的功能採用具有特定結構和軟體的專用計算機，從而使系統中每台計算機的可靠性也得到提高。
（2）開放性
DCS採用開放式、標准化、模塊化和系列化設計，系統中各台計算機採用區域網方式通信，實現信息傳輸，當需要改變或擴充系統功能時，可將新增計算機方便地連入系統通信網路或從網路中卸下，幾乎不影響系統其他計算機的工作。
（3）靈活性
通過組態軟體根據不同的流程應用對象進行軟硬體組態，即確定測量與控制信號及相互間連接關系、從控制演算法庫選擇適用的控制規律以及從圖形庫調用基本圖形組成所需的各種監控和報警畫面，從而方便地構成所需的控制系統。
（4）易於維護
功能單一的小型或微型專用計算機，具有維護簡單、方便的特點，當某一局部或某個計算機出現故障時，可以在不影響整個系統運行的情況下在線更換，迅速排除故障。
（5）協調性
各工作站之間通過通信網路傳送各種數據，整個系統信息共享，協調工作，以完成控制系統的總體功能和優化處理。
（6）控制功能齊全
控制演算法豐富，集連續控制、順序控制和批處理控制於一體，可實現串級、前饋、解耦、自適應和預測控制等先進控制，並可方便地加入所需的特殊控制演算法。
DCS的構成方式十分靈活，可由專用的管理計算機站、操作員站、工程師站、記錄站、現場控制站和數據採集站等組成，也可由通用的伺服器、工業控制計算機和可編程式控制制器構成。
處於底層的過程式控制制級一般由分散的現場控制站、數據採集站等就地實現數據採集和控制，並通過數據通信網路傳送到生產監控級計算機。生產監控級對來自過程式控制制級的數據進行集中操作管理，如各種優化計算、統計報表、故障診斷、顯示報警等。隨著計算機技術的發展，DCS可以按照需要與更高性能的計算機設備通過網路連接來實現更高級的集中管理功能，如計劃調度、倉儲管理、能源管理等。
1975年美國霍尼韋爾(Honey Well)第一套分布式控制系統TDCS-2000問世以來，分布式控制系統已經在工業控制的各個領域得到了廣泛的應用，以其高度的可靠性、方便的組態軟體、豐富的控制演算法、開放的聯網能力，逐漸成為過程工業自動控制的主流系統。
迄今，全世界數百家廠商已經開發了各種類型的分布式控制系統1500餘種，DCS 以其先進、可靠、靈活和操控簡便以及合理的價格而得到廣大工業用戶的青睞，廣泛應用於冶金、電力、化工、石油和造紙等工業領域。
E. 如何區分分布式web和非分布式web系統，試說明兩者的可能的應用場合
1.這個涉及到的范圍太廣，從整體設計上來說，你需要有個成熟穩定的架構，可以借鑒現有的，比如淘寶商城等，其次資料庫的設計、服務端架構的設計、編程語言的選擇、系統安全性、服務端的負載均衡等，都需要你了解，有些部分甚至需要熟練掌握。
2.web管理系統的概念也很大，尤其涉及到分布式，牽涉到的方方面面，都非常考驗項目經理和架構師的功力，如果個人開發的話，個人建議你還是找個現有的項目參考（目前個人的某些項目由於企業的原因無法公開，只能你自己找了）。
3.具體細節的問題，像數據同步，網路訪問安全機制等更需要注意，最好你能跟業內的專業人士做深入交流。
F. websphere 分布式計算和架構是怎麼實現的
介紹
分布式計算簡單來說，是把一個大計算任務拆分成多個小計算任務分布到若乾颱機器上去計算，然後再進行結果匯總。 目的在於分析計算海量的數據，從雷達監測的海量歷史信號中分析異常信號(外星文明)，淘寶雙十一實時計算各地區的消費習慣等。
海量計算最開始的方案是提高單機計算性能，如大型機，後來由於數據的爆發式增長、單機性能卻跟不上，才有分布式計算這種妥協方案。 因為計算一旦拆分，問題會變得非常復雜，像一致性、數據完整、通信、容災、任務調度等問題也都來了。
舉個例子，產品要求從資料庫中100G的用戶購買數據，分析出各地域的消費習慣金額等。 如果沒什麼時間要求，程序員小明就寫個對應的業務處理服務程序，部署到伺服器上，讓它慢慢跑就是了，小明預計10個小時能處理完。 後面產品嫌太慢，讓小明想辦法加快到3個小時。
平常開發中類似的需求也很多，總結出來就是，數據量大、單機計算慢。 如果上Hadoop、storm之類成本較高、而且有點大才小用。 當然讓老闆買更好的伺服器配置也是一種辦法。
利用分片演算法
小明作為一個有追求有理想的程序員，決定用介於單機計算和成熟計算框架的過度解決方案，這樣成本和需求都能滿足了。 分布式計算的核心在於計算任務拆分，如果數據能以水平拆分的方式，分布到5台機器上，每台機器只計算自身的1/5數據，這樣即能在3小時內完成產品需求了。
如上所述，小明需要把這些數據按照一定維度進行劃分。 按需求來看以用戶ID劃分最好，由於用戶之間沒有狀態上的關聯，所以也不需要事務性及二次迭代計算。 小明用簡單的hash取模對id進行劃分。
f(memberid) % 5 = ServerN
這樣程序可以分別部署到5台機器上，然後程序按照配置只取對應余數的用戶id，計算出結果並入庫。 這種方式多機之間毫無關聯，不需要進行通信，可以避免很多問題。 機器上的程序本身也不具備分布式的特性，它和單機一樣，只計算自身獲取到的數據即可，所以如果某台機器上程序崩潰的話，處理方式和單機一樣，比如記錄下處理進度，下次從當前進度繼續進行後續計算。
利用消息隊列
使用分片方式相對比較簡單，但有如下不足之處。
它不具有負載均衡的能力，如果某台機器配置稍好點，它可能最先計算完，然後空閑等待著。也有可能是某些用戶行為數據比較少，導致計算比較快完成。
還有一個弊端就是每台機器上需要手動更改對應的配置， 這樣的話多台機器上的程序不是完全一樣的，這樣可以用遠程配置動態修改的辦法來解決。
小明這種方式引入了個第三方，消息隊列。 小明先用一個單獨的程序把用戶信息推送到消息隊列里去，然後各台機器分別取消費這個隊列。 於是就有了3個角色：
推送消息的，簡稱Master。
消息隊列，這里以Rabbitmq為例。
各個處理程序，簡稱Worker或Slave都行。
雖然僅僅引入了個第三方，但它已經具備了分布式計算的很多特性。
計算任務分發。 Master把需要計算的用戶數據，不斷的推送消息隊列。
程序一致性。 Worker訂閱相同的消息隊列即可，無需更改程序代碼。
任意擴容。 由於程序完全一樣，意味著如果想要加快速度，重復部署一份程序到新機器即可。 當然這是理論上的，實際當中會受限於消息隊列、資料庫存儲等。
容災性。 如果5台中某一台程序掛了也不影響，利用Rabbitmq的消息確認機制，機器崩潰時正在計算的那一條數據會在超時，在其他節點上進行消費處理。
Hadoop簡介
Hadoop介紹已經相當多了，這里簡述下比如:」Hadoop是一套海量數據計算存儲的基礎平台架構」，分析下這句話。
其中計算指的是MapRece，這是做分布式計算用的。
存儲指的是HDFS，基於此上層的有HBase、Hive，用來做數據存儲用的。
平台，指可以給多個用戶使用，比如小明有一計算需求，他只需要按照對應的介面編寫業務邏輯即可，然後把程序以包的形式發布到平台上，平台進行分配調度計算等。 而上面小明的分布式計算設計只能給自己使用，如果另外有小華要使用就需要重新寫一份，然後單獨部署，申請機器等。Hadoop最大的優勢之一就在於提供了一套這樣的完整解決方案。
下面找了介紹Hadoop的概覽圖，跟小明的設計做對比下:
圖中「大數據計算任務」 對應小明的100G用戶數據的計算任務。
」任務劃分「 對應Master和消息隊列。
「子任務」 對應Worker的業務邏輯。
」結果合並「 對應把每個worker的計算結果入庫。
「計算結果」 對應入庫的用戶消費習慣數據。
PS：為了方便描述，把小明設計的分布式計算，叫做小和尚。
MapRece
由於MapRece計算輸入和輸出都是基於HDFS文件，所以大多數公司的做法是把mysql或sqlserver的數據導入到HDFS，計算完後再導出到常規的資料庫中，這是MapRece不夠靈活的地方之一。 MapRece優勢在於提供了比較簡單的分布式計算編程模型，使開發此類程序變得非常簡單，像之前的MPI編程就相當復雜。
狹隘的來講，MapRece是把計算任務給規范化了，它可以等同於小和尚中Worker的業務邏輯部分。 MapRece把業務邏輯給拆分成2個大部分，Map和Rece，可以先在Map部分把任務計算一半後，扔給Rece部分繼續後面的計算。 當然在Map部分把計算任務全做完也是可以的。 關於Maprece實現細節部分不多解釋，有興趣的同學可以查相關資料或看下樓主之前的C#模擬實現的博客【探索C#之微型MapRece】。
如果把小明產品經理的需求放到Hadoop來做，其處理流程大致如下：
把100G數據導入到HDFS
按照Maprece的介面編寫處理邏輯，分Map、Rece兩部分。
把程序包提交到Maprece平台上，存儲在HDFS里。
平台中有個叫Jobtracker進程的角色進行分發任務。 這個類似小和尚的Master負載調度管理。
如果有5台機器進行計算的話，就會提前運行5個叫TaskTracker的slave進程。 這類似小和尚worker的分離版，平台把程序和業務邏輯進行分離了， 簡單來說就是在機器上運行個獨立進程，它能動態載入、執行jar或dll的業務邏輯代碼。
Jobtracker把任務分發到TaskTracker後，TaskTracker把開始動態載入jar包，創建個獨立進程執行Map部分，然後把結果寫入到HDFS上。
如果有Rece部分，TaskTracker會創建個獨立進程把Map輸出的HDFS文件，通過RPC方式遠程拉取到本地，拉取成功後，Rece開始計算後續任務。
Rece再把結果寫入到HDFS中
從HDFS中把結果導出。
這樣一看好像是把簡單的計算任務給復雜化了，其實如果只有幾台計算任務的話，使用Maprece確實是殺雞用牛刀了。 如果有TB、PB級別的數據、跑在成百上千台計算節點上，Maprece的優勢才會體現出來。 其計算框架圖架構如下：
離線計算
通常稱Maprece及小和尚這種計算為離線計算，因為它對已經持久化的文件數據進行計算，不能實時響應。 還有個原因就是它的處理速度比較慢，它的輸入和輸出源都是基於HDFS設計，如果數據不是一開始就寫入到HDFS上，就會涉及到數據導入導出，這部分相對耗費時間。 而且它的數據流動是基於文件系統的，Map部分輸出的數據不是直接傳送到Rece部分，而是先寫入HDFS再進行傳送。
處理速度慢也是Maprece的不足之處，促使了後面實時計算的誕生。
另外個缺點是Maprece的計算任務流比較單一，它只有Map、Rece兩部分。 簡單的可以只寫一部分邏輯來解決，如果想拆分成多個部分，如邏輯A、邏輯B、邏輯C等， 而且一部分計算邏輯依賴上一次計算結果的話，MapRece處理起來就比較困難了。 像storm框架解決此類問題的方案，也稱為流式計算，下一章繼續補充。
G. 3. Web是一個以圖形化界面提供全球性、跨平台的( )和( )的分布式圖形信息系統
web（World Wide Web）即全球廣域網，也稱為萬維網，它是一種基於超文本和HTTP的、全球性的、動態交互的、跨平台的分布式圖形信息系統。是建立在Internet上的一種網路服務，為瀏覽者在Internet上查找和瀏覽信息提供了圖形化的、易於訪問的直觀界面，其中的文檔及超級鏈接將Internet上的信息節點組織成一個互為關聯的網狀結構。
拓展資料：
web的特點
（1）圖形化
Web 非常流行的一個很重要的原因就在於它可以在一頁上同時顯示色彩豐富的圖形和文本的性能。在Web之前Internet上的信息只有文本形式。Web可以提供將圖形、音頻、視頻信息集合於一體的特性。
（2）與平台無關
無論用戶的系統平台是什麼，你都可以通過Internet訪問WWW。瀏覽WWW對系統平台沒有什麼限制。無論從Windows平台、UNIX平台、Macintosh等平台我們都可以訪問WWW。對WWW的訪問通過一種叫做瀏覽器（browser）的軟體實現。如Mozilla的Firefox、Google的Chrome、Microsoft的Internet Explorer等。
（3）分布式的
大量的圖形、音頻和視頻信息會佔用相當大的磁碟空間，我們甚至無法預知信息的多少。對於Web沒有必要把所有信息都放在一起，信息可以放在不同的站點上，只需要在瀏覽器中指明這個站點就可以了。在物理上並不一定在一個站點的信息在邏輯上一體化，從用戶來看這些信息是一體的。
（4）動態的
由於各Web站點的信息包含站點本身的信息，信息的提供者可以經常對站上的信息進行更新。如某個協議的發展狀況，公司的廣告等等。一般各信息站點都盡量保證信息的時間性。所以Web站點上的信息是動態的、經常更新的，這一點是由信息的提供者保證的。
（5）交互的
Web的交互性首先表現在它的超鏈接上，用戶的瀏覽順序和所到站點完全由他自己決定。另外通過FORM的形式可以從伺服器方獲得動態的信息。用戶通過填寫FORM可以向伺服器提交請求，伺服器可以根據用戶的請求返回相應信息。
H. java分布式web系統如何做分布式事務控制
用過spring沒，用Spring的AOP技術能很好的將事物隔離出來。 Spring聲明式事務讓我們從復雜的事務處理中得到解脫。 使得我們再也無需要去處理獲得連接、關閉連接、事務提交和回滾等這些操作。再也無需要我們在與事務相關的方法中處理大量的try…catch…finally代碼。
I. web是什麼意思
web是互聯網的總稱，即全球廣域網，也稱為萬維網，它是一種基於超文本和HTTP的、全球性的、動態交互的、跨平台的分布式圖形信息系統。
web是建立在Internet上，可以為瀏覽者在Internet上查找和瀏覽信息提供了圖形化的界面，其中的文檔及超級鏈接將Internet上的信息節點組織成一個互為關聯的網狀結構。
web分為Web客戶端和Web伺服器程序。 WWW可以讓Web客戶端（常用瀏覽器）訪問瀏覽Web伺服器上的頁面。
(9)web分布式系統擴展閱讀：
Web的一個主要的概念是超文本鏈接。它使得文本不再像一本書一樣是固定的線性的，而是可以從一個位置跳到另外的位置並從中獲取更多的信息，還可以轉到別的主題上。
想要了解某一個主題的內容只要在這個主題上點一下，就可以跳轉到包含這一主題的文檔上。正是這種多連接性把它稱為Web。