分布式緩存net

❶ 什麼是分布式計算機網路

在這種網路中，不存在一個處理和控制中心，網路中任一結點都至少和另外兩個結點相連接，信息從一個結點到達另一結點時，可能有多條路徑。同時，網路中各個結點均以平等地位相互協調工作和交換信息，並可共同完成一個大型任務。分組交換網、網狀形網屬於分布式網路。這種網具有信息處理的分布性、可靠性、可擴充性及靈活性等一系列優點。因此，它是網路發展的方向。 分布式系統的平台已經成為一個鏈接某個組織的各個工作組、部門、分支機構和各個分部的企業網路。數據不是在一台伺服器上，而是在許多台伺服器上；這些伺服器可能位於多個不同的地理區域，並用WAN鏈路相連接。 圖D-26說明了從昂貴的集中式系統向可大批量安裝的低成本的分布式系統發展的趨勢。在20世紀80年代末、90年代初，分布式系統由數量龐大的桌面計算機組成，而如今，網際網路和Web技術已經大大擴展了分布式系統的概念。根據3Com論文的說法，Web是一個「大規模分布的系統集合」，它由數不勝數的節點組成，這些節點范圍從伺服器到攜帶型計算機和無線PDA，更不用說那些無需人工干預基本上就能夠彼此對話的嵌入式系統了。 TCP/IP提供了一個網路無關的傳輸層。 Web客戶機和伺服器消除了對平台和操作系統的依賴性。 組件軟體(java、ActiveX)消除了與購買和安裝軟體相關的爭論。 XML使數據獨立於軟體。 用Web技術構建的網路(如內聯網和網際網路)是真正的高級分布式計算網路。Web技術為分布式計算添加了一個新的維度。Web伺服器為具有Web瀏覽器的任何一台客戶機提供了通用的訪問方法。計算平台和操作系統的類型變得無關緊要，而無限制的通信和信息交換卻占據了主導地位。 最近的分布式計算項目已經被用於使用世界各地成千上萬位志願者的計算機的閑置計算能力，通過網際網路，您可以分析來自外太空的電訊號，尋找隱蔽的黑洞，並探索可能存在的外星智慧生命；您可以尋找超過1000萬位數字的梅森質數；您也可以尋找並發現對抗艾滋病病毒的更為有效的葯物。這些項目都很龐大，需要驚人的計算量，僅僅由單個的電腦或是個人在一個能讓人接受的時間內計算完成是決不可能的。 分布式環境具有一些很有趣的特徵。它利用了客戶機/伺服器計算技術和多層體系結構。它可將處理工作分布在多個不很昂貴的系統上，從而減輕了伺服器處理許多任務的工作量。數據可以通過有線或無線網路從許多不同的站點上進行訪問。可以將數據復制到其他系統以提供容錯功能，並使其更接近於用戶。對數據進行分布可以使數據免遭本地災害的破壞。 分布式環境需要下列組件： 支持多供應商產品和通信協議的網路平台。TCP/IP成為實際使用的標准協議。 用於在客戶機和伺服器之間交換信息的應用程序介面，如RPC(遠程過程調用)、消息傳遞系統或Web協議。 用來跟蹤資源和信息及其所處位置的目錄命名服務。 可支持分區和復制以便對數據進行分布並確保數據的可用性、可靠性和保護的文件系統和資料庫。 用於使信息更接近於用戶並使通過遠距離鏈路傳輸信息所需時間最小化的高速緩存方案。 安全功能(如身份驗證和授權)以及不同位置的系統之間的信任關系。 如前所述，Web是最基本的分布式計算機系統。您可以訪問全世界的Web伺服器，這些伺服器提供了近乎無限的豐富內容。您可以利用目錄服務來查找站點。搜索引擎對整個Web上的信息進行分類，並使您可以對其進行查詢。高速緩存技術和「內容分布」正在使信息與用戶的距離越來越近。 大規模分布系統 3Com有一篇論文，名為「Massively Distributed Systems」，是由Dan Nessett撰寫的。該論文談到了從高成本的集中式系統向低成本分布式的高單元容量的產品發展的趨勢，向大規模分布的系統發展的趨勢，這些大規模分布系統無處不在並且其運行常常超出人們的正常的知識范圍。對於那些想了解分布式計算發展趨勢的人們，建議最好閱讀一下這篇論文。 Nessett探討了兩種分布式處理方法。一種方法是將數據移到邊緣處理器，正如Web和基於Web的文件系統那樣。另一種方法是先有處理過程再接收數據，正如活動聯網和Java應用小程序那樣(如對象在分布式系統中移動，同時攜帶代碼和數據)。如果對象主要包含數據，則它會更接近於再進行處理。如果對象主要包含代碼，則它更接近於先有處理過程再接收數據。然而，另一種方法是利用瘦客戶機，這種方法是用戶在與伺服器連接的圖形終端進行工作，這些伺服器執行所有處理工作並存儲用戶的數據。 萬維網是由歐洲粒子物理實驗室(CERN)研製的基於Internet的信息服務系統。WWW以超文本技術為基礎，用面向文件的閱覽方式替代通常的菜單的列表方式，提供具有一定格式的文本、圖形、聲音、動畫等。它是一個充滿著對象的大規模分布的系統，其中各個Web站點所包含的文檔都同時包含有對象和對其他對象的索引。 Nessett談到了要使大規模分布的對象呈現給缺乏技術的用戶為何需要新的介面。一個例子是在用戶可瀏覽的虛擬空間中表示這些對象，就好像在三維世界中漫遊一樣。 分布式和並行處理 分布式計算技術的一個方面是能夠在多台計算機上並行運行若干個程序。以分布式計算技術為基礎，基於構件的系統體系結構將逐漸取代模塊化的系統體系結構。現在主要有兩種分布式計算技術的標准，一個是以OMG組織為核心的CORBA標准，另一個是以微軟為代表的基於DCOM的ActiveX標准。近年來，OMG組織在CORBA 標準的制定和推廣方面付出了巨大的努力，同時許多CORBA標準的產品也在逐漸成熟和發展；同時由於微軟在操作系統方面的絕對統治地位，ActiveX標准在Windows系列平台上顯得更加實用，相應的工具也更加成熟。 分布式並行處理技術是最適合於在通過LAN或網際網路連接的計算機之間發生的多道處理技術；而專用並行處理則是最適合於在本地通過高速介面掛接的系統上發生的多道處理技術。 多個計算機系統間的分布式並行處理需要有一個權威性的調度程序，用來決定何時何地運行程序的一些部分。任務分布可以實時進行，也可以按比較緩和的任務安排來進行。例如，分布式處理已經在破譯加密消息上得以使用。Distributed.net項目就是僱用數千名用戶和他們的計算機來破譯密碼的。用戶收到一個小程序，該程序可與Distributed.net的主系統進行通信，該系統向用戶分布要解決的部分問題。當用戶的計算機空閑時該程序即會運行。然後在完成後將其結果返回給主計算機。最後，主計算機對所有計算機提交的全部結果進行編譯。Distributed.net宣稱，它的用戶網擁有「世界上最快的計算機」。 HTC(高吞吐量計算)環境是由許多工作站組成的大集合環境，通常稱之為「網格環境」。Globus項目就是一個HTC項目，它可以幫助科研人員利用工作站和超級計算機池中的空閑周期。

