前言：中文期刊網精心挑選了分布式系統設計與應用范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
分布式系統設計與應用范文1
關鍵詞：調度自動化系統；分布式部署；集中式部署；負載均衡
引 言
電網調度自動化系統中III區Web的傳統部署方案是采用普通的集中式部署和帶負載均衡的集中式部署，這種部署方案用戶使用起來簡單方便，維護人員也便于管理，對于基本的SCADA、PUBLIC和PAS等應用也能滿足要求。但在這種部署方案下，III區僅僅是I區的一個鏡像，用戶只能進行圖形、報表、曲線、數據、告警信息等的瀏覽和查詢，而無法進行進一步的分析、規劃和推演。隨著電網規模的不斷擴大化和復雜化，方式、生計、繼保等部門或專業不僅是要通過Web系統對電網進行監視，更需要能夠在當前、歷史以及各種假想的電網狀態下對電網進行分析、規劃、推演和培訓，這就需要在III區實現PAS應用中的調度員潮流、靜態安全分析、短路計算、靈敏度分析和DTS等應用。為滿足這種需求，對于規模較小、訪問客戶端較少的系統來說，仍然可以用以往的集中式部署方案，將新增的PAS應用直接部署在原有的Web服務器上。但對于網省調以及大型的地調而言，Web服務器上已經集中部署了I區的所有應用，再加上訪問客戶端數量龐大，服務器會不堪重負，隨著系統的進一步擴大和客戶端的增加，服務器上的資源最終會被耗盡，導致III區系統不可用。為解決這個問題，我們在深圳EMS系統上提出了全新的WebIII區分布式部署方案。該方案實施后將會充分利用OPEN-3000的數據資源、技術資源以及設備資源，發揮III區系統的功能，有效的節約人力維護成本及系統建設成本，極大提高了III區WEB服務的穩定性，為方便用戶使用以及管理產生效益，提供有力的技術支持和保障。
1 系統方案設計
1.1 設計目標
伴隨著計算機技術和電力系統行業的發展，III區Web服務已經得到越來越多業內人士的關注，因此，在方案設計時，我們確定了以下目標：
1） 降低原服務器的負載：通過將數據庫服務器和各應用服務器分開部署，以達到降低原服務器負載的目的，這樣，既保證在訪問客戶端較多的情況下訪問服務不受影響，又可以在III區發揮OPEN-3000強大的計算和分析功能。
2） 技術的先進性：通過對III區進行分布式部署，使得系統具備更高的性能、更優化的功能、更廣的應用范圍、更好的展示方式和更強的實用性。
3） 使用方便性和簡單易維護性：在繼續發揮原有的優勢下，使用方面，提供全面而簡潔的分層次展示方式，方便客戶端訪問系統的全局信息；維護方面，充分考慮分布式部署的特點，并實現I區數據信息的全局共享，向用戶提供完善的維護機制、信息集中展示手段、運行狀態監視工具、自動/手動修復工具等，使得系統使用簡單化，維護簡易化。
4） 安全可靠性目標：按照分布式部署方案，單列各個功能模塊，全面提高系統的穩定性和可靠性，并關注網絡安全方面的相關技術，如物理隔離、防火墻、入侵檢測、安全加固等，實施相應的安全解決方案。
5） 標準化目標：OPEN-3000系統遵循最新的國際標準，包括IEC61970、IEC61968等標準，繼續發揮在原有標準執行上的優勢，如IEC 60870-5系列、IEC 60870-6系列（TASE.2）等，同時關注將來會對系統產生影響的標準，如IEC 61850。
6） 軟硬件平立：系統支持包括ALPHA、SUN、IBM、HP在內的各種服務器，實現完善的跨平臺功能。客戶端PC機使用標準的IE6.0。
1.2 設計方案
1.2.1 集中式部署方式
III區原有的集中式部署方式如下圖所示，數據庫和各應用服務都分布在兩臺Web服務器上，通過負載均衡方式來調節兩臺Web服務器的工作效率。
圖1.2.1 WebIII區集中式部署方式
這種分布方式下III區系統管理方式的實現比較簡單，如果是一臺Web服務器，客戶端則通過指定的IP地址進行訪問，如果是兩臺負載均衡的Web服務器，客戶端則根據簡單策略來決定連哪臺服務器。
1.2.2 分布式部署方式
分布式部署方式與集中式部署方式在設計架構上有很大的區別，所有的應用不再集中于一臺或者兩臺服務器，將應用進行剝離，同時繼續選擇負載均衡的方式，這樣，既能保留集中式部署的優點，又極大地提高了III區的訪問效率。如下圖所示
從上圖可以看到，數據庫服務和各應用服務進行了有效分布，這種分布，一方面可以有效地降低原服務器的負載，提升系統的可擴展性；另外一方面，降低了各應用間的耦合程度，減少應用間對計算機資源的競爭，對于系統的管理、維護、升級以及用戶的使用都會帶來很大的好處。
2 關鍵技術
對于在III區實現分布式部署，可行的方式是在應用服務器上實現系統管理服務，同時在客戶端實現系統管理感知，通過申請和訂閱兩種方式來讓客戶端獲取III區完成的系統管理信息。
2.1 滿足客戶端對III區各項功能的統一訪問的需求
通過對Web模塊做相應的改造，使得Web服務器不再和應用服務器綁定在一起，用戶在Web客戶端將可以通過統一的地址對III區的應用服務器進行統一訪問，而不必根據各個應用的不同來切換不同的地址。
2.1.1 Web客戶端hosts文件的更新邏輯
客戶端向服務器發送corba請求時，都是以機器名作為表征的，但tcp/ip 連接最終還是把機器名翻譯成ip地址在網絡上傳送報文，這一步的實現就要靠客戶端上的hosts文件。為了讓客戶端能夠得到III區里所有服務器的ip分布，我們必須有一種機制保證每個客戶端的hosts文件中都寫入所有服務器的ip地址和主機名。一臺第一次訪問Web的客戶端僅有的信息就是Web的地址，我們將這個地址作為整個Web系統的一個標準地址，然后通過從服務端下載到本地的某些文件中記錄的主機名和與該標準地址的一個偏移量來得到整個web系統各臺服務器的真實ip和主機名的對應關系。具體實施如下，
在WEB服務器上配置了host.ini和apphost.ini這兩個配置文件，在host.ini中，分別記錄了WEB服務器的名稱以及與地址的偏移量， 例如，WEB服務器的地址為：10.10.20.1，在host.ini中，有兩條記錄：0 web1和1 web2，這說明，機器名為web1的WEB服務器的IP為10.10.20.1，而機器名為web2的WEB服務器的IP為10.10.20.2。mini_web的程序處理中，先讀取host.ini，然后按照配置的規則分別存儲主機名和其對應的IP地址，但為了提高對本機hosts文件的讀寫速度，在更新本機hosts文件的函數中，區別主機名不同IP不同，主機名相同IP不同，主機名相同IP相同這三種狀況，對于前兩種情況則需要更新本地的hosts文件，而對于最后一種情況，則無需更新hosts文件，這樣就提高了對hosts文件的讀寫速度，提高了程序的處理效率。host.ini和apphost.ini兩個文件的格式是類似的， 所不同的是， host.ini文件中記錄了多臺web服務器的主機名和偏移量，而 apphost.ini文件中記錄了多臺應用服務器的主機名和偏移量。在host.ini文件中的主機是要配置負載均衡的。
2.2在corba通訊的層面
客戶端的應用程序需要和相關應用的服務器建立網絡連接，發送請求報文，接收服務器傳回的數據報文。在建立網絡連接的時候，客戶端需要知道相關應用的服務的主機的機器名或者需要知道相關應用的最輕負荷的服務器機器名。在I區，客戶端可以通過調用系統管理相應的接口得到這些相關的信息，但是在III區的客戶端，由于不存在系統管理模塊，客戶端無法獲得這些必要的信息。在應用服務器沒有做分離之前，我們可以簡單的將對任意應用服務主機的請求都轉化成對web服務器的請求。但是一旦做了應用服務器的分離，部分應用不再運行在web服務器上，客戶機就必須知道這些信息。為此，我們在web服務器上增加了一個程序web_unique，這個程序是運行在web服務器上的常駐進程，客戶端程序在每次要獲取相關應用服務的數據之前，都會向web_unique進程發出詢問請求，web_unique會將當前III區web系統內所有應用、節點的分布情況都以特定的格式返回給客戶端程序，客戶端程序從中選取自己需要訪問的應用機器名，然后轉而向該機器發出真正的數據請求報文。
2.3在消息總線通訊的層面
在web客戶端發送通道消息時，與非web系統發送通道消息采取不同的工作方式。非web系統發送通道消息時，消息總線首先檢查有哪些機器訂閱了該通道的消息，然后根據訂閱該通道消息的節點數目，將該消息分別復制出相應的份數，然后分別發送給對應的節點，這樣雖然應用分布在不同的機器上，對應的機器能也收到一份通道消息拷貝。而對于web應用而言，是無法采用這樣的工作方式的。如果應用的節點與web服務器分離，這個節點實際上是隱藏在web服務器之后，web客戶端不能與這個節點直接交互。 Web客戶端的消息要經過web服務器上的net_tunnel程序進行轉發，在舊的代碼中，net_tunnel認為客戶端只與web服務器進行交換，在接收到web客戶端發來的通道消息以后，直接將消息交付給本節點的消息總線，因而只能web節點才能接收到通道消息。在應用分離后，我們對net_tunnel程序進行了改造，在web服務器接收到web客戶端發來的消息以后，將自己偽裝成普通的本地應用程序，重新發送該消息，再次檢查有哪些節點訂閱了該通道，把此消息復制一份交付給相應的應用節點。
2.4 實現負荷預報、110kV電網合環風險分析等I區PAS應用在III區的部署
針對深圳用戶在III區實現PAS多個模塊功能的需求，但是鑒于PAS模塊涉及到大量的計算，會占用系統的大量資源，因此我們目前在深圳III區系統上只實現了調度員潮流功能。此次改造由于新增了兩臺服務器，突破了III區原有硬件的性能瓶頸，可以為III區PAS應用其它模塊功能的部署提供了基礎條件，既有利于EMS系統的應用推廣，又為深圳電網調度運行分析提供更豐富、更方便的手段。我們將對PAS的各模塊進行相應的修改，從而在III區實現負荷預報、靜態安全分析、短路電流計算、110kV電網合環風險分析、10kV電網合環風險分析、電網規劃分析等電網分析功能，使上述功能達到實用化的要求。
3 結論
III區的分布式部署方案以降低III區原服務器的負載從而提高系統的可擴展性為目標，符合國網公司“集團化運作、集約化發展、精益化管理、標準化建設”的要求，具有如下一些特點：
（1） 先進性
III區的分布式部署方案與傳統的集中式部署方案相比，具有很高的先進性。不但降低了原服務器的負載，而且通過各個應用服務器的分離降低了各個應用之間的耦合度，減少了應用間對計算機資源的競爭，對于系統的管理和可擴展性都帶來了極大的先進性。
（2） 高可靠性
III區的分布式部署方案給系統帶來先進性的同時，也帶來了更高的可靠性。將各個應用分開，降低了各應用之間的耦合度，給系統帶來了更高的可靠性。
（3） 高實用性
分布式系統設計與應用范文2
關鍵詞:分布式系統;基于Web;軟件設計
中圖分類號:TP311.52 文獻標識碼:A 文章編號:1007-9599 (2012) 13-0000-02
Web因其靈巧性、運用起來牢靠、方便、處理問題快捷、準確等顯著的優勢特點而有了較為廣闊的發展前途,在信息技術領域內,其應用度和普及度也有了很大程度的提升。本文先闡明控制系統軟件設計的原則、方法與控制系統軟件的功能作用,接著介紹應用服務器的設計與實現途經,并列舉該控制系統的應用實例。
一、基于Web的分布式計算機過程控制系統的設計原則與功能
基于Web的分布式應用憑借Web服務為主要媒介、載體,現如今,隨著知識經濟時代下信息化程度的不斷提高,Web服務因具備計算機信息網絡的諸多性能優勢而贏得了信息界極為一致的好評與贊譽。Web服務該模型在因特網上借助已有的服務和設施,與應用有機結合起來了,也生動體現了黑盒功能特性,開發者會在不需要考量怎樣滿足服務需求的情形下簡便地開發、重用Web組件,也不需要注重那些應用或組件服務所必需的執行平臺、運行環境或程序開發、設計原理等。下文著重介紹該控制軟件設計需要遵循的規則和控制系統軟件的功能特點。
(一)基于Web的分布式計算機系統的內涵
分布式系統作為以網絡為基礎的軟件系統,具備軟件特有的性質,因此分布式計算機控制系統有著較高的透明性和內聚性。從這個意義上說,分布式系統和普通的網絡之間的差異較為集中的體現在了高層系統軟件上,比如操作系統,絕非硬件。透明性是針對全部數據庫的分配節點,對于用戶而言是顯露的,無法判斷是遠程還是本地。內聚性則是將整個數據庫里面的每一個結合點都施行獨立運行。在以Web為前提條件的分布式控制軟件系統中,用戶無法感到數據是分散組合的,也就是說,用戶不用明確是否有復本、關系有否割裂、數據保存在了哪一個節點和事務具體在哪里執行等事項。
在一個以Web服務器為基礎的過程控制系統里,每一組群獨立分布的計算機向用戶的展示了高度有序的整體,這就作為系統予以充當。系統具備充足的邏輯資源和共通的物理資源,能夠把應完成的任務實時調動給系統去執行,在系統中出現一個用整體的方法去處理任務的分布式系統。對用戶而言,分布式系統有且只有一個模型。操作系統內部有一個專門用來完成這個模型的中間件。比較典型的案例就是在萬維網里,全部的內容看上去就好似一個Web頁面。
(二)分布式控制系統的分類
以Web作為基礎的分布式過程軟件系統能夠完成分布式處理的任務,它主要包含分布式編程語言及其編譯、運行系統、分布式文本系統、分布式數據庫資源管理系統和分布式操作系統。
(三)系統設計的原則
在網絡硬件設計的進程中,需要有平穩運行、有序、統一操縱、運用范圍廣闊和時效性優良的系統?，F如今比較容易看到的網絡協議主要是廣泛用于基于互聯網的TCP/IP協議以及Unix操作系統。信息網絡化的運行方式有兩種:一類是與客戶和服務緊密相關的客戶機/服務器的模式,另一類則是兩者對等方式。在這中間,第一種是要借助一臺或幾十臺電腦扮演服務器的角色,并負責為其余的電腦開展信息傳送、數據信息傳遞、網絡資源處理等任務。電腦的大量負荷必須專門由服務器獨自實現。在處于同等狀態、地位的網絡系統里,每一臺計算機都能扮演服務器的角色為其他計算機服務,又可以向另外的機器發送請求信號以便于第一時間獲取相應地答復。
(四)控制系統軟件的功能
本控制系統應用程序的功能較廣泛、應用面相當寬,但經合理、清晰地分類匯總,主要有以下幾個方面:計算機控制回路的組態功能,包含串連級控制系統軟件的組態和單回路控制系統軟件的組態;經由PSTN和以太網與其他計算機展開數據通信;依照特有的組態截面執行相對應的控制功能;用戶可以擴展控制算法的功能;包含網絡功能和數據采集卡等硬件情況的自我檢測功能。為了達到上面所述的各項功能就需要努力實現Web服務器的設計。
二、基于Web的分布式計算機過程控制軟件的設計方式
該控制軟件不得不在特定的網絡環境和程序語言環境下才能順利地運行,若不在一個專門的環境中配置是無法真正有效地運行起來的。只要求Web瀏覽器,像Microsoft IE(Internet Explorer)或Netscape Navigator就可以了。服務器客戶端主要包括應用服務器和Web服務器等。下面就來系統描述該控制軟件設計的整體結構、目標和設計方法。
(一)控制軟件設計的整體結構
該控制軟件作為一項繁雜巨大的系統,要由通信行業的運營商、數字化地圖的營銷方和終端制造者等諸多方面的攜手合作。一般而言,首先終端憑借扎實、牢固、精確地定位手段和途經獲取個人位置的信息以后,經移動或者因特網,把剛剛的數據和命令清晰、準確地給數據網關,再由數據網管方面的專門技術人員負責解析取得的方位信息,將數據導入數據庫中,然后給方位的服務站點,負責檢測具置的服務類網站就會把里面較為詳盡的狀態信息以數字化地圖的形式展現在眾人面前,接著就發到瀏覽器客戶端,從這個客戶端就會更加形象、清楚地控制、監督終端系統。負責位置服務的網站在這一系統中發揮了中流砥柱的作用,不但承擔起了系統的管理任務,還專職提供全部的方位服務。系統功能結構由服務管理和位置服務功能兩大子系統構成,它們各自其責、獨立工作,但又緊密協調地配合任務的完成。
分布式系統設計與應用范文3
關鍵詞：橫向可擴展性；分布系統；CAP理論；三中取二原則；BASE模型；一致性；可用性；分區容錯性
0 引言
在計算機科學中，CAP理論又稱之為布魯爾定理（Brewer’S theorem），目前已成為分布式系統設計與構建的重要理論基石。它是加州伯克利分校計算機科學家埃里·布魯爾（Eric Brewer）在1998年提出一個假說，并在2000年的分布式計算原則研討會上發表。這個假說是Brewer及其同事在橫向可擴展分布系統設計方面多年辛勤勞動的結晶。在2002年，麻省理工學院的賽斯·吉爾伯特（Seth Gilbert）和南?！ち制妫∟ancy Lynch）又完成了布魯爾假說的證明，使之脫離了唯像學說而成為一個定理，但吉爾伯特和林奇證明的布魯爾定理比布魯爾假說狹義。
1 CAP需求
在分布式的環境下，設計和部署系統時主要考慮下述3個重要的核心系統需求。
一致性（Consistency）：所有節點在同一時間具有相同的數據。
可用性（Availability）：保證對于每個請求的成功或者失敗都有響應。
分區容錯性（Partition Tolerance）：系統中信息的丟失或失敗并不影響系統的運行。
上述3個重要的核心系統需求又簡稱為CAP需求。
1.1 一致性
在分布式系統中，數據存在多個副本。一致性是指對某數據操作之后，存在各副本中的該數據始終保持一致。通常將這種操作稱為一致性操作，一致性操作是原子性的操作，即對數據的操作（增、刪、改）結果是對所有數據副本全部成功才算操作成功，否則為失敗。如果操作失敗，則回退到一致性操作前的狀態。
如果一個存儲系統能夠保證一致性，那么客戶讀取的數據可以保證是最新的數據，不會發生兩個客戶端在不同存儲節點讀取到不同的數據副本。
例1：N1、N1為網絡中的兩個節點，共享同一數據V，即一個是主本，另一個是副本，其初始值為V0。N1節點上有一個算法A，N2上有一個類似的算法B，利用A算法可以將新值寫人V，而利用B算法可以讀取V的值。
1）數據保持一致性情況。
（1）A寫入新的V值，稱作V1。
（2）N1發送信息給N2，更新N2的V值。
（3）B讀取N2的V值，讀取到的值將是V1。
2）數據出現不一致性情況。
如果網絡斷開（分區），從N1無法發送信息到N2，那么在第（3）步的時候，N2就會包含一個與N1中的不一致的V值，即在N1中的V=V1，在N2中的V=V0。
1.2 可用性
可用性是指客戶端訪問數據時，可以得到響應，但系統可用并不代表存儲系統的所有節點提供的數據一致。如客戶端想要讀取文章評論，存儲系統可以返回客戶端數據，但評論缺少最新的一條。在這種情況下，我們仍然可以說系統可用。往往可對不同的應用設定一個定長響應時間，超過這個定長響應時間的服務認為不可用?？捎眯灾槐砻鞣湛捎茫饕獦酥臼强梢酝瓿苫虿荒芡瓿缮鲜霾僮?。如當用戶購書時希望得到反饋，而不是看到瀏覽器報告網站無法連接的信息。
1.3 分區容錯性
在分布系統中，為了提高系統性能，可以將同一數據的副本分布地存放在不同地點。分區容錯性是指分布系統的容錯性。更確切地說，除非網絡的全部節點都出現故障，否則所有子集合節點的故障都不能導致整個系統的不正確響應。顯然，將數據分布在不同節點上，就有形成分區的風險。如果網線被切斷，分區就形成，兩節點之間無法進行通信。網絡分區是指由于某種原因網絡被分成若干個孤立的互不相通區域。分區容錯性也可以理解為系統在存在網絡分區的情況下仍然可以接受滿足一致性或可用性的請求。
2 CAP定理
CAP定理指出：在一個分布式系統構建中，不可能同時滿足一致性、可用性和分區容錯性三個系統需求，最多只能同時滿足兩個。對所設計系統的強調點不同，采用的策略也不一樣。
分布系統在小規模、低壓力、小延遲的情況下，CAP定理還不足以對系統總體性能造成影響，但隨著活動增加與吞吐量上升將凸顯其重要性。
對大型網站來說，可用性與分區容錯性的優先級高于數據一致性，一般放棄一致性，盡量朝著可用性和分區容錯性的方向設計，然后通過其他方法來保證一致性的商務需求。架構設計師不要將主要精力用在如何設計能同時滿足三者的完美分布式系統，社交SNS網站可以容忍相對較長時間的不一致性，但需要最終一致性。
CAP的證明很簡單，假設兩個節點集{G1，G2}，由于網絡分片導致G1和G2之間所有的通訊都斷開了，如果在G1中寫，在G2中讀剛寫入的數據，G2中返回的值不可能是G1中的寫人值。由于可用性的要求，G2一定要返回這次讀請求，由于分區容錯性的存在，導致不一致性。但由于一致性的要求，G2一定要返回這次讀請求的一致性結果，由于分區容錯性的存在，導致了長期等待，出現了不可用性。
2.1 異步網絡模型
在異步網絡模型中，沒有統一時鐘，對于所有對等運算（包括消息可丟失或不丟失的對等運算），不能實現同時滿足可用性、一致性和分區容錯性。
一個算法無法判斷一個消息是否丟失或者在傳輸通道中被延遲。
2.2 部分同步網絡模型
對于一個部分同步的網絡模型，假設所有的節點都有一個時鐘，并且所有的時鐘以一個相同的速度變化。然而，這些時鐘并不同步，在相同的時間，它們顯示不同的時間值。事實上，時鐘扮演計時器的角色，處理器可以根據本地狀態變量去衡量流逝了多少時間。一個本地的計時器可以用來確定調度某事件之后，經過多長時間間隔進行另一個操作。進而假設每一個消息要么在給定的時間內到達，要么丟失。并且所有節點在給定時間內處理完一個接收到的消息。
在一個部分同步網絡模型中，對于所有對等運算（包括消息可丟失的對等運算），不能實現同時滿足可用性、一致性和分區容錯性。
在Google使用廉價的PC機搭建了強大的、高可靠的計算和存儲平臺之后，互聯網公司一致性地選擇使用PC集群支撐全部的業務，這個理論指明了實現滿足可用性、分區容錯性的分布式系統可行，并且該分布式系統在沒有故障的情況下可以提供良好的一致性讀寫。
2.3 三中取二原則
CAP定理闡明分布系統構建中的3個核心系統需求不能夠全部同時滿足，強調一致性就需要處理因為系統不可用而導致的寫操作失敗的情況；如果強調可用性，那么應該知道系統的讀操作可能不能精確的讀取到寫操作寫入的最新值。因此系統的強調點不同，相應采用的策略也不一樣，只有真正理解了系統的需求，才有可能合理使用CAP理論。
目前互聯網中的很多分布式系統是基于首要滿足可用性和分區容錯性而設計。當處理CAP的問題時，存在下述幾個選擇。
1）放棄可用性。
如果選擇分區容錯性和一致性，放棄了可用性，那么即使節點損壞，為保證一致性，必須百分之百地保證所有節點之間有很好的連通性，這是很難做到的。最好的辦法就是將所有數據放到同一個節點中，但顯然這種設計一旦遇到分區事件，受影響的服務需要等待數據一致，在等待期間就無法對外提供服務。在多個節點上控制數據一致相當復雜，而且恢復的節點需要處理邏輯，以便平滑地返回服務狀態。
滿足一致性與分區容錯性的系統主要是一些鍵‘-’值數據庫，典型代表為Google的BigTable等系統。
2）放棄分區容錯性。
如果要滿足一致性和可用性，必須要有回滾操作。這樣，系統顯然無法容忍分區，當同一數據的兩個副本分配到了兩個無法通信的分區上并需要回滾操作時，將會返回錯誤的數據。
滿足一致性和可用性的系統通常在可擴展性方面不太強，如傳統的關系數據庫系統MySQL等。
3）放棄一致性。
如果選擇分區容錯性和可用性，放棄了一致性，當節點損壞時，遇到分區事件，受影響的服務不需要等待數據一致，就可以對外提供服務，保證了可用性。
滿足可用性與分區容錯性的系統主要是一些面向文檔的適用于分布式系統的數據庫，如SimpleDB。
兩個節點分處分區兩側，允許至少一個節點更新狀態將導致數據不一致，即喪失了一致性。除非兩個節點可以互相通信，才能既保證一致性又保證可用性，這又會導致喪失分區容錯性。對于跨區域的系統，設計者無法舍棄分區容錯性，那么就只能在數據一致性和可用性上做一個艱難選擇。一般說來，NoSQL的主題是創造可用性優先、數據一致性其次的方案；而傳統關系數據庫保持ACID特性（原子性、一致性、隔離性和持久性）。
3 BASE模型
BASE模型在20世紀90年代末提出，基于同性質之間的取舍，考慮了高可用性的設計。BASE（Basically Available，Soft-state，Eventuallyconsistent）是基本可用、軟狀態、最終一致性的英文縮寫。BASE思想主要強調基本的可用性，顯然BASE支持最終一致的概念。BASE是ACID的反面，BASE要求犧牲高一致性，獲得可用性或可靠性。BASE理論是CAP理論結合解決實際問題的產物。大規?？鐓^域分布的系統，包括云在內，也運用了這種思路。
BASE方法通過犧牲一致性來提高可用性和系統性能。
3.1 不同程度的一致性
基于程度的不同，一致性可有下面表述。
（1）強一致性。強一致性又稱為即時一致性，假如A操作先寫人了一個值到存儲系統，存儲系統保證后續A、B、C的讀取操作都將返回最新值。
（2）弱一致性。假如A先寫入了一個值到存儲系統，存儲系統不能保證后續A、B、C的讀取操作能讀取到最新值，即A寫完的數據并不能立刻讀到。
（3）最終一致性。最終一致性是弱一致性的一種特例，是指系統需要在某一時刻后達到一致性要求。假如A首先寫了一個值到存儲系統，存儲系統保證如果在A、B、C后續讀取之前沒有其他寫操作更新同樣的值，最終所有的讀取操作都將讀取到A寫入的最新值。即最終數據是一致的就可以了，而不是時時一致。最終一致性方面最典型的系統可以說是DNS系統，當更新一個域名的IP以后，根據配置策略以及緩存控制策略的不同，所有的客戶最終都會看到最新的值。
3.2 基本可用
基本可用的含義是系統能夠基本運行、始終提供服務。BASE模型與ACID模型相反，通過犧牲高一致性，獲得可用性分區容錯性。
3.3 軟狀態
軟狀態是指系統不要求一直保持強一致狀態，可以有一段時間不同步。軟狀態也可以理解為無連接的，而硬狀態是有連接的。
分布式系統設計與應用范文4
關鍵詞：分布式系統，綜合化，動態化，前期仿真
0.引言
智能建筑的基本問題實質上是信息、資源和任務的綜合共享與全局一體化的綜合管理。它實現的核心是系統集成，也就是說通過系統集成實現綜合共享，提高服務質量和工作效率，達到多快、好省和高效的目的。然而，隨著社會信息化進程的日益發展和受人們對經濟日益國際化趨勢的認同，智能建筑必將呈現出新的態勢，這種態勢體現在進行系統集成的同時，考慮建筑物的異構性、分布性、動態性和碎片性等因素的影響下，應充分體現系統的分布化、綜合化、動態化和智能化，這是建筑智能化進程中一個必須重視的戰略性問題。另外，任何工程對方案的考核是至關重要的，就智能大廈而言，對方案的考核是一個不容忽視的問題，所以對設計方案的前期仿真很有必要。
1.一體集成的分布化
智能大廈的系統一體化集成實質上是建立在系統集成、功能集成、網絡集成和軟件界面集成的多種集成的基礎上的一門高新技術。智能一體化集成化的本質是計算機網絡的管理。傳統的集成式網絡管理系統難以適應網絡規模日益擴大、網絡元素日益復雜的樓宇智能化要求，需要引入分布式管理方法。
分布式管理就是將管理的功能合理地分布于多個管理實體，以便有效、及時地對網絡資源進行監視、約束和控制，提高響應效率和擴展功能，更好地實現網絡管理目標。一個實際的網絡系統，可以根據管理的需要，按照地域、功能子系統、網絡等定義相對獨立的管理域并選定其管理者；各管理域通過管理者的交互實現全局管理目標。管理者之間的交互有兩種結構：層次的和全分布的。層次結構是通過上層管理者與下層管理者的交互來完成各管理域的管理者之間的協調。全分布式結構是一種對等結構，采用該方式的管理者之間能直接對等通信。一個實際的應用系統，管理的分布化的過程就是將管理應用功能由集中式客戶機/服務器（Client/Server）模式轉移到分布式計算平臺的過程。分布式計算平臺的目標是實現跨平臺資源的透明互操作和協同計算。
當前支持分布式計算主要有兩類環境：基于過程的分布式計算和面向對象的分布式計算。目前的主流是后一類。如基于CORBA（CommonObject Request Broker Architecture，公共對象請求體系結構）和Java的計算，它們采用面向對象的技術，提供對象式的應用編程接口，主要是針對重用和異構環境下的操作問題，這對相對龐大和復雜的智能大廈系統是非常適用的，目前CORBA技術已引起業界的關注和重視[5]。CORBA是一個開放式跨平臺的、語言獨立的分布式標準，它引入的概念屏蔽了下層的網絡傳輸，利用面向對象概念，實現分布式應用軟件的可重用性和可擴展性，既大大簡化了分布式應用系統的開發和維護，又便于異構環境下的集成，具有更高的可用性和可靠性的優點。目前遵從CORBA規范的產品主要有Inprise公司的VisiBroker,IONA公司的Orbix,Digital公司的ObjectBroker,IBM公司的Component Broker等，將基于面向對象的分布式計算技術引入智能建筑是順應技術潮流的，同時它應是甲乙類智能建筑的技術要求。
另外，分布式管理系統更容易實現大廈的智能化，不僅能實現管理的并行性和分布性，而且具有對管理活動的全過程進行多目標、多因素、多階段、多層次的協調，實現管理系統的整體協調和全局優化。
2.一體集成的綜合化
網絡是建筑物智能化的基礎，系統一體化是以網絡為支撐的，網絡信息來源于不同實體，隨著智能建筑的不斷深化，被管理的對象趨于復雜化，復雜化的因素主要有：被管理的對象趨于復雜化，復雜化的因素主要有：被管理的數量、對象的種類、組織的異構性、物理分布、參與組織的單元的數量、服務綜合的程度等，這時，由傳統的相對單一的網絡管理擴展為基于分布化的網絡綜合管理是環境的必然要求。
環境是系統存在、變化、發展的外部條件；系統與環境相互作用、相互影響，進行信息、能量或物質的交換。
綜合管理是指確保系統的所有資源根據其目的而有效運營的所有手段，它是系統與環境相統一的產物。有關綜合管理的平臺也在不斷涌現和改進，如基于事件（event）的驅動輪詢方案，基于CORBA平臺的方案。論文大全。
3.一體集成的動態性
事物的發展是m相對穩定的，在相對穩定的情況下，隨著環境的需要仍在不斷的發展和完善。智能建筑系統一體化集成的動態性是基于分布式的管理系統，也只有分布式的管理系統才能更好地實現其動態化。
動態化有兩個含義：其一是故障的檢測與動態重組恢復；其二是系統具有可擴展性。分布式系統具有故障診斷軟件包，采用互查技術來檢測系統發生故障的部位，并進行處理，動態地分配或重組系統，使系統工作于可靠狀態。分布式系統采用并行處理技術，可滿足智能大廈分階段建筑使用的要求，邊組織，邊開通，從而減少了一次性開通的難度和避免了一次性投資的方式。另外分布式系統的硬件和軟件都是模塊化的，模塊的連接嵌入比較方便，能夠很好地配合日益擴大的系統需求，便于提高和完善系統的性能，保障了系統的動態先進性。系統的動態化要求使用動態的管理策略，由于Java和CORBA的迅速發展，動態管理技術也在日趨成熟。
4.前期仿真
智能大廈的建設除了要達到預期的目標，即提供安全、舒適、快捷的優質服務，建立先進、科學的綜合管理機制，節省能源和降低成本，還要達到系統的優化配置以減少投資。這就需要在工程實施前對系統設計的基本要求和功能進行考核，以便查漏補缺和修正。論文大全。另外，因為智能大廈的網絡集成不同于研究試驗網，網絡系統可靠性、開放性等要素對大廈的智能化管理和提高運行效率具有十分重要的意義，所以，對智能大廈的前期仿真就顯得不僅十分必要而且十分重要。
由美國的Cleve和Moler博士在1980年前后創立的、正在蓬勃發展的Matlab為系統的動態仿真提供了良好的環境。Matlab的家族成員之一的Simulink為系統的仿真更是提供了極大的方便，綜合其它軟件的使用可以使該軟件在智能建筑的CAD中發揮更大的作用；此軟件也能為其它軟件提供良好的接口，便于SynchroHome等智能化集成系統軟件的調用。論文大全。該軟件有兩個明顯的功能；連接與仿真。首先利用鼠標在模型窗口上畫出所需的系統模型。然后利用軟件提供的功能對系統直接進行仿真，在系統的任何節點上可以輸出波形，從而更好地監控系統的工作過程，并實時地對系統模型進行修改以達到預期目的。這種思想和方法適合于智能大廈一體化集成的仿真與分析，相信基于Simulink的仿真技術必將在智能建筑的CAD中打開一個嶄新的局面。
5.結論
通過以上分析可見，隨著智能大廈進程的不斷加快和深化，隨著“數字城市”和“數字地球”研究的不斷深入，智能大廈系統集成的主要趨勢將是分布化、綜合化、動態化，它們之間的關系是相輔和承和互相促進的；同時由于智能大廈的建設是一種投資行為，對其進行前期仿真是十分必要性。
分布式系統設計與應用范文5
關鍵詞：電力系統；繼電保護及故障；信息子站系統
中圖分類號：TM77 文獻標識碼：A目前，電力系統對繼電保護故障信息子站系統雙機的切換要求越來越高，不僅要求保護故障信息子站系統在其中每臺出現問題故障時能做到雙機切換，而且需要在切換過程中保證數據的安全、完整、可靠性必須完全正確。電子系統調度自動化（SCADA/EMS）系統和相關技術在目前已經非常完善，電力網絡一次系統運行監控、管理、分析的自動化水平也已經得到了卓越的發展和進步。
根據電力系統結構的本身特點，且電力系統繼電保護及故障信息管理系統應該具備層次化的結構特性，其結構應該包括有：監控管理中心主站系統；置于變電站內的子站系統；保護、錄波器等二次裝置。顧及到大量保護及錄波器等二次裝配的復雜及多樣性，在變電站內設置了繼電保護與故障信息子站系統（又稱為PRFIS子站系統）將是PRFIS系統實現成功的關鍵。并且根據IEC 61850 等相關技術標準、采用OMG分布式系統和CORBA設計實現高性能的PRFIS子站系統。
一、系統設計目標
作為構成繼電保護及故障信息系統的變電站層子站系統的PRFIS子站系統，它主要設計的目標可以概括為：
1、數據匯集與轉發；實現主站與二次設備之間的有效數據通信是在二次設備與PRFIS子站系統互聯的“通信網關”下在節省通信資源及減小通信的前提下進行的。
2、數據的緩沖：內部配有小型數據庫系統，可實現故障數據的緩沖處理，從而增強整個PRFIS系統的安全可靠性。
3、數據預備處理：信息的預處理部分可以實現，比如信息過濾等等。既可以減輕主系統的壓力，又可以提高處理數據的效率。
4、多樣性設備的阻擋，整個PRFIS系統的可維護和可擴張性的提高：PRFIS子系統可以連接“即插即用”式的不同廠家及型號的二次設備的通訊規約庫，可以對主站阻擋連接多樣性的二次設備，確而保證整個PRFIS系統的可維護性、可擴張性和開放性。
5、遠程維護：在授權充分的條件下遠程維護就如身臨在現場，特別對于沒有值班人員時，對系統的維護及管理帶來了極大的方便。
6、對時：二次裝置的時鐘源需要具備硬對時與軟對時的功能。
7、具有自檢能力的子站系統，能夠產生自檢報告，向主站系統上報。
8、強大的就地功能。用戶可以使用便攜式計算機、子站后臺及站內監控后臺等方式使用維護接口及維護軟件的對系統進行維護。子站系統可以安裝任何工具軟件以實現對子站系統的管理。
二、硬件平臺
采用目前最先進的嵌入式硬件系統的思想設計的PRFIS子站系統主機硬件系統，全部的硬件系統不僅小巧，并且可靠及耐用。模塊化和分層分布式是嵌入式子站管理機采用的結構，裝置是由多個智能模塊組成，模塊類型主要有主管模塊、交換機模塊和裝置接入模塊、I/O模塊、電源模塊、GPS對時模塊、等。各個智能模塊之間通過高速背板總線交換著數據，不僅僅每個智能模塊間可以自由的正常工作，其它模塊之間也可以充分的相互配合。PRFIS子站系統的特點主要有：
1、主機裝置化，只有2U高度的整個系統，有典型的裝置化特點。尺寸的要求符合機柜的要求，可直接安裝在機柜上。2、功耗低。全部裝置消耗不超過15W，無需任何散熱設施。3、可以連接鍵盤、顯示器。根據要求使用標準的顯示器和PS2鍵盤。4）支持220V交直流電。5）多種通訊方式可兼容?？稍谕ㄟ^不同連接方式，通過一個端口實現多種通訊方式的兼容，無需任何跳線。6）光電隔離設計。運用在所以的通信端口，保證PRFIS子站系統主機運行時不會受到外界干擾，同時芯片也采用了防靜電設計，可抵抗高達1500V的靜電。7）RJ45接口，既方便又可靠。此接口專業用在高速以太網連接的接口。8）可擴充性?？梢酝ㄟ^裝置本身本身自帶的USB接口和網口，可連接各種標準擴展設置。
三、軟件系統設置。
軟件系統的設計從軟件系統設計、操作系統平臺、端口處理線程與“即插即用”、主處理進程、數據庫系統、基于IEC61850的CORBA服務器、PRFIS子站系統應用工具軟件體現。
1、軟件系統設計
PRFIS子站系統關鍵的軟件結構包括：端口處理線程、主處理進程、數據庫管理系統、事件處理程序、基于IEC61850的CORBA服務器
2、操作系統平臺
PRFIS子站主機系統采用的是嵌入式操作系統。此系統比現代系統運行穩定、可靠、高效、安全并且易維護，供給了強大的網絡功能，便于遠程管理。
采用此系統的內置標準數據管理系統，為故障信息的處理、管理與使用提供了有力保障。
3、端口處理線程與“即插即用”
本線程由主處理進程系統啟動時，據存貯在數據庫中的信息自動啟動，一個通信端口相對應端口處理線程，負責處理相應端口上所以智能二次設備的通信程序，端口處理線程會根據配置好的信息確定相應的通信規則，并配置相應的規約處理程序。對應的端口處理線程會處理和全部保護及錄波器等的二次裝置的通信任務，支持二次裝置的即插即用是其規約處理程序的可配置性致使PRFIS子站在軟件體系結構。
4、主處理進程
PRFIS子站軟件系統復位啟動時的入口程序之一有主處理進程，它的功能主義包括了：根據系統配置信息自動啟動和管理端口處理線程，分別實現了各端口處理線程、數據庫管理系統、CORBA服務器、事件處理器之間的異步通信，并且也可作為核心調度程序實現信息中轉。
5、數據庫系統
數據庫統一管理端口處理線程收集并且處理的數據，再由數據庫統一提供訪問與安全管理機制，方便故障信息的處理和共享。也可經過數據庫集中的管理產品系統參數配置，可提高產品的運行于維護的方便。穩定、可靠及高效。
6、事件處理程序
若電網出現故障時，PRFIS子站系統一方會自主的搜集關于設備的故障信息，另一方面會將搜集到的信息傳遞到主站系統，形成非常完整事件的處理流程，事件的處理程序是在IEC61580標準中面向對象的通用變電站事件信息結構定義和通用變電站事件模型設計的。
子站系統所連接二次裝置中所產生事件的記錄信息是由事件處理程序負責，并轉換成為GOOSE定義的事件信息結構，再采用標準的事件通知服務技術，然后服務接口調用運行于PRFIS主站系統的時間通知服務器的接口任務，將事件推向主站系統，從而實現二次裝置產生的數據信息主動送上。
四、基于IEC61850的CORBA服務器
1、關于IEC61859
IEC61850作為變電站通信和系統技術標準，它的核心內容規范要建立在信息模型上的抽象通信接口服務的變電系統的信息模型。但是其實質的目的是實現變電站系統與其他自動化系統開放地互聯及互相操作與變電站自動化系統內部智能設備之間開放的信息互操作。IEC61850所規定變電站系統的信息模型和抽象通信接口服務，并且全部采取面向對象的思想構思，因此需要經過映射處理。
2、OMG分布式系統標準與CORBA技術的實現
網絡化硬件環境是PRFIS子站的軟件系統的基礎，但是應用程序在網絡環境下也是需要分散的。因而組成全部軟件系統的各個組成部分分別運行在網絡內不同計算機平臺上的，并且能夠協調運行。分布式系統可以使用網絡和計算器資源得到充分有效的運用，但其就像本系統開發的背景一樣，通常具有不同的硬件平臺及操作系統，因此在這些分布式網絡環境下，采取傳統軟件思想開發分布式系統非常困難且易于出錯，并且會不可避免的重復工作。
CORBA是種國際標準及規范，只有根據這個標準，所有廠家采用任何語言開發的都能實現交互操作（運用對象組件）。
3、 IEC61850標準是由IEC61850模型映射到CORBA服務器要以CORBA技術實現的，需要做到以下工作：1）面向對象的信息模型是將標準規定的信息模型映射成的。2）將ACSI映射成CORBA服務器接口考慮到現場二次裝置的復雜性和多樣性，PRFIS子站的CORBA服務器同時實現了ACSI以外的多接口，以支持過渡性的系統構造方案。
五、系統的應用
該系統已經成功運用某變電站，站內保護的設備及故障錄波器設備通過網絡接入到了該系統。在本身有的的網絡的基礎上，將保護設備與故障錄波器設備統一接連至PRFIS子站系統，通過光纖網絡送到局端，可實現局端對站設備的管理維護，運行表明了系統具有以下功能特點：
1）在電力系統運行及故障的情況下全部都能夠按真實情況反映、記錄數據并且告警系統的相關信息，包含了電網運行的參考數據、設備通訊的狀況、保護壓板投切、開關動作、定值區切換、故障錄波、保護動作等。
2）系統供給了簡單并且直接的查詢方法，可以對保護設備、故障錄波設備進行管理，同時提供對電力系統運行信息的快速有效的查詢。
3）根據需定義各個層次的用戶操作權限，權限定義可與設備相關聯，用戶登錄、注銷及操作在系統中都有記錄，可預備查詢。
小結
系統根據IEC61850等其他相關標準設計，并且采用CORBA技術映射其抽象通信服務接口。系統采取層次化的體系結構，可以與任何廠家、型號的保護等二次設備的"即插即用"。系統采用了嵌入式軟、硬件平臺技術，安全、可靠、耐用、支持通用、標準的軟硬件產品配套，系統整體設計先進、功能完善實用、具有良好的可維護性、擴充性及開放性。
隨著電網迅速的發展，保護死區問題造成的危害愈來愈大，所以，希望引起電網管理部門的重視，及時采取防范的措施。
參考文獻
[1]陳玉，劉成林.繼電保護故障信息系統雙機互備的方案和應用[D].電力系統通信，2011（230）.
分布式系統設計與應用范文6
“操作系統”是計算機學科一門專業必修課程，課程內容豐富，既要講授關于操作系統的基礎理論，又要讓學生了解實際操作系統的設計與實現。為了進一步加強北航計算機學院“操作系統”課程的建設，提高課程質量，我們對國外40多所高校的“操作系統”的課程設置、教學內容等進行了調研。下面結合調研情況，介紹CC(Computing Curricula) 2001有關操作系統的教學內容和幾所有代表性的國外高校操作系統的課程設置。
1 CC2001
CC2001[1]認為，操作系統是硬件的抽象，人們通過它來控制硬件，進行計算機用戶間的資源分配工作。這門課主要講述影響現代操作系統設計的各種因素及實際操作。
近些年來操作系統和其抽象機制相對于應用軟件變得更加復雜，這就要求學生在系統學習內部算法實現和數據結構之前對操作系統有比較深入的理解。課程設置不僅強調了操作系統的使用，更強調它的設計和實現。操作系統中的許多思想也可用于計算機的其他領域，如并發程序設計、算法設計和實現、虛擬環境的創建、安全系統的創建及網絡管理等。對于計算機科學專業，其核心知識點為：操作系統概述、操作系統原理、并發性、調度與分派、內存管理?？蛇x的知識點為：設備管理、安全與保護、文件系統、實時和嵌入式系統、容錯、系統性能評價和腳本。
另外，新出的CC2005 Overview report[2]中為了適應不同的教學要求，將“操作系統”課程分為了兩門：操作系統原理與設計、操作系統配置與使用。
2 國外操作系統課程設置
2.1Princeton University
課程介紹：該校的“操作系統”教學理念是：掌握操作系統的唯一途徑是構造一個真正的操作系統。因此教學中注重設計和分析操作系統，教學內容包括：進程，互斥，同步，信號量，管程，死鎖預防和檢測，存儲管理，虛擬存儲，進程調度，磁盤管理，文件系統，安全保護，分布式系統。
實習項目：課程所設計的6個項目就是用來構造真正的操作系統。課程結束時，學生將有一個小的、真正操作系統內核。學生2人構成一個小組，3個項目后重組，這樣有機會同他人合作。每個項目分設計和完成兩個階段。項目包括：引導機制、非搶占式調度、搶占式調度、進程間通信與進程調度、虛存和文件系統等六項。
教學方法：采用講課與課堂中討論結合的方式，教師提前提供閱讀分配材料、討論課題及練習。學生在上課之前先行閱讀和思考討論題。相信學生們可以互相學習，鼓勵在項目中互相幫助。為了鼓勵合作，學生有機會報告誰對您幫助最大。課程結束時，幫助別人的學生可獲額外分數。
教科書：Andrew S. Tanenbaum, Albert S. Woodhull, Operating Systems: Design and Implementation, 2nd edition。
評分標準：中期測試15%，課程參加 15%，設計項目70%。
特點：采用講課與課堂中討論結合的方式；實習任務必須完成一個操作系統，而且是從引導程序開始。實習要求細致、嚴格，鼓勵合作。
2.2University of California at Berkeley
課程介紹：課程目的是學習設計操作系統，課程內容包括：操作系統和系統設計的基本概念；程序、子系統、多道程序系統、進程、進間通信與同步；存儲分配、分段、分頁、裝入與鏈接；資源分配、調度、性能評價；文件系統，存儲設備、系統；保護、安全。
實習項目：在仿真MIPS平臺構造操作系統。一共有4個項目，每個項目包括文檔和代碼兩部分，文檔占項目成績的40% ，代碼60%。項目包括：線程管理、多道程序設計、高速緩存和虛擬存儲、網絡和分布式系統。另外有5個家庭作業，但不進入評分標準。
教科書： Silberschatz and Galvin, Operating System Concepts, 7th Edition, John Wiley & Sons，ISBN：0-471-41743-2。
評分標準：兩次測試30%(每次15%)；期末考試15%；4個項目50%；班級討論5%。
特點：課程內容深入、廣泛；實習內容要求高，學習Java版本的Nachos，最后要構造支持分布式應用的操作系統。
2.3Carnegie Mellon Unive-rsity
課程介紹：課程引入了多道程序，分時，異步處理的概念，這些概念引出了同步，調度，存儲管理，信息共享和保護等問題。課程注重操作系統的設計方面。
實習項目：有4個編程項目和4個家庭作業。編程項目分別是：Yalnix shell； Yalnix 終端驅動；Yalnix內核；Yalnix文件系統。
教科書：Silberschatz, Galvin, and Gagne, Operating System Concepts, sixth edition, published by Wiley, 2002.
評分標準：第1個編程項目5%；第2個編程項目10%；第3個編程項目20%；第4個編程項目15%；中期測試15%；期終測試25%；4個家庭作業每個2.5%，共10%。
2.4Cornell University
課程名稱：Systems Programming & Operating Systems/ Practicum in Operating SystemsCOS 414/415
課程介紹：
COS 414包括操作系統的設計與實現，介紹基本的操作系統的結構，并發，調度，同步，存儲管理，文件系統，系統安全，計算機網絡。
COS 415 Practicum in Operating Systems項目：1. 編寫非搶占的用戶層線程包；2.擴展非搶占的用戶層線程包為搶占；3. 在搶先的線程包上添加不可靠的網絡服務，能夠在不同的計算機上，實現從一個小線程包向另一個線程包傳送消息；4. 擴展網絡包為可靠的傳送；5. Ad-hoc 網絡服務；6.在線程包上實現虛擬文件系統。
教科書：Silberschatz, Galvin, and Gagne, Operating System Concepts, sixth edition, published by Wiley, 2002.
評分要求：COS 414：閱讀任務 10%；中期測試30%；期末測試50%；主觀評測 10%。COS 415：6個項目 100%。
特點：講課內容豐富、課程實踐難度大。另外，該校操作系統課程由原理和實踐兩門組成。另外，Brown University、University of New South Wales等很多國外大學操作系統課程由兩門組成。
2.5Yale University
課程介紹：課程包括基本的操作系統設計和實現。課程內容包含：基本概念，同步，死鎖，進程管理，存儲管理，文件系統，安全和保護，網絡。并且介紹真實的操作系統的操作。最終通過6次實驗實現一個小型的操作系統。
實習項目：1. 啟動和創建引導鏡像；2. 實現進程和線程的模型(無中斷和調度)；3. 實現進程和線程的調度和中斷；4. 進程間通信和設備驅動；5. 虛擬存儲；6. 文件系統。
教科書：A. Silberschatz, P. Galvin, and G. Gagne, Operating System Concepts (Seventh Edition) , John Wiley & Sons, Inc., 2005.
評分要求：作業75%；期中測試20%；課堂參與5%。
2.6Harvard University
課程介紹：這門課介紹了操作系統設計和實現的基本概念。課程內容包含：基本概念，同步，死鎖，進程管理，存儲管理，文件系統。
實習項目：5個項目分別是：1. 熟悉OS/161以及其運行環境System/161；2. 同步；3. 系統調用和進程；4. 虛擬內存；5. 文件系統。
教科書：A. Tannenbaum, Modern Operating Systems, 2nd ed., Prentice Hall, 2001。
評分要求：課程出勤10%；期中測試15%；終期測試25%；5個項目50%。
2.7University of New South Wales
課程名稱：COMP3231/9201 Operating System
課程介紹：課程內容包含操作系統概要介紹；線程；進程管理；存儲管理；保護與安全；實例研究包括UNIX, Linux, Windows-2000和OS/161。
實習項目：4個項目分別是：1. 熟悉OS/161以及其運行環境System/161；2. 同步；3. 系統調用和進程；4. 虛擬內存。
教科書：A. Tannenbaum, Modern Operating Systems, 2nd ed., Prentice Hall, 2001。
特點：該校對操作系統課程非常重視(John Lions曾經是該校教師)，專門設有OS講座教授。操作系統課程由兩門組成，兩門難度要求不一樣。另外，該校實習項目采用的是Harvard University編寫的OS/161，所以與Harvard University類似，只是少了文件系統。
3 課程分析
3.1教學內容分析
CC2001教學大綱中操作系統部分內容廣泛，偏重基本原理，但是也缺少部分內容，例如：磁盤管理、分布式系統等。而國外各大學的教學內容一般都介紹當代操作系統動向，分布式、網絡通信、面向對象技術等都有所涉及，既重視原理、概念的講解，也重視具體實現源代碼的分析。
通過知識點總結可以看出，CC2001教學大綱、國內外各大學都強調：操作系統概述、操作系統原理、并發性、調度、內存管理、設備管理、安全與保護和文件系統。但是CC2001的選講內容(實時和嵌入式系統、容錯、腳本)，一般大學很少包含。有一些內容CC2001不包括，但國外大學會教授，例如磁盤管理、分布式系統等。
另外，一些大學還對一些實際的操作系統進行介紹，例如CMU介紹Linux，Cornell介紹Linux和Windows等。
3.2教學內容和方法分析
CC2001大綱和多數國外學校的課堂教學內容較為簡單。一般國外大學授課學時數在30左右，但是要求學生課前必須閱讀教科書和大量的教學參考資料。授課方式采用課堂講授與討論相結合的方式。
3.3教學實驗分析比較
CC2001大綱中沒有規定實驗的內容，而國外大學都對操作系統實驗有著嚴格的要求，有的完成一個小型操作系統，有要求獨立完成的，也有建議合作的，實習基礎有Nachos，也有其他教學操作系統。線程(進程)、線程(進程)調度、虛存和文件系統是實習項目的主要內容。實驗要求具體(報告寫作、代碼風格、執行結果)，管理嚴格，不能正確運行的作業不能得分。
3.4評分標準分析比較
通過分析國內外大學的評分標準可以看出，他們對實驗成績很重視，有的大學(如Princeton University)甚至只有實驗成績，而沒有期末考試。
3.5教材
根據我們的調研，使用較多的教材有：Andrew S. Tanenbaum的Modern Operating Systems, Second Edition；Silberschatz and Galvin的Operating System Concepts；Andrew S. Tanenbaum的Operating Systems: Design and Implementation等。
4 總結
通過上面的分析可以看出，國外“操作系統”教學有如下特點：
重視實驗環節。我們列舉的大學都對操作系統實驗有著嚴格的要求，有的認為掌握操作系統的途徑就是完成一個小型操作系統。在最終的成績中，實驗成績至少在50％以上。
教學內容靈活。從國外大學的教學內容看，他們參考CC2001，但不一定保持一致，他們的教學內容更取決于授課教師對于操作系統的理解。
教學方法多樣。教師講授與學生課堂參與相結合。學生是否參加課堂討論會影響課程的最終成績。不過國內學校學生人數較多，做到這一點很難。
課下閱讀量大，作業多。CC2001大綱中“操作系統”核心知識點課時為18小時，國外大學授課學時數在30左右，低于國內大學的學時數(例如北航操作系統為48學時)。但是國外大學通過大量的課下閱讀、作業，保證了教學質量。很多國內大學都在進行教學改革，減少學時數，這點很值得我們借鑒。
參考文獻
