① 什麼是分布式系統
分布式系統是一個硬體或軟體組件分布在不同的網路計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。
正是因為軟體的特性，所以分布式系統具有高度的內聚性和透明性。因此，網路和分布式系統之間的區別更多的在於高層軟體（特別是操作系統），而不是硬體。
(1)分布式如何配置資源擴展閱讀
分布式系統系統優點
1、經濟：微處理機提供了比大型主機更好的性能價格比
2、速度：分布式系統總的計算能力比單個大型主機更強
3、固有的分布性：一些應用涉及到空間上分散的機器
4、可靠性：如果一個機器崩潰,整個系統還可以運轉
5、漸增：計算能力可以逐漸有所增加
② java的框架spring如何配置分布式事務
分布式事務本身不是程序做的，我們不需要在代碼中明確地做這些事，因為是不是分布式對於代碼來說，代碼寫起來完全相同。
只是選擇支持 JTA XA （也叫 2-Phase Commit, 2PC) 的數據源就可以了，你默認使用的 DataSource 可能不是 XA ( Weblogic 把它叫 TX）。
一般在網站編程時多數人可能是用 Spring 搭配 tomcat commons-dbcp 那個數據源，那個可能就不是支持 XA 的數據源，如果你打算在復雜企業應用生態系統中使用J2EE 就不要用 Spring 提供 commonbs-dbcp 那種小作坊式的做法，因為它是假設自己的程序就是獨立生態系統，當你需要與外界打交道時就碰到諸多問題，這也是為什麼很多大企業依然還是會使用 EJB 的原因（EJB 已經考慮到這點，並把它寫入到J2EE 標准中），我們推薦用伺服器自己的數據源，也就是 lookup JNDI，這樣的話，是不是 XA 事務就由伺服器的配置來定製，代碼就不需要任何配置來決定是不是 XA 了 ；事務本身是不是 XA (分布式的）是伺服器的事，伺服器來管理「資源」 （包括數據源，JMS 連接等，一個資源（JDBC連接）如何參與事務是「資源管理器」（驅動程序）的職責，跟程序無關），伺服器提供事務管理並作為「事務協調者」來處理多個「資源管理器」（不同的資料庫連接）之間的事務一致性，，而 Spring 的職責很簡單，對於我們希望 Spring 自動提交或回滾事務時，在配置中指定需要回滾的異常的類型。
不過我沒有實際使用過 Spring，我有多年的 EJB 經驗，這其中的原理是相同的，因為這是 J2EE 標准規范要求達到的。
③ 怎麼搭建分布式伺服器
如何搭建分布式網站伺服器，比如我有3台伺服器ABC，需要搭建分布式服務。也就需要建立IIS 還由DNS WIN 伺服器的 還有更改主機名 很麻煩的,這個需要專業的IT人員來操作的。
以下資料作為參考：
DNS輪循
首先介紹一個DNS系統:傳統的DNS解析都是一個域名對應一個IP地址,但是通過DNS輪循技術(負載平衡技術)可以做到一個域名對應到多個IP 上. 這樣大家難免就會問,這個技術有什麼用呢?
DNS輪循是指將相同的域名解釋到不同的IP，隨機使用其中某台主機的技術,該項技術可以智能的調整網站的訪問量到不同伺服器上，減輕網站伺服器的壓力，實現負載勻衡;如果您感覺到單一的主機已經不堪負載你網站日益增長的訪問，那麼建議您採用我們的DNS輪循技術。
DNS輪循系統可以根據您的需求設置N台主機作為WEB伺服器。目前已有越來多大型的WEB伺服器使用DNS輪循來實現負載均衡，服務的分布規劃更便捷，擴展性更好，從而提高了網站的穩定性和訪問效率，那些大量數據文件請求的客戶也得到了更快的響應。
DNS輪循還將給您的網站提供這樣的改進，諸如您的網站的數據使用量一直處於不斷的增長當中，當達到伺服器資源運行瓶頸的情況
下，由於採用了DNS輪循技術，您只需要增加伺服器數量就可以平滑升級，而且偶然故障或其他意外情況造成的損失得以避免，7×24小時可靠性的持續的運行
成為可能。
如果您真的希望自己的網站能夠一直穩定的在線運行，盡量的減少宕機的比率，那麼除了採用比較好的網站空間技術支持之外，還可以採用時代互聯域名的DNS輪循功能來實現網站的永久在線負載平衡
負載均衡是由多台伺服器以對稱的方式組成一個伺服器集合，每台伺服器都具有等價的地位，都可以單獨對外提供服務而無須其
他伺服器的輔助。通過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一台伺服器上，而接收到請求的伺服器獨立地回應客戶的請求。均衡負載
能夠平均分配客戶請求到伺服器列陣，籍此提供快速獲取重要數據，解決大量並發訪問服務問題。這種群集技術可以用最少的投資獲得接近於大型主機的性能。
網路負載均衡的優點
第一，網路負載均衡能將傳入的請求傳播到多達32台伺服器上，即可以使用最多32台伺服器共同分擔對外的網路請求服務。網路負載均衡技術保證即使是在負載很重的情況下，伺服器也能做出快速響應;
第二，網路負載均衡對外只需提供一個IP地址(或域名);
第三，當網路負載均衡中的一台或幾台伺服器不可用時，服務不會中斷。網路負載均衡自動檢測到伺服器不可用時，能夠迅速在剩餘的
伺服器中重新指派客戶機通訊。這項保護措施能夠幫助你為關鍵的業務程序提供不中斷的服務，並可以根據網路訪問量的增加來相應地增加網路負載均衡伺服器的數
量;
第四，網路負載均衡可在普通的計算機上實現。
網路負載均衡的實現過程
在Windows Server 2003中，網路負載均衡的應用程序包括Internet信息服務(IIS)、ISA
Server 2000防火牆與代理伺服器、VPN虛擬專用網、終端伺服器、Windows Media
Services(Windows視頻點播、視頻廣播)等服務。同時，網路負載均衡有助於改善伺服器的性能和可伸縮性，以滿足不斷增長的基於
Internet客戶端的需求。
網路負載均衡可以讓客戶端用一個邏輯Internet名稱和虛擬IP地址(又稱群集IP地址)訪問群集，同時保留每台計算機各自的名稱。下面，我們將在兩台安裝Windows Server 2003的普通計算機上，介紹網路負載均衡的實現及應用。
這兩台計算機中，一台計算機名稱為A，IP地址為192.168.0.7;另一台名為B，IP地址為192.168.0.8。
規劃網路負載均衡專用虛擬IP地址為192.168.0.9。當正式應用時，客戶機只需要使用IP地址192.168.0.9來訪問伺服器，網路服務均衡
會根據每台伺服器的負載情況自動選擇192.168.0.7或者192.168.0.8對外提供服務。具體實現過程如下：
在實現網路負載均衡的每一台計算機上，只能安裝TCP/IP協議，不要安裝任何其他的協議(如IPX協議或者NetBEUI協議)，這可以從「網路連接屬性」中查看。
第一步，分別以管理員身份登錄A機和B機，打開兩台機的「本地連接」屬性界面，勾選「此連接使用下列項目」中的「負載均衡」項並進入「屬性」對話框，將IP地址都設為192.168.0.9(即負載均衡專用IP)，將子網掩碼設置為255.255.255.0;
第二步，分別進入A機和B機的「Internet協議(TCP/IP)」屬性設置界面，點擊「高級」按鈕後，在彈出的「高級TCP/IP設置」界面中添加IP地址192.168.0.9和子網掩碼設置為255.255.255.0。
第三步，退出兩台計算機的「本地連接屬性」窗口，耐心等一會兒讓系統完成設置。
以後，如果這兩台伺服器不能滿足需求，可以按以上步驟添加第三台、第四台計算機到網路負載均衡系統中以滿足要求。
④ 如何 配置 NET 下的 分布式系統
至開發上的一個巨大進步，.net程序員以對象方式操作數據，以類sql語法在程序里查詢數據，大大減少了繁瑣的構造SQL語句的工作，可以更加專注於編寫業務邏輯代碼。但是在多層架構的分布式應用系統中，實體對象通過遠程序列化到客戶端時，這些實體會與其數據上下文(也就是實體容器)分離，在客戶端無法對實體直接進行查詢以及CUD(Create,Update,Delete)操作，下面以SQL Server為資料庫，Remoting+Entity Framework3.5作為數據服務層，WinForm作為客戶端，講述一下如何使用EF框架搭建多層分布式應用系統。 二、 技術分析 1. 通過遠程客戶端傳輸過來的實體，都是處於分離狀態(EntityState屬性值為Detached)，所以在多層應用程序中的服務端實現實體的更新或刪除時，關鍵是如何把實體附加回實體容器中。MSDN上關於對分離實體的查詢和CUD操作描述如下: 1) 附加對象(實體框架) 在實體框架的某個對象上下文內執行查詢時，返回的對象會自動附加到該對象上下文。還可以將從源而不是從查詢獲得的對象附加到對象上下文。您可以附加以前分離的對象、由 NoTracking 查詢返回的對象或從對象上下文的外部獲取的對象。還可以附加存儲在 ASP.NET 應用程序的視圖狀態中的對象或從遠程方法調用或 Web 服務返回的對象。 使用下列方法之一將對象附加到對象上下文: · 調用 ObjectContext 上的 AddObject 將對象附加到對象上下文。當對象為數據源中尚不存在的新對象時採用此方法。 · 調用 ObjectContext上的Attach 將對象附加到對象上下文。當對象已存在於數據源中但當前尚未附加到上下文時採用此方法。有關更多信息，請參見如何:附加相關對象(實體框架)。 · 調用 ObjectContext的AttachTo，以將對象附加到對象上下文中的特定實體集。如果對象具有 null(在 Visual Basic 中為 Nothing)EntityKey 值，也可以執行此操作。 · 調用 ObjectContext上的ApplyPropertyChanges。當對象已存在於數據源中，並且分離的對象具有您希望保存的屬性更新時採用此方法。如果簡單地附加該對象，則屬性更改將丟失。有關更多信息，請參見如何:應用對已分離對象的更改(實體框架)。 2) 應用對已分離對象的更改(實體框架)示例代碼 View Code 2. 實現動態條件查詢。在本地環境中，對於Linq，我們可以通過動態構造Lambda表達式樹來實現動態條件查詢，但是在遠程環境中，Lamdba表達式不支持遠程序列化傳輸，只能通過ObjectContext的CreateQuery方法實現，但幸好微軟後來又提供了一個LINQ動態查詢擴展庫Dynamic.cs，使用起來更方便,於是採用它實現。 3. EF中核心抽象類是ObjectContext,實體容器都從它派生，實體容器上的CUD方法其實都是通過調用ObjectContext的CUD操作方法實現的。1) AddObject(string,object):表示添加實體object到實體容器，只要實體的EntityKey值為空，無論是否Detached狀態均可以通過此方法實現添加操作。2) ApplyPropertyChanges(string,object)表示把分離狀態的實體object上的所作的修改更新回容器中已存在的對應的實體，執行條件有兩個:①實體處於分離狀態，②實體容器中存在主鍵值與其相同的且為Unchanged狀態的實體,所以，當我們需要更新一個Detached狀態的實體時，可以先把一個具有原始值的相同鍵值的實體附加回容器中，或者直接執行一下查詢，從資料庫中取出該實體。3) DeleteObject(object)表示從實體容器中刪除一個實體,執行條件是該實體存在於實體容器中,所以刪除一個Detach狀態的實體之前，需要把它通過Attach方法附加回實體容器中。 4. 實體對象也是基於抽象類EntityObject派生的，由此我們完全可以用ContextObject和EntityObject實現服務端對實體的查詢和CUD方法，其實現子類在運行時由客戶端注入，從而使服務端和資料庫實現松耦合。 5. 下圖是MSDN上關於在數據訪問層中使用 LINQ to SQL 的 n 層應用程序的基本體系結構圖，其實EF的結構也是一樣的，不過是把DataContext換成ObjectContext。 三、 動手開發 1. 利用EF建立資料庫概念模型新建一個解決方案EFServiceSystem，添加一個新項目，命名為EFModel,添加項目，在項目下添加一個ADO.NET Entity Data Model項，命名為EFModel.edmx,選擇從資料庫生成(假設我們已經建好了一個SQL Server資料庫)，一路點擊下一步，直至完成。編譯項目成功後就算完成。為什麼要把資料庫模型單獨編譯成一個dll呢，我將在後面給予解釋。 2. 建立數據服務層在解決方案下再添加一個類庫項目，命名為EFService。1) 利用外觀模式，我們把客戶端常用的查詢和CUD操作方法簡化為3個方法Query<T>,Save(T t),Delete(T t)，根據針對介面編程的設計原則，定義一個CUD方法介面供客戶端調用。 View Code 2) 實現類EntityHelper的代碼。主要思路是通過構造函數注入數據上下文實例名稱，在配置文件取出其程序集限定名，通過反射創建實例，調用實例的相應方法實現介面。 View Code 3) 最後，我們創建一個服務工廠類，暴露給客戶端，負責以介面方式向客戶端提供遠程服務對象，數據服務層創建完畢。 View Code 4) 補充一下Dynamic.cs的內容，省得你去網上找了View Code 3. 創建運行服務的宿主程序。實際開發中，通常選擇創建一個windows服務程序來運行Remoting，但是服務需要安裝才能啟動，運行和調試起來都比較繁瑣，所以這里創建一個簡單的控制台程序來運行它。在解決方案下添加一個控制台程序項目，在program.cs編寫如下代碼: View Code 配置文件App.Config主要包括資料庫連接信息以及自己定義一個數據上下文名稱(這里和資料庫連接名稱相同，事實上不必相同)，資料庫連接信息可以從EFModel項目中配置文件中直接拷貝過來。內容如下: View Code 編譯成功後，拷貝EFModel和和EFService兩個項目生成的dll文件至可執行文件EFServiceHost.exe同一目錄下，點擊運行EFServiceHost.exe。 4. 最後，我們建立一個winform客戶端作為測試。在program.cs注冊遠程服務: View Code 四、 部署應用 1. 至此，整個系統搭建完畢。在本例中，我把所有項目都統一建立在一個解決方案下，其實是為了演示方便，實際開發時候，完全可以各自獨立創建。下面我們來分析一下各個項目的職能和相互之間的引用關系。 1) EFModel:由Visual Studio 的數據模型工具生成的資料庫實例模型，提供數據的查詢以及CUD操作。不需引用其它項目。 2) EFService:使用資料庫實例模型以及實體的抽象基類編寫完成，代碼里不涉及具體資料庫模型實例，運行時通過客戶端注入參數和讀取配置文件動態生成資料庫模型實例，並調用實例的查詢和CUD方法實現客戶端的請求。不需引用其它項目。 3) EFServiceHost:負責運行Remoting服務，如果通過配置文件方式發布服務的話，編譯時也不需引用其它項目，我這里引用了EFService項目，是因為使用了代碼方式暴露EFSservice的服務類。運行時需要將EFService和EFModel的dll文件拷貝至運行目錄下。 4) EFClient:需要引用EFModel和EFService。(注:因為本例中式使用了Remoting作為遠程服務，如果是WebService或者WCF則只需添加服務引用，然後在本地生成客戶端代理類)。事實上EFService中的實現類EntityHelper也可以獨立出去，不必讓客戶端引用，對於客戶端而言，僅僅是使用ServiceFactory和介面IentityHelper就足夠了。這樣只要介面不變，EntityHelper更新的時候，客戶端無須更新引用，而且服務端代碼可以完全被隔離開客戶端，對一些服務端和客戶端之間的保密性比較敏感的項目尤為有利。 2. 通過分析我們發現，在開發下一個新項目的時候，即使整個資料庫都變了，從SQL SERVER變成Oracle，資料庫服務名變了，表也變了，我們仍然無需修改服務端代碼，只需針對新的資料庫，生成新的EFModel，然後拷貝DLL文件至EFServiceHost的運行目錄下(這也就是我為什麼要把EFModel獨立成一個項目的原因)，再修改一下EFServiceHost的配置文件中的資料庫連接和實體容器名稱即可完成新系統的部署。對於客戶端來說，也就是更新一下EFModel.dll，還是調用服務端提供的那幾個API，便可完成查詢和CUD操作，不用關心底層的資料庫是SQL Server還是Oracle，更不用自己實現對新庫新表的查詢和CUD操作(本來也不用)。當然，對於正在運行的系統，我們也可以針對新建資料庫生成新的實體模型DLL，拷貝至EFServiceHost運行目錄下，實現熱插拔方式擴展資料庫，而對原來的系統毫無影響，即使新加的庫是不同類型的庫。 五、 系統架構圖示 六、 總結 從以上分析可以看出，該系統運用到項目開發中，對服務端來說，實現了最大程度組件重用(零代碼修改)，對客戶端開發來說，高度簡化了對數據的操作命令，並封裝了實現細節,大大降低了開發的技術難度，提高了開發速度。當然，我這里寫的代碼僅僅是最簡單的演示代碼，在實際項目開發中，服務端要處理的細節和擴展的功能要比這復雜得多。比如性能優化，實現復雜查詢和批量CUD操作，並發處理，事務控制，日誌跟蹤，數據緩存等等。另外，如果各層採用不同的技術實現，服務層實現的代碼也有差異。比如EF可以選擇最新版的更完善更強大的EF4.0，遠程服務可以選擇Remoting,WebService,WCF等，不同的遠程服務，宿主程序也有所不同，Remoting和WCF可以選擇winform，控制台程序，IIS，而Web Service只能選擇IIS。不同的服務，不同的宿主程序，會有不同的通信通道 (Http,Tcp),不同的數據傳輸格式 (二進制，XML,JSON)。如果你嫌上面的實現方式涉及的技術太多，開發起來太麻煩，那麼，微軟現成的具有REST風格的遠程數據服務WCF Data Services會是你的最佳選擇。
⑤ 如何配置ceph分布式存儲方案
1、對象存儲：即radosgw,兼容S3介面。通過rest api上傳、下載文件。
2、文件系統：posix介面。可以將ceph集群看做一個共享文件系統掛載到本地。
3、塊存儲：即rbd。有kernel rbd和librbd兩種使用方式。支持快照、克隆。相當於一塊硬碟掛到本地，用法和用途和硬碟一樣。
⑥ 什麼叫分布式事務，在SQL Server中如何配置
MSDTC(Microsoft Distributed Transaction Coordinator)中文叫微軟分布式事務處理協調器，負責WINDOWS平台的分布式事務處理。SQL SERVER的事務如果需要和本資料庫之外（包括別的資料庫）的事務協同完成同一個事務，那麼就需要MSTDC來掌控，否則SQL SERVER的事務就是普通的本地資料庫事務，和MSDTC沒有關系，資料庫自身就能處理了。
很多組織機構慢慢的在不同的伺服器和地點部署SQL Server資料庫——為各種應用和目的——開始考慮通過SQL Server集群的方式來合並。
將SQL Server實例和資料庫合並到一個中心的地點可以減低成本，尤其是維護和軟硬體許可證。此外，在合並之後，可以減低所需機器的數量，這些機器就可以用於備用。
當尋找一個備用，比如高可用性的環境，企業常常決定部署Microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)SQL Server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後，我讓你們自己做決定。
什麼是Microsoft集群伺服器
MSCS是一個Windows Server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」，來獲得更高的可用性和對數據和應用更簡便的管理。MSCS可以自動的檢查到伺服器或者應用的失效，並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。
這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中，它會自動將資源(比如磁碟和IP地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性，比如站點全面失效的情況下。
MSCS不要求在客戶計算機上安裝任何特殊軟體，因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的，因為MSCS在相同的IP地址上重啟應用、文件共享等等。進一步，為了災難恢復，集群的節點可以處於分離的、遙遠的地點。
在集群伺服器上的SQL Server
SQL Server 2000可以配置為最多4個節點的集群，而SQL Server 2005可以配置為最多8個節點的集群。當一個SQL Server實例被配置為集群之後，它的磁碟資源、IP地址和服務就形成了集群組來實現災難恢復。
SQL Server 2000允許在一個集群上安裝16個實例。根據在線幫助，「SQL Server 2005在一個伺服器或者處理器上可以支持最多50個SQL Server實例，」但是，「只能使用25個硬碟驅動器符，因此如果你需要更多的實例，那麼需要預先規劃。」
注意SQL Server實例的災難恢復階段是指SQL Server服務開始所需要的時間，這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性，考慮使用其他的方法，比如log shipping和資料庫鏡像。
單個的大的SQL Server集群還是小的集群
下面是大的、由更多的節點組成的集群的優點：
◆更高的可用新(更多的節點來災難恢復)。
◆更多的負載均衡選擇(更多的節點)。
◆更低廉的維護成本。
◆增長的敏捷性。多達4個或者8個節點，依賴於SQL版本。
◆增強的管理性和簡化環境(需要管理的少了)。
◆更少的停機時間(災難恢復更多的選擇)。
◆災難恢復性能不受集群中的節點數目影響。
下面是單個大的集群的缺點：
◆集群節點數目有限(如果需要第9個節點怎麼辦)。
◆在集群中SQL實例數目有限。
◆沒有對失效的防護——如果磁碟陣列失效了，就不會發生災難恢復。
◆使用災難恢復集群，無法在資料庫級別或者資料庫對象級別，比如表，創建災難恢復集群。
虛擬化和集群
虛擬機也可以參與到集群中，虛擬和物理機器可以集群在一起，不會發生問題。SQL Server實例可以在虛擬機上，但是性能可能會受用影響，這依賴於實例所消耗的資源。在虛擬機上安裝SQL Server實例之前，你需要進行壓力測試來驗證它是否可以承受必要的負載。
在這種靈活的架構中，如果虛擬機和物理機器集群在一起，你可以在虛擬機和物理機器之間對SQL Server進行負載均衡。比如，使用虛擬機上的SQL Server實例開發應用。然後在你需要對開發實例進行壓力測試的時候，將它災難恢復到集群中更強的物理機器上。
集群伺服器可以用於SQL Server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境，為了負載均衡和維護，實例可以從一個節點移動到另外的節點。