❷ 網站常用的幾種開發語言NET,php,JSP，各有什麼優點缺點

ASP，全稱為Active Server Pages
ASP是微軟（Microsoft）所開發的一種後台腳本語言，它的語法和Visual BASIC類似，可以像SSI（Server Side Include）那樣把後台腳本代碼內嵌到HTML頁面中。雖然ASP簡單易用，但是它自身存在著許多缺陷，最重要的就是安全性問題。目前在微軟的 .net 戰略中新推出的ASP.net 借鑒了Java技術的優點，使用C Sharp (C#) 語言作為ASP.net的推薦語言，同時改進了以前ASP的安全性差等缺點。但是，使用ASP/ASP.net仍有一定的局限性，因為從某種角度來說它們只能在微軟的 Windows NT/2000/XP + IIS的伺服器平台上良好運行（雖然像ChilliSoft提供了在UNIX/Linux上運行ASP的解決方案，但是目前ASP在UNIX/Linux上的應用可以說幾乎為0）。所以平台的局限性和ASP自身的安全性限制了ASP的廣泛應用。

ASP在執行的時候，是由IIS調用程序引擎，解釋執行嵌在HTML中的ASP代碼，最終將結果和原來的HTML一同送往客戶端。

PHP，全稱為PHP: Hypertext Preprocessor
PHP 的全名非常有趣，它是一個巢狀的縮寫名稱——「PHP: Hypertext Preprocessor」，打開縮寫還是縮寫。PHP是一種HTML 內嵌式的語言 (就像上面講的ASP那樣)。而 PHP 獨特的語法混合了C，Java，Perl以及 PHP 式的新語法。它可以比 CGI 或者 Perl 更快速地執行動態網頁。

PHP的源代碼完全公開，在 Open Source 意識抬頭的今天，它更是這方面的中流砥柱。不斷地有新的函數庫加入，以及不停地更新，使得 PHP 無論在 UNIX 或是 Win32 的平台上都可以有更多新的功能。它提供豐富的函數，使得在程式設計方面有著更好的資源。目前PHP的最新版本為4.1.1 ，它可以在Win32以及UNIX/Linux等幾乎所有的平台上良好工作。PHP在4.0版後使用了全新的Zend引擎，其在最佳化之後的效率，比較傳統 CGI 或者 ASP 等技術有了更好的表現。

平台無關性是PHP的最大優點，但是在優點的背後，還是有一些小小的缺點的。如果在PHP中不使用ODBC，而用其自帶的資料庫函數（這樣的效率要比使用ODBC高）來連接資料庫的話， 使用不同的資料庫，PHP的函數名不能統一。這樣，使得程序的移植變得有些麻煩。不過，作為目前應用最為廣泛的一種後台語言，PHP的優點還是異常明顯的。

JSP，全稱為Java Server Pages / Servlet
JSP和Servlet要放在一起講，是因為它們都是Sun公司的J2EE（Java 2 platform Enterprise Edition）應用體系中的一部分。

Servlet的形式和前面講的CGI差不多，它是HTML代碼和後台程序分開的。它們的啟動原理也差不多，都是伺服器接到客戶端的請求後，進行應答。不同的是，CGI對每個客戶請求都打開一個進程（Process），而Servlet卻在響應第一個請求的時候被載入，一旦Servlet被載入，便處於已執行狀態。對於以後其他用戶的請求，它並不打開進程，而是打開一個線程（Thread），將結果發送給客戶。由於線程與線程之間可以通過生成自己的父線程（Parent Thread）來實現資源共享，這樣就減輕了伺服器的負擔，所以，Java Servlet可以用來做大規模的應用服務。

雖然在形式上JSP和ASP或PHP看上去很相似——都可以被內嵌在HTML代碼中。但是，它的執行方式和ASP或PHP完全不同。在JSP被執行的時候，JSP文件被JSP解釋器（JSP Parser）轉換成Servlet代碼，然後Servlet代碼被Java編譯器編譯成 .class 位元組文件，這樣就由生成的Servlet來對客戶端應答。所以，JSP可以看做是Servlet的腳本語言（Script Language）版。

由於JSP/Servlet都是基於Java的，所以它們也有Java語言的最大優點——平台無關性，也就是所謂的「一次編寫，隨處運行（WORA – Write Once, Run Anywhere）」。除了這個優點，JSP/Servlet的效率以及安全性也是相當驚人的。因此，JSP/Servlet雖然在國內目前的應用並不廣泛，但是其前途不可限量。

在調試JSP代碼時，如果程序出錯，JSP伺服器會返回出錯信息，並在瀏覽器中顯示。這時，由於JSP是先被轉換成Servlet後再運行的，所以，瀏覽器中所顯示的代碼出錯的行數並不是JSP源代碼的行數，而是指轉換後的Servlet程序代碼的行數。這給調試代碼帶來一定困難。所以，在排除錯誤時，可以採取分段排除的方法（在可能出錯的代碼前後輸出一些字元串，用字元串是否被輸出來確定代碼段從哪裡開始出錯），逐步縮小出錯代碼段的范圍，最終確定錯誤代碼的位置。

JSP和ASP相比較：

運行速度、運行開銷、運行平台、擴展性、安全性、函數支持、廠商支持、對XML的支持等等，ASP都不是JSP的對手。COM組件的復雜性實編程實現有一定的難度。而JAVABeans和JAVA的結合卻是天衣無縫的。

JSP和ASP.NET相比較：

1．相對C＃，JSP的腳本語言JAVA也是面向對象的、分布式的、解釋的語言。

2．與C＃相似JAVA同樣去掉了難以理解的指針等概念，取而代之的是類和對象。

3. JSP有一項全新的技術――Servlet（伺服器端程序）很好的節約了伺服器資源。

4．JAVABeans是針對ASP.NET的Server Control的技術。只要會JAVA， JavaBeans就很容易寫出。

5．再有就是JAVA的JDBC資料庫連接技術。

6．JSP對XML同樣有十分廣泛的支持。

1) 面向對象性:
ASP+將C#作為一種面向對象語言，在很多方面來看，C#將成為微軟的與Java相似的語言。
C#另一個有趣的地方是所有對象都自動變成為COM對象。如果C#能取得很大的市場份額，那麼它將給ASP+帶來類似於Java的功能，並且具備更快的性能，因為它可以和Windows環境緊密集成。
C# 是ASP+開發中一個最重要的功能，微軟會將C#發展成為Java的強勁對手。這也是他們.Net框架的一個重要組成部分。我認為C#是微軟在編程市場上擊敗對手的主要工具。我期待著微軟能在這個產品後面傾注全力，這樣，C#可以成為許多程序員的又一種選擇。C#產生的結果是將進一步加固微軟和Sun產品的戰線。這對用戶是有利的，他們可以選擇兩者之一來開發新的應用。

2) 資料庫連接：
ASP另一個亮點是它使用ADO對象，ODBC, OLE-DB和事務處理管理器。因此ASP Web資料庫應用開發特別簡單。ASP+發展了更多的功能，因為有了ADO+！ADO+帶來了更強大更快速的功能。JSP和JDBC目前在易用性和性能上同ASP/ADO相比已有些落後，當新版本ASP+/ADO+出現後這樣的差別會更明顯。我個人希望SUN應盡快能花大力氣來追趕ASP+/ADO+的組合。

3) 大型站點應用：
ASP+將對大型站點(web farms)有更好的支持。事實上，微軟在這方面付出了巨大的努力。 ASP+可以讓你考慮到多伺服器(multiple servers)的場合，當你需要更強大的功能時，僅僅只需要增加一台伺服器。整個.Net框架已經充分地提供了這個方法。ASP+提供了外部會話狀態(external session state)來提供內置式web farm的支持。另外，由於請求的各組件相互間經過了充分的優化，所以速度很快。
於是ASP+現在可以在大型項目方面與JSP一樣具有等同的能力。 而ASP+還有價格方面的優勢，因為所有的組件將是伺服器操作系統的一部分。對於JSP,你需要購買昂貴的應用伺服器群來達到同樣的目的。

4) ASP+還提供更多的其它方面的新特性，例如：
*內置的對象緩存和頁面結果緩存。
*內置的XML支持，可用於XML數據集的簡單處理。
*伺服器控制提供了更充分的互動式控制。
ASP+確實對ASP進行了較大的發展。

❸ 如何 配置 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會是你的最佳選擇。

❹ C#.net 主要特點

C#是一個語言，ASP.net是一個平台，上面支持用C#或者VB.Net寫代碼。
另外，C#不但可以開發基於ASP.net的應用程序，也可以開發基於WinForm的程序，這就是區別。
若是單純以概念來說，你可以把.net當做一個工作平台一般，它是一個開發環境的基底，提供你開發Windows、Web、Mobile、XML...等應用程式一個共通的平台，若是要了解深一點，則再去了解其運作的相關機制那是有助於你利用它來開發.C#和.NET主要是應用在網際網路.
C#（讀做C-sharp）編程語言是由微軟公司的Anders Hejlsberg和 Scott Willamette領導的開發小組專門為.NET平台設計的語言，它可以使程序員移植到.NET上。這種移植對於廣大的程序員來說是比較容易的，因為C#從C，C++和Java發展而來，它採用了這三種語言最優秀的特點，並加入了它自己的特性。C#是事件的驅動的，完全面向對象的可視化編程語言，我們可以使用集成開發環境來編寫C#程序。使用IDE，程序員可以方便的建立，運行，測試和調試C#程序，這就將開發一個可用程序的時間減少到不用IDE開發時所用時間的一小部分。使用IDE迅速建立一個應用程序的過程稱為快速反映開發。

C#2.0新特性
1、 泛型：在我看來，泛型就是通過將數據類型參數化從而實現了代碼的更為靈活的復用，泛型的出現使得C#能夠使用同一段代碼來操作多種數據類型。泛型無疑是C#2.0最重大的改進，它的出現賦予了C#代碼更強的類型安全，更好的復用，更高的效率和更清晰的約束。
2、 匿名方法：匿名方法允許我們將代碼直接與委託實例相關聯，使委託實例化工作更加直觀和方便。在我看來，這只是C#又多了一種語法格式而已，不再像以前必須將方法名傳給委託實例，而是又多了一種選擇。
3、 迭代器：迭代器允許我們更加方便的編寫用於foreach語句的類型。在我看來，迭代器的出現只不過是改進了1.0中不便的可用foreach語句類型的編寫限制，簡化了一些介面。
4、 局部類型：局部類型允許我們將一個類的代碼分別寫在不同的cs文件中。最典型的應用就是使用VS2005創建Form文件時，VS會自動將系統生成的代碼與用戶代碼分開。局部類型通過partial關鍵字來聲明。
5、 空屬類型：空屬類型是一種像int？一樣可以為空的變數類型。本質上是一種泛型的應用，是System .Nullable<>的一種類型實例化。
6、 靜態類：靜態類是只用於包含靜態成員的類型，它既不能實例化，亦不能被繼承。

❺ 關於.Net開發下的分布式緩存設計

緩存真是個好東西，在大型的系統中可以有效地提升系統的速度，此乃廢話就不多說了，在。Net 平台下面我把緩存從功用大致分為兩類，數據對象緩存和頁面輸出緩存。 對於數據緩存來講是由System.Web.Caching.Cache這個類來實現，可以從上下文對象Context.Cache 來獲取這個對象的引用。而頁面/控制項輸出緩存則是由。Net環境在運行時依據頭部的緩存申明來控制緩存策略。 本文主要論證與數據緩存相關的一些應用與問題。文中提到了"無法跨Web園共享數據的問題"，雖然提到解決方案就是使用XML文件來存放緩存的鍵值，這里有一個疑惑，就是。Net的Web園既然是進程獨立的又何來共享之說呢，真要是這樣的話即便是通過XML文檔寫入緩存鍵值緩存的對象也不能同時在兩個進程中共享，而這里獲得的好處僅是避免了在其它的進程中讀到了已在當前進程中失效的「臟」緩存數據，這樣的話開幾個Web園就會產生幾個緩存的對象對系統資源的利用系就比較低了。 如果是用Web場布署的話浪費就更多了，也許是還少有論壇達到這樣的規模故不在設計能力的范圍中吧。CommunityServer也是使用了這個系統對象，並對它作了一些包裝形成了CommunityServer.Components.CSCache這個類，還是不錯的，可以在項目中選擇使用。

❻ Win7中的Remote Procere Call是什麼服務

Win7區域網共享需要開啟的服務項,解決區域網無法共享問題!.
開始 > 運行（或者win+R）: services.msc，找到以下服務項，並開啟。

UPnP Device Host:
允許 UPnP 設備宿主在此計算機上。如果停止此服務，則所有宿主的 UPnP 設備都將停止工作，並且不能添加其他宿主設備。如果禁用此服務，則任何顯式依賴於它的服務將都無法啟動。

TCP/IP NetBIOS Helper:
提供 TCP/IP (NetBT) 服務上的 NetBIOS 和網路上客戶端的 NetBIOS 名稱解析的支持，從而使用戶能夠共享文件、列印和登錄到網路。如果此服務被停用，這些功能可能不可用。如果此服務被禁用，任何依賴它的服務將無法啟動。

SSDP Discovery:
當發現了使用 SSDP 協議的網路設備和服務，如 UPnP 設備，同時還報告了運行在本地計算機上使用的 SSDP 設備和服務。如果停止此服務，基於 SSDP 的設備將不會被發現。如果禁用此服務，任何依賴此服務的服務都無法正常啟動。

Server:
支持此計算機通過網路的文件、列印、和命名管道共享。如果服務停止，這些功能不可用。如果服務被禁用，任何直接依賴於此服務的服務將無法啟動。

Network Location Awareness:
當發現了使用 SSDP 協議的網路設備和服務，如 UPnP 設備，同時還報告了運行在本地計算機上使用的 SSDP 設備和服務。如果停止此服務，基於 SSDP 的設備將不會被發現。如果禁用此服務，任何依賴此服務的服務都無法正常啟動。

Network Connections:
管理「網路和撥號連接」文件夾中對象，在其中您可以查看區域網和遠程連接。

DNS Client:
DNS 客戶端服務(dnscache)緩存域名系統(DNS)名稱並注冊該計算機的完整計算機名稱。如果該服務被停止，將繼續解析 DNS 名稱。然而，將不緩存 DNS 名稱的查詢結果，且不注冊計算機名稱。如果該服務被禁用，則任何明確依賴於它的服務都將無法啟動。

Computer Browser:
維護網路上計算機的更新列表，並將列表提供給計算機指定瀏覽。如果服務停止，列表不會被更新或維護。如果服務被禁用，任何直接依賴於此服務的服務將無法啟動。

WIN7系統的網路功能比XP有了進一步的增強，使用起來也相對清晰。但是由於做了很多表面優化的工作，使得底層的網路設置對於習慣了XP系統的人來說變得很不適應，其中區域網組建就是一個很大的問題。
默認安裝系統後不但同組內的WIN7系統互相不能共享訪問，而且最頭疼的問題是組內的XP系統計算機更難互訪。針對這個問題，從網路上收集了一些這方面的資料，結合自己在調試過程中的情況，通過以下步驟基本能夠解決XP與WIN7區域網共享設置的問題。不到之處請網友諒解指正。
一：必要點
1、需要是管理員許可權的帳戶
2、所有入網的計算機都要在相同的IP段，比如都為192.168.1.X（2≤X≤255）
3、所有入網的計算機都要在相同的工作組，比如都在WORKGROUP組
4、所有入網的計算機都要開啟來賓賬戶，默認賬戶名為：guest。
5、關閉任何第三方的防火牆軟體，或者進行一些相關設置（很重要）。Windows自帶的防火牆。如果沒有把它關閉的話，也需要進行一些設置才可以。打開Windows防火牆---例外---勾選 文件和列印機共享---確定---保存。 XP系統，在 常規 選項卡中，要去掉不允許例外 前面的勾。
6、所有入網的計算機的操作系統必須有正確的許可權設置（這是重點）
7、XP，是指Windows XP Professional 版本。其中所述的部分方法，並不適用於Windows XP Home Edition。8、WIN7，是指Windows 7。不同版本的WIN7可能存在一定的差異。如果你用的是Home Basic版本，就不要再往下看了，因為Home Basic不提供文件共享功能。。
二：必須開啟的服務右鍵點擊我的電腦 或計算機—管理----服務和應用程序，打開服務或者用WIN+R打開 運行---輸入services.msc回車，打開服務設置將以下服務的[啟動類型]選為[自動]，並確保[服務狀態]為[已啟動]
Server
Workstation
Computer Browser
DHCP Client
Remote Procere Call
Remote Procere Call (RPC)
LocatorDNS ClientFunction Discovery Resource PublicationUPnP Device

❼ 並發的並發處理

一個小型的網站，比如個人網站，可以使用最簡單的html靜態頁面就實現了，配合一些圖片達到美化效果，所有的頁面均存放在一個目錄下，這樣的網站對系統架構、性能的要求都很簡單，隨著互聯網業務的不斷豐富，網站相關的技術經過這些年的發展，已經細分到很細的方方面面，尤其對於大型網站來說，所採用的技術更是涉及面非常廣，從硬體到軟體、編程語言、資料庫、WebServer、防火牆等各個領域都有了很高的要求，已經不是原來簡單的html靜態網站所能比擬的。
大型網站，比如門戶網站。在面對大量用戶訪問、高並發請求方面，基本的解決方案集中在這樣幾個環節：使用高性能的伺服器、高性能的資料庫、高效率的編程語言、還有高性能的Web容器。但是除了這幾個方面，還沒法根本解決大型網站面臨的高負載和高並發問題。
上面提供的幾個解決思路在一定程度上也意味著更大的投入，並且這樣的解決思路具備瓶頸，沒有很好的擴展性，下面我從低成本、高性能和高擴張性的角度來說說我的一些經驗。 其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使我們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，我們無法全部手動去挨個實現，於是出現了我們常見的信息發布系統CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
除了門戶和信息發布類型的網站，對於交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。
同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用資料庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行後台管理並且存儲再資料庫中，這些信息其實大量被前台程序調用，但是更新頻率很小，可以考慮將這部分內容進行後台更新的時候進行靜態化，這樣避免了大量的資料庫訪問請求。 大型網站都有復雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一台資料庫將很快無法滿足應用，於是我們需要使用資料庫集群或者庫表散列。
在資料庫集群方面，很多資料庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施即可。
上面提到的資料庫集群由於在架構、成本、擴張性方面都會受到所採用DB類型的限制，於是我們需要從應用程序的角度來考慮改善系統架構，庫表散列是常用並且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將資料庫進行分離，不同的模塊對應不同的資料庫或者表，再按照一定的策略對某個頁面或者功能進行更小的資料庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能並且有很好的擴展性。sohu的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行資料庫分離，然後對帖子、用戶按照板塊和ID進行散列資料庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加一台低成本的資料庫進來補充系統性能。 緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在後面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memory Cache是常用的緩存介面，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。 負載均衡將是大型網站解決高負荷訪問和大量並發請求採用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
1.軟體四層交換
大家知道了硬體四層交換機的原理後，基於OSI模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有餘的，有人說軟體實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟體四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對於分布式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。這樣的架構我准備空了專門詳細整理一下和大家探討。
對於大型網站來說，前面提到的每個方法可能都會被同時使用到，我這里介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大。
2.硬體四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。第四層交換功能就象是虛IP，指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上，需要復雜的載量平衡演算法。在IP世界，業務類型由終端TCP或UDP埠地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP埠共同決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000台伺服器使用了三四台Alteon就搞定了。

❽ 如何處理大量數據並發操作

處理大量數據並發操作可以採用如下幾種方法:

1.使用緩存：使用程序直接保存到內存中。或者使用緩存框架: 用一個特定的類型值來保存，以區別空數據和未緩存的兩種狀態。

2.資料庫優化：表結構優化;SQL語句優化，語法優化和處理邏輯優化;分區;分表;索引優化;使用存儲過程代替直接操作。

3.分離活躍數據:可以分為活躍用戶和不活躍用戶。

4.批量讀取和延遲修改: 高並發情況可以將多個查詢請求合並到一個。高並發且頻繁修改的可以暫存緩存中。

5.讀寫分離: 資料庫伺服器配置多個，配置主從資料庫。寫用主資料庫，讀用從資料庫。

6.分布式資料庫: 將不同的表存放到不同的資料庫中，然後再放到不同的伺服器中。

7.NoSql和Hadoop: NoSql，not only SQL。沒有關系型資料庫那麼多限制，比較靈活高效。Hadoop，將一個表中的數據分層多塊，保存到多個節點（分布式）。每一塊數據都有多個節點保存（集群）。集群可以並行處理相同的數據，還可以保證數據的完整性。

拓展資料:

大數據（big data），指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。

在維克托·邁爾-舍恩伯格及肯尼斯·庫克耶編寫的《大數據時代》中大數據指不用隨機分析法（抽樣調查）這樣捷徑，而採用所有數據進行分析處理。大數據的5V特點（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。

❾ 如何進行網站性能優化

一、前端優化

網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。

首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、Javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：

對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：

1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。

對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。

2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。

3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。

4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。

5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。

對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。

1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。

要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。

我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。

2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。

3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。

4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問，伺服器會通過301轉向到/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。

還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。

做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。

當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。

二、後端優化

上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。

前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：

1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： ），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。

2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ ）、php accelebrator()，還有收費的Zend Performance Suite

3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。

4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。

5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。

6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能

7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構

最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。

❿ php面試題 memcache和redis的區別

Redis與Memcached的區別

傳統MySQL+ Memcached架構遇到的問題

實際MySQL是適合進行海量數據存儲的，通過Memcached將熱點數據載入到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務數據量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：

1.MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作占據大量開發時間。

2.Memcached與MySQL資料庫數據一致性問題。

3.Memcached數據命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。

4.跨機房cache同步問題。

眾多NoSQL百花齊放，如何選擇

最近幾年，業界不斷涌現出很多各種各樣的NoSQL產品，那麼如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的
問題，實際歸根結底最重要的是了解這些產品的定位，並且了解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用於解
決以下幾種問題

1.少量數據存儲，高速讀寫訪問。此類產品通過數據全部in-momery 的方式來保證高速訪問，同時提供數據落地的功能，實際這正是Redis最主要的適用場景。

2.海量數據存儲，分布式系統支持，數據一致性保證，方便的集群節點添加/刪除。

3.這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性，後者是一個中心化的方案設計，通過類似一個分布式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然後定期compat歸並到磁碟上，將隨機寫優化為順序寫，提高寫入性能。

4.Schema free，auto-sharding等。比如目前常見的一些文檔資料庫都是支持schema-free的，直接存儲json格式數據，並且支持auto-sharding等功能，比如mongodb。

面對這些不同類型的NoSQL產品,我們需要根據我們的業務場景選擇最合適的產品。

Redis適用場景，如何正確的使用

前面已經分析過，Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-
backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用
Memcached,何時使用Redis呢?

如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

1 Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。

2 Redis支持數據的備份，即master-slave模式的數據備份。

3 Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次載入進行使用。

拋開這些，可以深入到Redis內部構造去觀察更加本質的區別，理解Redis的設計。

在
Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。Redis只會緩存所有的
key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability =
age*log(size_in_memory)」計
算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以

保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存

中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個
操作，直到子線程完成swap操作後才可以進行修改。

使用Redis特有內存模型前後的情況對比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used

當

從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。

這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行

批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程
池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。

如果希望在海量數據的環境中使用好Redis，我相信理解Redis的內存設計和阻塞的情況是不可缺少的。

補充的知識點：

memcached和redis的比較

1 網路IO模型

Memcached是多線程，非阻塞IO復用的網路模型，分為監聽主線程和worker子線程，監聽線程監聽網路連接，接受請求後，將連接描述
字pipe 傳遞給worker線程，進行讀寫IO, 網路層使用libevent封裝的事件庫，多線程模型可以發揮多核作用，但是引入了cache
coherency和鎖的問題，比如，Memcached最常用的stats
命令，實際Memcached所有操作都要對這個全局變數加鎖，進行計數等工作，帶來了性能損耗。

(Memcached網路IO模型)

Redis使用單線程的IO復用模型，自己封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和select，
對於單純只有IO操作來說，單線程可以將速度優勢發揮到最大，但是Redis也提供了一些簡單的計算功能，比如排序、聚合等，對於這些操作，單線程模型實
際會嚴重影響整體吞吐量，CPU計算過程中，整個IO調度都是被阻塞住的。

2.內存管理方面

Memcached使用預分配的內存池的方式，使用slab和大小不同的chunk來管理內存，Item根據大小選擇合適的chunk存儲，內
存池的方式可以省去申請/釋放內存的開銷，並且能減小內存碎片產生，但這種方式也會帶來一定程度上的空間浪費，並且在內存仍然有很大空間時，新的數據也可
能會被剔除，原因可以參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/

Redis使用現場申請內存的方式來存儲數據，並且很少使用free-list等方式來優化內存分配，會在一定程度上存在內存碎片，Redis
跟據存儲命令參數，會把帶過期時間的數據單獨存放在一起，並把它們稱為臨時數據，非臨時數據是永遠不會被剔除的，即便物理內存不夠，導致swap也不會剔
除任何非臨時數據(但會嘗試剔除部分臨時數據)，這點上Redis更適合作為存儲而不是cache。

3.數據一致性問題

Memcached提供了cas命令，可以保證多個並發訪問操作同一份數據的一致性問題。 Redis沒有提供cas 命令，並不能保證這點，不過Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷。

4.存儲方式及其它方面

Memcached基本只支持簡單的key-value存儲，不支持枚舉，不支持持久化和復制等功能

Redis除key/value之外，還支持list,set,sorted set,hash等眾多數據結構，提供了KEYS

進行枚舉操作，但不能在線上使用，如果需要枚舉線上數據，Redis提供了工具可以直接掃描其mp文件，枚舉出所有數據，Redis還同時提供了持久化和復制等功能。

5.關於不同語言的客戶端支持

在不同語言的客戶端方面，Memcached和Redis都有豐富的第三方客戶端可供選擇，不過因為Memcached發展的時間更久一些，目
前看在客戶端支持方面，Memcached的很多客戶端更加成熟穩定，而Redis由於其協議本身就比Memcached復雜，加上作者不斷增加新的功能
等，對應第三方客戶端跟進速度可能會趕不上，有時可能需要自己在第三方客戶端基礎上做些修改才能更好的使用。

根據以上比較不難看出，當我們不希望數據被踢出，或者需要除key/value之外的更多數據類型時，或者需要落地功能時，使用Redis比使用Memcached更合適。

關於Redis的一些周邊功能

Redis除了作為存儲之外還提供了一些其它方面的功能，比如聚合計算、pubsub、scripting等，對於此類功能需要了解其實現原
理，清楚地了解到它的局限性後，才能正確的使用，比如pubsub功能，這個實際是沒有任何持久化支持的，消費方連接閃斷或重連之間過來的消息是會全部丟
失的，又比如聚合計算和scripting等功能受Redis單線程模型所限，是不可能達到很高的吞吐量的，需要謹慎使用。

總的來說Redis作者是一位非常勤奮的開發者，可以經常看到作者在嘗試著各種不同的新鮮想法和思路，針對這些方面的功能就要求我們需要深入了解後再使用。

總結：

1.Redis使用最佳方式是全部數據in-memory。

2.Redis更多場景是作為Memcached的替代者來使用。

3.當需要除key/value之外的更多數據類型支持時，使用Redis更合適。

4.當存儲的數據不能被剔除時，使用Redis更合適。

談談Memcached與Redis(一)

1. Memcached簡介

Memcached是以LiveJurnal旗下Danga Interactive公司的Bard
Fitzpatric為首開發的高性能分布式內存緩存伺服器。其本質上就是一個內存key-value資料庫，但是不支持數據的持久化，伺服器關閉之後數
據全部丟失。Memcached使用C語言開發，在大多數像Linux、BSD和Solaris等POSIX系統上，只要安裝了libevent即可使
用。在Windows下，它也有一個可用的非官方版本(http://code.jellycan.com/memcached/)。Memcached
的客戶端軟體實現非常多，包括C/C++, PHP, Java, Python, Ruby, Perl, Erlang,
Lua等。當前Memcached使用廣泛，除了LiveJournal以外還有Wikipedia、Flickr、Twitter、Youtube和
WordPress等。

在Window系統下，Memcached的安裝非常方便，只需從以上給出的地址下載可執行軟體然後運行memcached.exe –d
install即可完成安裝。在Linux等系統下，我們首先需要安裝libevent，然後從獲取源碼，make && make
install即可。默認情況下，Memcached的伺服器啟動程序會安裝到/usr/local/bin目錄下。在啟動Memcached時，我們可
以為其配置不同的啟動參數。

1.1 Memcache配置

Memcached伺服器在啟動時需要對關鍵的參數進行配置，下面我們就看一看Memcached在啟動時需要設定哪些關鍵參數以及這些參數的作用。

1）-p <num> Memcached的TCP監聽埠，預設配置為11211；

2）-U <num> Memcached的UDP監聽埠，預設配置為11211，為0時表示關閉UDP監聽；

3）-s <file> Memcached監聽的UNIX套接字路徑；

4）-a <mask> 訪問UNIX套接字的八進制掩碼，預設配置為0700；

5）-l <addr> 監聽的伺服器IP地址，默認為所有網卡；

6）-d 為Memcached伺服器啟動守護進程；

7）-r 最大core文件大小；

8）-u <username> 運行Memcached的用戶，如果當前為root的話需要使用此參數指定用戶；

9）-m <num> 分配給Memcached使用的內存數量，單位是MB；

10）-M 指示Memcached在內存用光的時候返回錯誤而不是使用LRU演算法移除數據記錄；

11）-c <num> 最大並發連數，預設配置為1024；

12）-v –vv –vvv 設定伺服器端列印的消息的詳細程度，其中-v僅列印錯誤和警告信息，-vv在-v的基礎上還會列印客戶端的命令和相應，-vvv在-vv的基礎上還會列印內存狀態轉換信息；

13）-f <factor> 用於設置chunk大小的遞增因子；

14）-n <bytes> 最小的chunk大小，預設配置為48個位元組；

15）-t <num> Memcached伺服器使用的線程數，預設配置為4個；

16）-L 嘗試使用大內存頁；

17）-R 每個事件的最大請求數，預設配置為20個；

18）-C 禁用CAS，CAS模式會帶來8個位元組的冗餘；

2. Redis簡介

Redis是一個開源的key-value存儲系統。與Memcached類似，Redis將大部分數據存儲在內存中，支持的數據類型包括：字
符串、哈希表、鏈表、集合、有序集合以及基於這些數據類型的相關操作。Redis使用C語言開發，在大多數像Linux、BSD和Solaris等
POSIX系統上無需任何外部依賴就可以使用。Redis支持的客戶端語言也非常豐富，常用的計算機語言如C、C#、C++、Object-C、PHP、
Python、Java、Perl、Lua、Erlang等均有可用的客戶端來訪問Redis伺服器。當前Redis的應用已經非常廣泛，國內像新浪、淘
寶，國外像Flickr、Github等均在使用Redis的緩存服務。

Redis的安裝非常方便，只需從http://redis.io/download獲取源碼，然後make && make

install即可。默認情況下，Redis的伺服器啟動程序和客戶端程序會安裝到/usr/local/bin目錄下。在啟動Redis伺服器時，我們
需要為其指定一個配置文件，預設情況下配置文件在Redis的源碼目錄下，文件名為redis.conf。