QQ遊戲百萬人同時線上伺服器架構實作

轉載自：http://morton5555.blog.163.com/blog/static/976407162012013112545710/#

　　QQ遊戲于前幾日終于突破了百萬人同時線上的關口，向着更為遠大的目标邁進，這讓其它衆多傳統的棋牌休閑遊戲平台黯然失色，相比之下，聯衆似乎已經根本不是QQ的對手，因為QQ除了這100萬的遊戲線上人數外，它還擁有3億多的注冊量（當然很多是重複注冊的）以及QQ聊天軟體900萬的同時線上率，我們已經可以預見未來由QQ建構起來的強大棋牌休閑遊戲帝國。

伺服器程式，其可承受的同時連接配接數目是有理論峰值的，通過C＋＋中對TSocket的定義類型：word，我們可以判定這個連接配接理論峰值是65535，也就是說，你的單個伺服器程式，最多可以承受6萬多的使用者同時連接配接。但是，在實際應用中，能達到一萬人的同時連接配接并能保證正常的資料交換已經是很不容易了，通常這個值都在2000到5000之間，據說QQ的單台伺服器同時連接配接數目也就是在這個值這間。

　　如果要實作2000到5000使用者的單伺服器同時線上，是不難的。在windows下，比較成熟的技術是采用IOCP－－完成端口。與完成端口相關的資料在網上和CSDN論壇裡有很多，感興趣的朋友可以自己搜尋一下。隻要運用得當，一個完成端口伺服器是完全可以達到2K到5K的同時線上量的。但，5K這樣的數值離百萬這樣的數值實在相差太大了，是以，百萬人的同時線上是單台伺服器肯定無法實作的。

　　要實作百萬人同時線上，首先要實作一個比較完善的完成端口伺服器模型，這個模型要求至少可以承載2K到5K的同時線上率（當然，如果你MONEY多，你也可以隻開發出最多允許100人線上的伺服器）。在建構好了基本的完成端口伺服器之後，就是有關伺服器組的架構設計了。之是以說這是一個伺服器組，是因為它絕不僅僅隻是一台伺服器，也絕不僅僅是隻有一種類型的伺服器。

　　簡單地說，實作百萬人同時線上的伺服器模型應該是：登陸伺服器＋大廳伺服器＋房間伺服器。當然，也可以是其它的模型，但其基本的思想是一樣的。下面，我将逐一介紹這三類伺服器的各自作用。

　　登陸伺服器：一般情況下，我們會向玩家開放若幹個公開的登陸伺服器，就如QQ登陸時讓你選擇的從哪個QQ遊戲伺服器登陸一樣，QQ登陸時讓玩家選擇的六個伺服器入口實際上就是登陸伺服器。登陸伺服器主要完成負載平衡的作用。詳細點說就是，在登陸伺服器的背後，有N個大廳伺服器，登陸伺服器隻是用于為目前的用戶端連接配接選擇其下一步應該連接配接到哪個大廳伺服器，當登陸伺服器為目前的用戶端連接配接選擇了一個合适的大廳伺服器後，用戶端開始根據登陸伺服器提供的資訊連接配接到相應的大廳上去，同時用戶端斷開與登陸伺服器的連接配接，為其他玩家用戶端連接配接登陸伺服器騰出套接字資源。在設計登陸伺服器時，至少應該有以下功能：N個大廳伺服器的每一個大廳伺服器都要與所有的登陸伺服器保持連接配接，并實時地把本大廳伺服器目前的同時線上人數通知給各個登陸伺服器，這其中包括：使用者進入時的同時線上人數增加資訊以及使用者退出時的同時線上人數減少資訊。這裡的各個大廳伺服器同時線上人數資訊就是登陸伺服器為用戶端選擇某個大廳讓其登陸的依據。舉例來說，玩家A通過登陸伺服器1連接配接到登陸伺服器，登陸伺服器開始為目前玩家在衆多的大廳伺服器中根據哪一個大廳伺服器人數比較少來選擇一個大廳，同時把這個大廳的連接配接IP和端口發給用戶端，用戶端收到這個IP和端口資訊後，根據這個資訊連接配接到此大廳，同時，用戶端斷開與登陸伺服器之間的連接配接，這便是使用者登陸過程中，在登陸伺服器這一塊的處理流程。

　　大廳伺服器：大廳伺服器，是普通玩家看不到的伺服器，它的連接配接IP和端口資訊是登陸伺服器通知給用戶端的。也就是說，在QQ遊戲的本地檔案中，具體的大廳伺服器連接配接IP和端口資訊是沒有儲存的。大廳伺服器的主要作用是向玩家發送遊戲房間清單資訊，這些資訊包括：每個遊戲房間的類型，名稱，線上人數，連接配接位址以及其它如遊戲幫助檔案URL的資訊。從界面上看的話，大廳伺服器就是我們輸入使用者名和密碼并校驗通過後進入的遊戲房間清單界面。大廳伺服器，主要有以下功能：一是向目前玩家廣播各個遊戲房間線上人數資訊；二是提供遊戲的版本以及下載下傳位址資訊；三是提供各個遊戲房間伺服器的連接配接IP和端口資訊；四是提供遊戲幫助的URL資訊；五是提供其它遊戲輔助功能。但在這衆多的功能中，有一點是最為核心的，即：為玩家提供進入具體的遊戲房間的通道，讓玩家順利進入其欲進入的遊戲房間。玩家根據各個遊戲房間線上人數，判定自己進入哪一個房間，然後輕按兩下伺服器清單中的某個遊戲房間後玩家開始進入遊戲房間伺服器。

　　遊戲房間伺服器：遊戲房間伺服器，具體地說就是如“鬥地主1”，“鬥地主2”這樣的遊戲房間。遊戲房間伺服器才是具體的負責執行遊戲相關邏輯的伺服器。這樣的遊戲邏輯分為兩大類：一類是通用的遊戲房間邏輯，如：進入房間，離開房間，進入桌子，離開桌子以及在房間内說話等；第二類是遊戲桌子邏輯，這個就是各種不同類型遊戲的主要差別之處了，比如鬥地主中的叫地主或不叫地主的邏輯等，當然，遊戲桌子邏輯裡也包括有通用的各個遊戲裡都存在的遊戲邏輯，比如在桌子内說話等。總之，遊戲房間伺服器才是真正負責執行遊戲具體邏輯的伺服器。

　　這裡提到的三類伺服器，我均采用的是完成端口模型，每個伺服器最多連接配接數目是5000人，但是，我在遊戲房間伺服器上作了邏輯層的限定，最多隻允許300人同時線上。其他兩個伺服器仍然允許最多5000人的同時線上。如果按照這樣的結構來設計，那麼要實作百萬人的同時線上就應該是這樣：首先是大廳，1000000/5000＝200。也就是說，至少要200台大廳伺服器，但通常情況下，考慮到實際使用時伺服器的處理能力和負載情況，應該至少準備250台左右的大廳伺服器程式。另外，具體的各種類型的遊戲房間伺服器需要多少，就要根據目前玩各種類型遊戲的玩家數目分别計算了，比如鬥地主最多是十萬人同時線上，每台伺服器最多允許300人同時線上，那麼需要的鬥地主伺服器數目就應該不少于：100000/300=333，準備得充分一點，就要準備350台鬥地主伺服器。

　　除正常的玩家連接配接外，還要考慮到：

　　對于登陸伺服器，會有250台大廳伺服器連接配接到每個登陸伺服器上，這是始終都要保持的連接配接；

　　而對于大廳伺服器而言，如果僅僅有鬥地主這一類的伺服器，就要有350多個連接配接與各個大廳伺服器始終保持着。是以從這一點看，我的結構在某些方面還存在着需要改進的地方，但核心思想是：盡快地提供使用者登陸的速度，盡可能友善地讓玩家進入遊戲中。

posted @ 2011-06-28 15:57 李sir 閱讀(152) 評論(0) 編輯

穩定高效大型系統架構---叢集中間件開發

那現在來說，穩定的中間件應該是什麼樣子呢？

對于用戶端請求，如果發現服務停止，可以實作服務無縫轉移－－－這叫不丢失任何服務.

對于多個用戶端請求，可以講請求輪巡到不同的伺服器上－－－這樣叫負荷平攤，如果再做到可以根據用戶端數量方面地增減伺服器數量，那就能很通過簡單增加伺服器，實作系統效率的提升。

最牛的是，如果你再加上分布式程式設計。一個函數，根據伺服器負荷平攤的特點，可以讓多個伺服器，同時為一個函數工作。

思考：

第一：用戶端請求，實作輪巡。

知道了請求，需要輪巡。就要先知道有那些伺服器－－－》設計伺服器注冊登出機制。

還要知道請求目前，每台伺服器上有那些負荷－－－》用戶端請求計算機制。

然後根據這些，計算目前請求由那個伺服器來完成任務。

第二：故障熱切換

經試驗驗證，故障有三種情況

A）請求選擇伺服器前，有故障。

B）伺服器選中後，準備開始要服務時，故障。

C)服務正在進行時，發生故障

為解決以上問題，我做出如下架構：

1、在用戶端，開發了安全通路機制，保證在有服務存在的情況，單次的通路異常，可以容錯；同時若通路時發生故障，重新請求。

2、中間層開發了負荷平衡機制，其建立的叢集，對用戶端來說，是一個透明體。用戶端隻需要知道公布的服務叢集IP位址，由負荷平衡自動配置設定請求；同時伺服器發生故障時，自動從叢集中移去，将請求切換至其它正常的伺服器上。(中間層是一個無狀态，多線程，分布式的應用程式服務，對任何一個請求，由哪台伺服器提供服務都可以達到一緻的目标)

posted @ 2011-06-28 15:47 李sir 閱讀(74) 評論(0) 編輯

淺談大型網站動态應用系統架構

動态應用，是相對于網站靜态内容而言，是指以c/c++、php、Java、perl、.net等伺服器端語言開發的網絡應用軟體，比如論壇、網絡相冊、交友、BLOG等常見應用。動态應用系統通常與資料庫系統、緩存系統、分布式存儲系統等密不可分。

大型動态應用系統平台主要是針對于大流量、高并發網站建立的底層系統架構。大型網站的運作需要一個可靠、安全、可擴充、易維護的應用系統平台做為支撐，以保證網站應用的平穩運作。

大型動态應用系統又可分為幾個子系統：

l Web前端系統

l 負載均衡系統

l 資料庫叢集系統

l 緩存系統

l 分布式存儲系統

l 分布式伺服器管理系統

l 代碼分發系統

Web前端系統

結構圖：

為了達到不同應用的伺服器共享、避免單點故障、集中管理、統一配置等目的，不以應用劃分伺服器，而是将所有伺服器做統一使用，每台伺服器都可以對多個應用提供服務，當某些應用通路量升高時，通過增加伺服器節點達到整個伺服器叢集的性能提高，同時使他應用也會受益。該Web前端系統基于Apache/Lighttpd/Eginx等的虛拟主機平台，提供PHP程式運作環境。伺服器對開發人員是透明的，不需要開發人員介入伺服器管理

負載均衡系統

負載均衡系統分為硬體和軟體兩種。硬體負載均衡效率高，但是價格貴，比如F5等。軟體負載均衡系統價格較低或者免費，效率較硬體負載均衡系統低，不過對于流量一般或稍大些網站來講也足夠使用，比如lvs/nginx/haproxy。大多數網站都是硬體、軟體負載均衡系統并用。

資料庫叢集系統

結構圖：

由于Web前端采用了負載均衡叢集結構提高了服務的有效性和擴充性，是以資料庫必須也是高可靠的才能保證整個服務體系的高可靠性，如何建構一個高可靠的、可以提供大規模并發處理的資料庫體系？

我們可以采用如上圖所示的方案：

1) 使用 MySQL 資料庫，考慮到Web應用的資料庫讀多寫少的特點，我們主要對讀資料庫做了優化，提供專用的讀資料庫和寫資料庫，在應用程式中實作讀操作和寫操作分别通路不同的資料庫。

2) 使用 MySQL Replication 機制實作快速将主庫（寫庫）的資料庫複制到從庫（讀庫）。一個主庫對應多個從庫，主庫資料實時同步到從庫。

3) 寫資料庫有多台，每台都可以提供多個應用共同使用，這樣可以解決寫庫的性能瓶頸問題和單點故障問題。

4) 讀資料庫有多台，通過負載均衡裝置實作負載均衡，進而達到讀資料庫的高性能、高可靠和高可擴充性。

5) 資料庫伺服器和應用伺服器分離。

6) 從資料庫使用BigIP做負載均衡。

緩存系統

緩存分為檔案緩存、記憶體緩存、資料庫緩存。在大型Web應用中使用最多且效率最高的是記憶體緩存。最常用的記憶體緩存工具是Memcachd。使用正确的緩存系統可以達到實作以下目标：

1、使用緩存系統可以提高通路效率，提高伺服器吞吐能力，改善使用者體驗。

2、減輕對資料庫及存儲集伺服器的通路壓力

3、 Memcached伺服器有多台，避免單點故障，提供高可靠性和可擴充性，提高性能。

分布式存儲系統

結構圖：

WEB系統平台中的存儲需求有下面兩個特點：

1) 存儲量很大，經常會達到單台伺服器無法提供的規模，比如相冊、視訊等應用。是以需要專業的大規模存儲系統。

2) 負載均衡cluster中的每個節點都有可能通路任何一個資料對象，每個節點對資料的處理也能被其他節點共享，是以這些節點要操作的資料從邏輯上看隻能是一個整體，不是各自獨立的資料資源。

是以高性能的分布式存儲系統對于大型網站應用來說是非常重要的一環。（這個地方需要加入對某個分布式存儲系統的簡單介紹。）

分布式伺服器管理系統

結構圖：

随着網站通路流量的不斷增加，大多的網絡服務都是以負載均衡叢集的方式對外提供服務，随之叢集規模的擴大，原來基于單機的伺服器管理模式已經不能夠滿足我們的需求，新的需求必須能夠集中式的、分組的、批量的、自動化的對伺服器進行管理，能夠批量化的執行計劃任務。

在分布式伺服器管理系統軟體中有一些比較優秀的軟體，其中比較理想的一個是 Cfengine。它可以對伺服器進行分組，不同的分組可以分别定制系統配置檔案、計劃任務等配置。它是基于C/S 結構的，所有的伺服器配置和管理腳本程式都儲存在Cfengine Server上，而被管理的伺服器運作着 Cfengine Client 程式，Cfengine Client通過SSL加密的連接配接定期的向伺服器端發送請求以擷取最新的配置檔案和管理指令、腳本程式、更新檔安裝等任務。

有了Cfengine 這種集中式的伺服器管理工具，我們就可以高效的實作大規模的伺服器叢集管理，被管理伺服器和 Cfengine Server 可以分布在任何位置，隻要網絡可以連通就能實作快速自動化的管理。

代碼釋出系統

結構圖：

随着網站通路流量的不斷增加，大多的網絡服務都是以負載均衡叢集的方式對外提供服務，随之叢集規模的擴大，為了滿足叢集環境下程式代碼的批量分發和更新，我們還需要一個程式代碼釋出系統。

這個釋出系統可以幫我們實作下面的目标：

1) 生産環境的伺服器以虛拟主機方式提供服務，不需要開發人員介入維護和直接操作，提供釋出系統可以實作不需要登陸伺服器就能把程式分發到目标伺服器。

2) 我們要實作内部開發、内部測試、生産環境測試、生産環境釋出的4個開發階段的管理，釋出系統可以介入各個階段的代碼釋出。

3) 我們需要實作源代碼管理和版本控制，SVN可以實作該需求。

這裡面可以使用常用的工具Rsync，通過開發相應的腳本工具實作伺服器叢集間代碼同步分發。

posted @ 2011-06-28 15:38 李sir 閱讀(147) 評論(0) 編輯

大型網站采用的具有穩定性的系統構架

千萬級的注冊使用者，千萬級的文章，nTB級的附件，還有巨大的日通路量，大型網站采用什麼系統架構保證性能和穩定性？

首先讨論一下大型網站需要注意和考慮的問題。

資料庫海量資料處理：負載量不大的情況下select、delete和update是響應很迅速的，最多加幾個索引就可以搞定，但千萬級的注冊使用者和一個設計不好的多對多關系将帶來非常嚴重的性能問題。另外在高UPDATE的情況下，更新一個聚焦索引的時間基本上是不可忍受的。索引和更新是一對天生的冤家。

高并發死鎖：平時我們感覺不到，但資料庫死鎖在高并發的情況下的出現的機率是非常高的。

檔案存儲的問題：大型網站有海量圖檔資料、視訊資料、檔案資料等等，他們如何存儲并被有效索引？高并發的情況下IO的瓶頸問題會迅速顯現。也許用RAID和專用存貯伺服器能解決眼下的問題，但是還有個問題就是各地的通路問題，也許我們的伺服器在北京，可能在雲南或者新疆的通路速度如何解決？如果做分布式，那麼我們的檔案索引以及架構該如何規劃。

接下來讨論大型網站的底層系統架構，來有效的解決上述問題。

毋庸置疑，對于規模稍大的網站來說，其背後必然是一個伺服器叢集來提供網站服務，例如，2004年eBay的伺服器有2400台，估計現在更多。當然，資料庫也必然要和應用服務分開，有單獨的資料庫伺服器叢集。對于像淘寶網這樣規模的網站而言，就是應用也分成很多組。

下面，就從伺服器作業系統與Web伺服器、資料庫、伺服器叢集與負載均衡、緩存、獨立的圖檔伺服器、其它等幾個方面來分析大型網站的系統架構。

伺服器作業系統與Web伺服器

最底層首先是作業系統。好的作業系統能提高好的性能、穩定性和安全性，而這些對大型網站的性能、安全性和穩定性都是至關重要的。

淘寶網（阿裡巴巴）： Linux作業系統 + Web 伺服器： Apache

新浪：FreeBSD + Web 伺服器：Apache

Yahoo：FreeBSD + Web 伺服器：自己的

Google：部分Linux + Web 伺服器：自己的

百度：Linux + Web 伺服器： Apache

網易：Linux + Web 伺服器： Apache

eBay： Windows Server 2003/8 （大量） + Web 伺服器：Microsoft IIS

MySpace： Windows Server 2003/8 + Web 伺服器：Microsoft IIS

由此可見，開源作業系統做Web應用是首選已經是一個既定事實。在開源作業系統中Linux和FreeBSD差不太多，很難說哪個一定比另外一個要優秀很多、能夠全面的超越對手，應該是各有所長。但熟悉Linux的技術人員更多些，利于系統管理、優化等，是以Linux使用更廣泛。而Windows Server和IIS雖然有的網站使用，但不開源，而且需要購買微軟的一系列應用産品，限制了其使用。總之，開源作業系統，尤其是Linux做Web應用是首選已經是一個既定事實。

常用的系統架構是：

Linux + Apache + PHP + MySQL

Linux + Apache + Java （WebSphere） + Oracle

Windows Server 2003/2008 + IIS + C#/ASP.NET + 資料庫

資料庫

因為是千萬人同時通路的網站，是以一般是有很多個資料庫同時工作的，說明白一點就是資料庫叢集和并發控制，資料分布到地理位置不同的資料中心，以免發生斷電事故。

主流的資料庫有Sun的是MySQL和Oracle。

Oracle是一款優秀的、廣泛采用的商業資料庫管理軟體。有很強大的功能和安全性，可以處理相對海量的資料。而MySQL是一款非常優秀的開源資料庫管理軟體，非常适合用多台PC Server組成多點的存儲節點陣列（這裡我所指的不是MySQL自身提供的叢集功能），每機關的資料存儲成本也非常的低廉。用多台PC Server安裝MySQL組成一個存儲節點陣列，通過MySQL自身的Replication或者應用自身的處理，可以很好的保證容錯（允許部分節點失效），保證應用的健壯性和可靠性。可以這麼說，在關系資料庫管理系統的選擇上，可以考慮應用本身的情況來決定。

MySQL資料庫伺服器的master-slave模式，利用資料庫伺服器在主從伺服器間進行同步，應用隻把資料寫到主伺服器，而讀資料時則根據負載選擇一台從伺服器或者主伺服器來讀取，将資料按不同政策劃分到不同的伺服器（組）上，分散資料庫壓力。

伺服器叢集與負載均衡

伺服器群集中每個服務結點運作一個所需伺服器程式的獨立拷貝，而網絡負載均衡則将工作負載在這些主機間進行配置設定。負載均衡建立在現有網絡結構之上，它提供了一種廉價有效的方法擴充伺服器帶寬和增加吞吐量，加強網絡資料處理能力，提高網絡的靈活性和可用性。它主要完成以下任務：解決網絡擁塞問題，服務就近提供，實作地理位置無關性 ;為使用者提供更好的通路品質;提高伺服器響應速度;提高伺服器及其他資源的利用效率;避免了網絡關鍵部位出現單點失效。

常用的伺服器叢集和資料庫叢集負載均衡實作方法：

Citrix NetScaler的硬體負載均衡交換機做伺服器叢集的負載均衡。

MySQL Proxy做MySQL伺服器叢集的負載均衡并實作讀寫分離。其實作讀寫分離的基本原理是讓主資料庫處理事務性查詢，而從資料庫處理SELECT查詢。資料庫複制被用來把事務性查詢導緻的變更同步到叢集中的從資料庫。

CDN （Content Delivery Network）：幾乎在各大網站都有使用該技術。例如，使得你的網站在各省市通路更快，其原理是采取了分布式網絡緩存結構（即國際上流行的web cache技術），通過在現有的Internet中增加一層新的網絡架構，将網站的内容釋出到最接近使用者的cache伺服器内，通過DNS負載均衡的技術，判斷使用者來源就近通路cache伺服器取得所需的内容，解決Internet網絡擁塞狀況，提高使用者通路網站的響應速度，如同提供了多個分布在各地的加速器，以達到快速、可備援的為多個網站加速的目的。

緩存

衆所周知，使用緩存能有效應對大負載，減少資料庫的壓力，并顯著提高多層應用程式的性能，但如何在叢集環境中使多個緩存、多層緩存并儲存同步是個重大問題。大型網站一般都使用緩存伺服器群，并使用多層緩存。業内最常用的有：

Squid cache，Squid伺服器群，把它作為web伺服器端前置cache伺服器緩存相關請求來提高web伺服器速度。Squid将大部分靜态資源（圖檔，js，css等）緩存起來，直接傳回給通路者，減少應用伺服器的負載

memcache，memcache伺服器群，一款分布式緩存産品，很多大型網站在應用; 它可以應對任意多個連接配接，使用非阻塞的網絡IO。由于它的工作機制是在記憶體中開辟一塊空間，然後建立一個HashTable，Memcached自管理這些HashTable。

e-Accelerator，比較特殊，PHP的緩存和加速器。是一個免費開源的PHP加速、優化、編譯和動态緩存的項目，它可以通過緩存PHP代碼編譯後的結果來提高PHP腳本的性能，使得一向很複雜和離我們很遠的 PHP腳本編譯問題完全得到解決。通過使用eAccelerator，可以優化你的PHP代碼執行速度，降低伺服器負載，可以提高PHP應用執行速度最高達10倍。

獨立的圖檔伺服器

無論從管理上，還是從性能上看，隻要有可能，盡量部署獨立的圖檔伺服器。這幾乎成為常識了。具備獨立的圖檔伺服器或者伺服器叢集後，在 Web 伺服器上就可以有針對性的進行配置優化。

其他

一個網際網路應用，除了伺服器的作業系統，Web Server軟體，應用伺服器軟體，資料庫軟體外，我們還會涉及到一些其他的系統，比如一些中間件系統、檔案存儲系統（圖檔伺服器，視訊伺服器，管理伺服器，RSS和廣告伺服器等等）、全文檢索、搜尋、等等。會在以後介紹。

posted @ 2011-06-28 15:31 李sir 閱讀(55) 評論(0) 編輯

網站構架師進行大型網站構架的步驟

架構演變第一步：實體分離webserver和資料庫

最開始，由于某些想法，于是在網際網路上搭建了一個網站，這個時候甚至有可能主機都是租借的，但由于這篇文章我們隻關注架構的演變曆程，是以就假設這個時候已經是托管了一台主機，并且有一定的帶寬了，這個時候由于網站具備了一定的特色，吸引了部分人通路，逐漸你發現系統的壓力越來越高，響應速度越來越慢，而這個時候比較明顯的是資料庫和應用互相影響，應用出問題了，資料庫也很容易出現問題，而資料庫出問題的時候，應用也容易出問題，于是進入了第一步演變階段：将應用和資料庫從實體上分離，變成了兩台機器，這個時候技術上沒有什麼新的要求，但你發現确實起到效果了，系統又恢複到以前的響應速度了，并且支撐住了更高的流量，并且不會因為資料庫和應用形成互相的影響。

這一步涉及到了這些知識體系：

這一步架構演變對技術上的知識體系基本沒有要求。

構架構演變第二步：增加頁面緩存

好景不長，随着通路的人越來越多，你發現響應速度又開始變慢了，查找原因，發現是通路資料庫的操作太多，導緻資料連接配接競争激烈，是以響應變慢，但資料庫連接配接又不能開太多，否則資料庫機器壓力會很高，是以考慮采用緩存機制來減少資料庫連接配接資源的競争和對資料庫讀的壓力，這個時候首先也許會選擇采用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鏡像等來支撐更大的流量，是以在真實的發展過程中還會有很多的不同，另外一個大型網站要做到的遠遠不僅僅上面這些，還有像安全、運維、營運、服務、存儲等，要做好一個大型的網站真的很不容易。

posted @ 2011-06-28 15:26 李sir 閱讀(59) 評論(0) 編輯

memcached的分布式算法-Consistent Hashing

前言：

我們知道以往資料要放到 M 台伺服器上，最簡單的方法就是取餘數 (de>hash_value % Mde>) 然後放到對應的伺服器上，那就是當添加或移除伺服器時，緩存重組的代價相當巨大。添加伺服器後，餘數就會産生巨變，這樣就無法擷取與儲存時相同的伺服器，進而影響緩存的命中率。

下面這篇文章寫的非常好，結合memcached的特點利用Consistent hasning 算法，可以打造一個非常完備的分布式緩存伺服器。

我是Mixi的長野。本次不再介紹memcached的内部結構，開始介紹memcached的分布式。

memcached的分布式
- memcached的分布式是什麼意思？
Cache::Memcached的分布式方法
- 根據餘數計算分散
- 根據餘數計算分散的缺點
Consistent Hashing
- Consistent Hashing的簡單說明
- 支援Consistent Hashing的函數庫
總結

memcached的分布式

正如第1次中介紹的那樣， memcached雖然稱為“分布式”緩存伺服器，但伺服器端并沒有“分布式”功能。伺服器端僅包括第2次、第3次前坂介紹的記憶體存儲功能，其實作非常簡單。至于memcached的分布式，則是完全由用戶端程式庫實作的。這種分布式是memcached的最大特點。

memcached的分布式是什麼意思？

這裡多次使用了“分布式”這個詞，但并未做詳細解釋。現在開始簡單地介紹一下其原理，各個用戶端的實作基本相同。

下面假設memcached伺服器有node1～node3三台，應用程式要儲存鍵名為“tokyo”“kanagawa”“chiba”“saitama”“gunma” 的資料。

圖1 分布式簡介：準備

首先向memcached中添加“tokyo”。将“tokyo”傳給用戶端程式庫後，用戶端實作的算法就會根據“鍵”來決定儲存資料的memcached伺服器。伺服器標明後，即指令它儲存“tokyo”及其值。

圖2 分布式簡介：添加時

同樣，“kanagawa”“chiba”“saitama”“gunma”都是先選擇伺服器再儲存。

接下來擷取儲存的資料。擷取時也要将要擷取的鍵“tokyo”傳遞給函數庫。函數庫通過與資料儲存時相同的算法，根據“鍵”選擇伺服器。使用的算法相同，就能選中與儲存時相同的伺服器，然後發送get指令。隻要資料沒有因為某些原因被删除，就能獲得儲存的值。

圖3 分布式簡介：擷取時

這樣，将不同的鍵儲存到不同的伺服器上，就實作了memcached的分布式。 memcached伺服器增多後，鍵就會分散，即使一台memcached伺服器發生故障無法連接配接，也不會影響其他的緩存，系統依然能繼續運作。

接下來介紹第1次中提到的Perl用戶端函數庫Cache::Memcached實作的分布式方法。

Cache::Memcached的分布式方法

Perl的memcached用戶端函數庫Cache::Memcached是 memcached的作者Brad Fitzpatrick的作品，可以說是原裝的函數庫了。

Cache::Memcached - search.cpan.org

該函數庫實作了分布式功能，是memcached标準的分布式方法。

根據餘數計算分散

Cache::Memcached的分布式方法簡單來說，就是“根據伺服器台數的餘數進行分散”。求得鍵的整數哈希值，再除以伺服器台數，根據其餘數來選擇伺服器。

下面将Cache::Memcached簡化成以下的Perl腳本來進行說明。

use strict;

use warnings;

use String::CRC32;

my @nodes = (’node1′,’node2′,’node3′);

my @keys = (’tokyo’, ‘kanagawa’, ‘chiba’, ’saitama’, ‘gunma’);

foreach my $key (@keys) {

my $crc = crc32($key); # CRC値

my $mod = $crc % ( $#nodes + 1 );

my $server = $nodes[ $mod ]; # 根據餘數選擇伺服器

printf “%s => %s\n”, $key, $server;

}

Cache::Memcached在求哈希值時使用了CRC。

String::CRC32 - search.cpan.org

首先求得字元串的CRC值，根據該值除以伺服器節點數目得到的餘數決定伺服器。上面的代碼執行後輸入以下結果：

tokyo       => node2 kanagawa => node3 chiba       => node2 saitama   => node1 gunma     => node1

根據該結果，“tokyo”分散到node2，“kanagawa”分散到node3等。多說一句，當選擇的伺服器無法連接配接時，Cache::Memcached會将連接配接次數添加到鍵之後，再次計算哈希值并嘗試連接配接。這個動作稱為rehash。不希望rehash時可以在生成Cache::Memcached對象時指定“rehash => 0”選項。

根據餘數計算分散的缺點

餘數計算的方法簡單，資料的分散性也相當優秀，但也有其缺點。那就是當添加或移除伺服器時，緩存重組的代價相當巨大。添加伺服器後，餘數就會産生巨變，這樣就無法擷取與儲存時相同的伺服器，進而影響緩存的命中率。用Perl寫段代碼來驗證其代價。

use strict;

use warnings;

use String::CRC32;

my @nodes = @ARGV;

my @keys = (’a’..’z\');

my %nodes;

foreach my $key ( @keys ) {

my $hash = crc32($key);

my $mod = $hash % ( $#nodes + 1 );

my $server = $nodes[ $mod ];

push @{ $nodes{ $server } }, $key;

}

foreach my $node ( sort keys %nodes ) {

printf “%s: %s\n”, $node, join “,”, @{ $nodes{$node} };

}

這段Perl腳本示範了将“a”到“z”的鍵儲存到memcached并通路的情況。将其儲存為mod.pl并執行。

首先，當伺服器隻有三台時：

$ mod.plnode1 node2nod3

node1: a,c,d,e,h,j,n,u,w,x

node2: g,i,k,l,p,r,s,y

node3: b,f,m,o,q,t,v,z

結果如上，node1儲存a、c、d、e……，node2儲存g、i、k……，每台伺服器都儲存了8個到10個資料。

接下來增加一台memcached伺服器。

$ mod.plnode1 node2node3 node4

node1: d,f,m,o,t,v

node2: b,i,k,p,r,y

node3: e,g,l,n,u,w

node4: a,c,h,j,q,s,x,z

添加了node4。可見，隻有d、i、k、p、r、y命中了。像這樣，添加節點後鍵分散到的伺服器會發生巨大變化。26個鍵中隻有六個在通路原來的伺服器，其他的全都移到了其他伺服器。命中率降低到23%。在Web應用程式中使用memcached時，在添加memcached伺服器的瞬間緩存效率會大幅度下降，負載會集中到資料庫伺服器上，有可能會發生無法提供正常服務的情況。

mixi的Web應用程式運用中也有這個問題，導緻無法添加memcached伺服器。但由于使用了新的分布式方法，現在可以輕而易舉地添加memcached伺服器了。這種分布式方法稱為 Consistent Hashing。

Consistent Hashing

關于Consistent Hashing的思想，mixi株式會社的開發blog等許多地方都介紹過，這裡隻簡單地說明一下。

mixi Engineers’ Blog - スマートな分散で快適キャッシュライフ
ConsistentHashing - コンシステントハッシュ法

Consistent Hashing的簡單說明

Consistent Hashing如下所示：首先求出memcached伺服器（節點）的哈希值，并将其配置到0～232的圓（continuum）上。然後用同樣的方法求出存儲資料的鍵的哈希值，并映射到圓上。然後從資料映射到的位置開始順時針查找，将資料儲存到找到的第一個伺服器上。如果超過232仍然找不到伺服器，就會儲存到第一台memcached伺服器上。

圖4 Consistent Hashing：基本原理

從上圖的狀态中添加一台memcached伺服器。餘數分布式算法由于儲存鍵的伺服器會發生巨大變化而影響緩存的命中率，但Consistent Hashing中，隻有在continuum上增加伺服器的地點逆時針方向的第一台伺服器上的鍵會受到影響。

圖5 Consistent Hashing：添加伺服器

是以，Consistent Hashing最大限度地抑制了鍵的重新分布。而且，有的Consistent Hashing的實作方法還采用了虛拟節點的思想。使用一般的hash函數的話，伺服器的映射地點的分布非常不均勻。是以，使用虛拟節點的思想，為每個實體節點（伺服器）在continuum上配置設定100～200個點。這樣就能抑制分布不均勻，最大限度地減小伺服器增減時的緩存重新分布。

通過下文中介紹的使用Consistent Hashing算法的memcached用戶端函數庫進行測試的結果是，由伺服器台數（n）和增加的伺服器台數（m）計算增加伺服器後的命中率計算公式如下：

(1 - n/(n+m)) * 100

支援Consistent Hashing的函數庫

本連載中多次介紹的Cache::Memcached雖然不支援Consistent Hashing，但已有幾個用戶端函數庫支援了這種新的分布式算法。第一個支援Consistent Hashing和虛拟節點的memcached用戶端函數庫是名為libketama的PHP庫，由last.fm開發。

libketama - a consistent hashing algo for memcache clients – RJ ブログ - Users at Last.fm

至于Perl用戶端，連載的第1次中介紹過的Cache::Memcached::Fast和Cache::Memcached::libmemcached支援 Consistent Hashing。

Cache::Memcached::Fast - search.cpan.org
Cache::Memcached::libmemcached - search.cpan.org

兩者的接口都與Cache::Memcached幾乎相同，如果正在使用Cache::Memcached，那麼就可以友善地替換過來。Cache::Memcached::Fast重新實作了libketama，使用Consistent Hashing建立對象時可以指定ketama_points選項。

my $memcached = Cache::Memcached::Fast->new({ servers => ["192.168.0.1:11211","192.168.0.2:11211"], ketama_points => 150 });

另外，Cache::Memcached::libmemcached 是一個使用了Brain Aker開發的C函數庫libmemcached的Perl子產品。 libmemcached本身支援幾種分布式算法，也支援Consistent Hashing，其Perl綁定也支援Consistent Hashing。

Tangent Software: libmemcached

總結

本次介紹了memcached的分布式算法，主要有memcached的分布式是由用戶端函數庫實作，以及高效率地分散資料的Consistent Hashing算法。下次将介紹mixi在memcached應用方面的一些經驗，和相關的相容應用程式。

posted @ 2011-06-28 14:52 李sir 閱讀(68) 評論(0) 編輯

開源分布式檔案系統

FastDFS是一個開源的輕量級分布式檔案系統，她對檔案進行管理，功能包括：檔案存儲、檔案同步、檔案通路（檔案上傳、檔案下載下傳）等，解決了大容量存儲和負載均衡的問題。特别适合以檔案為載體的線上服務，如相冊網站、視訊網站等等。

FastDFS服務端有兩個角色：跟蹤器（tracker）和存儲節點（storage）。跟蹤器主要做排程工作，在通路上起負載均衡的作用。

存儲節點存儲檔案，完成檔案管理的所有功能：存儲、同步和提供存取接口，FastDFS同時對檔案的metadata進行管理。所謂檔案的meta data就是檔案的相關屬性，以鍵值對（key valuepair）方式表示，如：width=1024，其中的key為width，value為1024。檔案metadata是檔案屬性清單，可以包含多個鍵值對。

FastDFS系統結構如下圖所示：

跟蹤器和存儲節點都可以由一台多台伺服器構成。跟蹤器和存儲節點中的伺服器均可以随時增加或下線而不會影響線上服務。其中跟蹤器中的所有伺服器都是對等的，可以根據伺服器的壓力情況随時增加或減少。

為了支援大容量，存儲節點（伺服器）采用了分卷（或分組）的組織方式。存儲系統由一個或多個卷組成，卷與卷之間的檔案是互相獨立的，所有卷的檔案容量累加就是整個存儲系統中的檔案容量。一個卷可以由一台或多台存儲伺服器組成，一個卷下的存儲伺服器中的檔案都是相同的，卷中的多台存儲伺服器起到了備援備份和負載均衡的作用。

在卷中增加伺服器時，同步已有的檔案由系統自動完成，同步完成後，系統自動将新增伺服器切換到線上提供服務。

當存儲空間不足或即将耗盡時，可以動态添加卷。隻需要增加一台或多台伺服器，并将它們配置為一個新的卷，這樣就擴大了存儲系統的容量。

FastDFS中的檔案辨別分為兩個部分：卷名和檔案名，二者缺一不可。

FastDFS file upload

上傳檔案互動過程：

1. client詢問tracker上傳到的storage，不需要附加參數；

2. tracker傳回一台可用的storage；

3. client直接和storage通訊完成檔案上傳。

FastDFS file download

下載下傳檔案互動過程：

1. client詢問tracker下載下傳檔案的storage，參數為檔案辨別（卷名和檔案名）；

2. tracker傳回一台可用的storage；

3. client直接和storage通訊完成檔案下載下傳。

需要說明的是，client為使用FastDFS服務的調用方，client也應該是一台伺服器，它對tracker和storage的調用均為伺服器間的調用。

google code位址：http://code.google.com/p/fastdfs/

google code下載下傳位址：http://code.google.com/p/fastdfs/downloads/list

MogileFS一個開源的分布式檔案系統

1.應用層——沒有特殊的元件要求

2.無單點失敗——MogileFS啟動的三個元件（存儲節點、跟蹤器、跟蹤用的資料庫），均可運作在多個機器上，是以沒有單點失敗。（你也可以将跟蹤器和存儲節點運作在同一台機器上，這樣你就沒有必要用4台機器）推薦至少兩台機器。

3.自動的檔案複制——檔案是基于他們的“類”，檔案可以自動的在多個存儲節點上複制，這是為了盡量少的複制，才使用“類”的。加入你有的圖檔站點有三份JPEG圖檔的拷貝，但實際隻有1or2份拷貝，那麼Mogile可以重建立立遺失的拷貝數。用這種辦法，MogileFS(不做RAID)可以節約在磁盤，否則你将存儲同樣的拷貝多份，完全沒有必要。

4.“比RAID好多了”——在一個非存儲區域網絡的RAID（non-SAN RAID）的建立中，磁盤是備援的，但主機不是，如果你整個機器壞了，那麼檔案也将不能通路。 MogileFS在不同的機器之間進行檔案複制，是以檔案始終是可用的。

5.傳輸中立，無特殊協定——MogileFS用戶端可以通過NFS或HTTP來和MogileFS的存儲節點來通信，但首先需要告知跟蹤器一下。

6.簡單的命名空間——檔案通過一個給定的key來确定，是一個全局的命名空間。你可以自己生成多個命名空間，隻要你願意，但是這樣可能在同一MogileFS中，會造成沖突key。

7.不用共享任何東西——MogileFS不需要依靠昂貴的SAN來共享磁盤，每個機器隻用維護好自己的磁盤。

8.不需要RAID——在MogileFS中的磁盤可以是做了RAID的也可以是沒有，如果是為了安全性着想的話RAID沒有必要買了，因為MogileFS已經提供了。

9.不會碰到檔案系統本身的不可知情況——在MogileFS中的存儲節點的磁盤可以被格式化成多種格（ext3,reiserFS等等）。MogilesFS會做自己内部目錄的哈希，是以它不會碰到檔案系統本身的一些限制，比如一個目錄中的最大檔案數。你可以放心的使用。

FastFDS和MogileFS的對比

FastDFS設計時借鑒了MogileFS的一些思路。FastDFS是一個完善的分布式檔案存儲系統，通過用戶端API對檔案進行讀寫。可以說，MogileFS的所有功能特性FastDFS都具備，MogileFS網址：http://www.danga.com/mogilefs/。

另外，相對于MogileFS，FastDFS具有如下特點和優勢：

1. FastDFS完善程度較高，不需要二次開發即可直接使用；

2. 和MogileFS相比，FastDFS裁減了跟蹤用的資料庫，隻有兩個角色：tracker和storage。FastDFS的架構既簡化了系統，同時也消除了性能瓶頸；

3. 在系統中增加任何角色的伺服器都很容易：增加tracker伺服器時，隻需要修改storage和client的配置檔案（增加一行tracker配置）；增加storage伺服器時，通常不需要修改任何配置檔案，系統會自動将該卷中已有檔案複制到該伺服器；

4. FastDFS比MogileFS更高效。表現在如下幾個方面：

1）參見上面的第2點，FastDFS和MogileFS相比，沒有檔案索引資料庫，FastDFS整體性能更高；

2）從采用的開發語言上看，FastDFS比MogileFS更底層、更高效。FastDFS用C語言編寫，代碼量不到2萬行，沒有依賴其他開源軟體或程式包，安裝和部署特别簡潔；而MogileFS用perl編寫；

3）FastDFS直接使用socket通信方式，相對于MogileFS的HTTP方式，效率更高。并且FastDFS使用sendfile傳輸檔案，采用了記憶體零拷貝，系統開銷更小，檔案傳輸效率更高。

5. FastDFS有着詳細的設計和使用文檔，而MogileFS的文檔相對比較缺乏。

6. FastDFS的日志記錄非常詳細，系統運作時發生的任何錯誤資訊都會記錄到日志檔案中，當出現問題時友善管理者定位錯誤所在。

7. FastDFS還對檔案附加屬性（即meta data，如檔案大小、圖檔寬度、高度等）進行存取，應用不需要使用資料庫來存儲這些資訊。

8. FastDFS從V1.14開始支援相同檔案内容隻儲存一份，這樣可以節省存儲空間，提高檔案通路性能。

posted @ 2011-06-28 14:23 李sir 閱讀(378) 評論(0) 編輯

Net Remoting(應用程式域)

http://www.cnblogs.com/JimmyZhang/archive/2008/07/26/1252183.html

posted @ 2011-06-28 11:20 李sir 閱讀(20) 評論(0) 編輯

c# 序列化

BinaryFormatter

Book類

using System;

using System.Collections;

using System.Text;

namespace SerializableTest

{

[Serializable]

public class Book

{

public Book()

{

alBookReader = new ArrayList();

}

public string strBookName;

[NonSerialized]

public string strBookPwd;

private string _bookID;

public string BookID

{

get { return _bookID; }

set { _bookID = value; }

}

public ArrayList alBookReader;

private string _bookPrice;

public void SetBookPrice(string price)

{

_bookPrice = price;

}

public void Write()

{

Console.WriteLine("Book ID:" + BookID);

Console.WriteLine("Book Name:" + strBookName);

Console.WriteLine("Book Password:" + strBookPwd);

Console.WriteLine("Book Price:" + _bookPrice);

Console.WriteLine("Book Reader:");

for (int i = 0; i < alBookReader.Count; i++)

{

Console.WriteLine(alBookReader[i]);

}

這個類比較簡單，就是定義了一些public字段和一個可讀寫的屬性，一個private字段，一個标記為[NonSerialized]的字段，具體會在下面的例子中展現出來

一、BinaryFormatter序列化方式

1、序列化，就是給Book類指派，然後進行序列化到一個檔案中

Book book = new Book();

book.BookID = "1";

book.alBookReader.Add("gspring");

book.alBookReader.Add("永春");

book.strBookName = "C#強化";

book.strBookPwd = "*****";

book.SetBookPrice("50.00");

BinarySerialize serialize = new BinarySerialize();

serialize.Serialize(book);2、反序列化

BinarySerialize serialize = new BinarySerialize();

Book book = serialize.DeSerialize();

book.Write();3、測試用的

BinarySerialize類

using System;

using System.Collections.Generic;

using System.Text;

using System.IO;

using System.Runtime.Serialization.Formatters.Binary;

namespace SerializableTest

{

public class BinarySerialize

{

string strFile = "c:\\book.data";

public void Serialize(Book book)

{

using (FileStream fs = new FileStream(strFile, FileMode.Create))

{

BinaryFormatter formatter = new BinaryFormatter();

formatter.Serialize(fs, book);

}

public Book DeSerialize()

{

Book book;

using (FileStream fs = new FileStream(strFile, FileMode.Open))

{

BinaryFormatter formatter = new BinaryFormatter();

book = (Book)formatter.Deserialize(fs);

}

return book;

}

主要就是調用System.Runtime.Serialization.Formatters.Binary空間下的BinaryFormatter類進行序列化和反序列化，以縮略型二進制格式寫到一個檔案中去，速度比較快，而且寫入後的檔案已二進制儲存有一定的保密效果。

調用反序列化後的截圖如下：

也就是說除了标記為NonSerialized的其他所有成員都能序列化

二、SoapFormatter序列化方式

調用序列化和反序列化的方法和上面比較類似，我就不列出來了，主要就看看SoapSerialize類

SoapSerialize類

using System;

using System.Collections.Generic;

using System.Text;

using System.IO;

using System.Runtime.Serialization.Formatters.Soap;

namespace SerializableTest

{

public class SoapSerialize

{

string strFile = "c:\\book.soap";

public void Serialize(Book book)

{

using (FileStream fs = new FileStream(strFile, FileMode.Create))

{

SoapFormatter formatter = new SoapFormatter();

formatter.Serialize(fs, book);

}

public Book DeSerialize()

{

Book book;

using (FileStream fs = new FileStream(strFile, FileMode.Open))

{

SoapFormatter formatter = new SoapFormatter();

book = (Book)formatter.Deserialize(fs);

}

return book;

}

主要就是調用System.Runtime.Serialization.Formatters.Soap空間下的SoapFormatter類進行序列化和反序列化，使用之前需要應用System.Runtime.Serialization.Formatters.Soap.dll（.net自帶的）

序列化之後的檔案是Soap格式的檔案(簡單對象通路協定（Simple Object Access Protocol，SOAP），是一種輕量的、簡單的、基于XML的協定，它被設計成在WEB上交換結構化的和固化的資訊。 SOAP 可以和現存的許多網際網路協定和格式結合使用，包括超文本傳輸協定（HTTP），簡單郵件傳輸協定（SMTP），多用途網際郵件擴充協定（MIME）。它還支援從消息系統到遠端過程調用（RPC）等大量的應用程式。SOAP使用基于XML的資料結構和超文本傳輸協定(HTTP)的組合定義了一個标準的方法來使用Internet上各種不同操作環境中的分布式對象。)

調用反序列化之後的結果和方法一相同

XML序列化方式

調用序列化和反序列化的方法和上面比較類似，我就不列出來了，主要就看看XmlSerialize類

XmlSerialize類

using System;

using System.Collections.Generic;

using System.Text;

using System.IO;

using System.Xml.Serialization;

namespace SerializableTest

{

public class XmlSerialize

{

string strFile = "c:\\book.xml";

public void Serialize(Book book)

{

using (FileStream fs = new FileStream(strFile, FileMode.Create))

{

XmlSerializer formatter = new XmlSerializer(typeof(Book));

formatter.Serialize(fs, book);

}

public Book DeSerialize()

{

Book book;

using (FileStream fs = new FileStream(strFile, FileMode.Open))

{

XmlSerializer formatter = new XmlSerializer(typeof(Book));

book = (Book)formatter.Deserialize(fs);

}

return book;

}

從這三個測試類我們可以看出來其實三種方法的調用方式都差不多，隻是具體使用的類不同

xml序列化之後的檔案就是一般的一個xml檔案：

book.xml

<?xml version="1.0"?>

<anyType xsi:type="xsd:string">gspring</anyType>

</alBookReader>

</Book>輸出截圖如下：

也就是說采用xml序列化的方式隻能儲存public的字段和可讀寫的屬性，對于private等類型的字段不能進行序列化

關于循環引用：

比如在上面的例子Book類中加入如下一個屬性：

public Book relationBook;

在調用序列化時使用如下方法：

Book book = new Book();

book.BookID = "1";

book.alBookReader.Add("gspring");

book.alBookReader.Add("永春");

book.strBookName = "C#強化";

book.strBookPwd = "*****";

book.SetBookPrice("50.00");

Book book2 = new Book();

book2.BookID = "2";

book2.alBookReader.Add("gspring");

book2.alBookReader.Add("永春");

book2.strBookName = ".NET強化";

book2.strBookPwd = "*****";

book2.SetBookPrice("40.00");

book.relationBook = book2;

book2.relationBook = book;

BinarySerialize serialize = new BinarySerialize();

serialize.Serialize(book);這樣就會出現循環引用的情況，對于BinarySerialize和SoapSerialize可以正常序列化(.NET内部進行處理了)，對于XmlSerialize出現這種情況會報錯："序列化類型 SerializableTest.Book 的對象時檢測到循環引用。"

posted @ 2011-06-28 11:17 李sir 閱讀(34) 評論(0) 編輯

初識memcached緩存功能

原文：(KrazyNio AT hotmail.com), 2006.04. 06

一、memcached 簡介

在很多場合，我們都會聽到 memcached 這個名字，但很多同學隻是聽過，并沒有用過或實際了解過，隻知道它是一個很不錯的東東。這裡簡單介紹一下，memcached 是高效、快速的分布式記憶體對象緩存系統，主要用于加速 WEB 動态應用程式。

二、memcached 安裝

首先是下載下傳 memcached 了，目前最新版本是 1.1.12，直接從官方網站即可下載下傳到 memcached-1.1.12.tar.gz。除此之外，memcached 用到了 libevent，我下載下傳的是 libevent-1.1a.tar.gz。

接下來是分别将 libevent-1.1a.tar.gz 和 memcached-1.1.12.tar.gz 解開包、編譯、安裝：

# tar -xzf libevent-1.1a.tar.gz

# cd libevent-1.1a

# ./configure --prefix=/usr

# make

# make install

# cd ..

# tar -xzf memcached-1.1.12.tar.gz

# cd memcached-1.1.12

# ./configure --prefix=/usr

# make

# make install

安裝完成之後，memcached 應該在 /usr/bin/memcached。

三、運作 memcached 守護程式

運作 memcached 守護程式很簡單，隻需一個指令行即可，不需要修改任何配置檔案（也沒有配置檔案給你修改）：

/usr/bin/memcached -d -m 128 -l 192.168.1.1 -p 11211 -u httpd

參數解釋：

-d 以守護程式（daemon）方式運作 memcached；

-m 設定 memcached 可以使用的記憶體大小，機關為 M；

-l 設定監聽的 IP 位址，如果是本機的話，通常可以不設定此參數；

-p 設定監聽的端口，預設為 11211，是以也可以不設定此參數；

-u 指定使用者，如果目前為 root 的話，需要使用此參數指定使用者。

當然，還有其它參數可以用，man memcached 一下就可以看到了。

四、memcached 的工作原理

首先 memcached 是以守護程式方式運作于一個或多個伺服器中，随時接受用戶端的連接配接操作，用戶端可以由各種語言編寫，目前已知的用戶端 API 包括 Perl/PHP/Python/Ruby/Java/C#/C 等等。PHP 等用戶端在與 memcached 服務建立連接配接之後，接下來的事情就是存取對象了，每個被存取的對象都有一個唯一的辨別符 key，存取操作均通過這個 key 進行，儲存到 memcached 中的對象實際上是放置記憶體中的，并不是儲存在 cache 檔案中的，這也是為什麼 memcached 能夠如此高效快速的原因。注意，這些對象并不是持久的，服務停止之後，裡邊的資料就會丢失。

三、PHP 如何作為 memcached 用戶端

有兩種方法可以使 PHP 作為 memcached 用戶端，調用 memcached 的服務進行對象存取操作。

第一種，PHP 有一個叫做 memcache 的擴充，Linux 下編譯時需要帶上–enable-memcache[=DIR] 選項，Window 下則在 php.ini 中去掉 php_memcache.dll 前邊的注釋符，使其可用。

除此之外，還有一種方法，可以避開擴充、重新編譯所帶來的麻煩，那就是直接使用 php-memcached-client。

本文選用第二種方式，雖然效率會比擴充庫稍差一些，但問題不大。

四、PHP memcached 應用示例

首先下載下傳 memcached-client.php，在下載下傳了 memcached-client.php 之後，就可以通過這個檔案中的類“memcached”對 memcached 服務進行操作了。其實代碼調用非常簡單，主要會用到的方法有 add()、get()、replace() 和 delete()，方法說明如下：

add ($key, $val, $exp = 0)

往 memcached 中寫入對象，$key 是對象的唯一辨別符，$val 是寫入的對象資料，$exp 為過期時間，機關為秒，預設為不限時間；

get ($key)

從 memcached 中擷取對象資料，通過對象的唯一辨別符 $key 擷取；

replace ($key, $value, $exp=0)

使用 $value 替換 memcached 中辨別符為 $key 的對象内容，參數與 add() 方法一樣，隻有 $key 對象存在的情況下才會起作用；

delete ($key, $time = 0)

删除 memcached 中辨別符為 $key 的對象，$time 為可選參數，表示删除之前需要等待多長時間。

下面是一段簡單的測試代碼，代碼中對辨別符為 \'mykey\' 的對象資料進行存取操作：

<?php

// 包含 memcached 類檔案

require_once(\'memcached-client.php\');

// 選項設定

$options = array(

\'servers\' => array(\'192.168.1.1:11211\'), //memcached 服務的位址、端口，可用多個數組元素表示多個 memcached 服務

\'debug\' => true, //是否打開 debug

\'compress_threshold\' => 10240, //超過多少位元組的資料時進行壓縮

\'persistant\' => false //是否使用持久連接配接

);

// 建立 memcached 對象執行個體

$mc = new memcached($options);

// 設定此腳本使用的唯一辨別符

$key = \'mykey\';

// 往 memcached 中寫入對象

$mc->add($key, \'some random strings\');

$val = $mc->get($key);

echo "n".str_pad(\'$mc->add() \', 60, \'_\')."n";

var_dump($val);

// 替換已寫入的對象資料值

$mc->replace($key, array(\'some\'=>\'haha\', \'array\'=>\'xxx\'));

$val = $mc->get($key);

echo "n".str_pad(\'$mc->replace() \', 60, \'_\')."n";

var_dump($val);

// 删除 memcached 中的對象

$mc->delete($key);

$val = $mc->get($key);

echo "n".str_pad(\'$mc->delete() \', 60, \'_\')."n";

var_dump($val);

是不是很簡單，在實際應用中，通常會把資料庫查詢的結果集儲存到 memcached 中，下次通路時直接從 memcached 中擷取，而不再做資料庫查詢操作，這樣可以在很大程度上減輕資料庫的負擔。通常會将 SQL 語句 md5() 之後的值作為唯一辨別符 key。下邊是一個利用 memcached 來緩存資料庫查詢結果集的示例（此代碼片段緊接上邊的示例代碼）：

<?php

$sql = \'SELECT * FROM users\';

$key = md5($sql); //memcached 對象辨別符

{

// 在 memcached 中未擷取到緩存資料，則使用資料庫查詢擷取記錄集。

echo "n".str_pad(\'Read datas from MySQL.\', 60, \'_\')."n";

$conn = mysql_connect(\'localhost\', \'test\', \'test\');

mysql_select_db(\'test\');

$result = mysql_query($sql);

while ($row = mysql_fetch_object($result))

$datas[] = $row;

// 将資料庫中擷取到的結果集資料儲存到 memcached 中，以供下次通路時使用。

$mc->add($key, $datas);

{

echo "n".str_pad(\'Read datas from memcached.\', 60, \'_\')."n";

}

var_dump($datas);

可以看出，使用 memcached 之後，可以減少資料庫連接配接、查詢操作，資料庫負載下來了，腳本的運作速度也提高了。

之前我曾經寫過一篇名為《PHP 實作多伺服器共享 SESSION 資料》文章，文中的 SESSION 是使用資料庫儲存的，在并發通路量大的時候，伺服器的負載會很大，經常會超出 MySQL 最大連接配接數，利用 memcached，我們可以很好地解決這個問題，工作原理如下：

使用者通路網頁時，檢視 memcached 中是否有目前使用者的 SESSION 資料，使用 session_id() 作為唯一辨別符；如果資料存在，則直接傳回，如果不存在，再進行資料庫連接配接，擷取 SESSION 資料，并将此資料儲存到 memcached 中，供下次使用；目前的 PHP 運作結束（或使用了session_write_close()）時，會調用 My_Sess::write() 方法，将資料寫入資料庫，這樣的話，每次仍然會有資料庫操作，對于這個方法，也需要進行優化。使用一個全局變量，記錄使用者進入頁面時的 SESSION 資料，然後在 write() 方法内比較此資料與想要寫入的 SESSION 資料是否相同，不同才進行資料庫連接配接、寫入資料庫，同時将 memcached 中對應的對象删除，如果相同的話，則表示 SESSION 資料未改變，那麼就可以不做任何操作，直接傳回了；那麼使用者 SESSION 過期時間怎麼解決呢？記得 memcached 的 add() 方法有個過期時間參數 $exp 嗎？把這個參數值設定成小于 SESSION 最大存活時間即可。另外别忘了給那些一直線上的使用者延續 SESSION 時長，這個可以在 write() 方法中解決，通過判斷時間，符合條件則更新資料庫資料。

posted @ 2011-06-28 10:50 李sir 閱讀(34) 評論(0) 編輯

C# 友善的複制/比較物件内資料的方法(Object Copy / Compare)

用 Collection / Object 時經常想用一個物件(Object)去生成另一個物件并保留原有資料(如 DataTable.Copy())，最沒頭沒腦的做法是:

view plaincopy to clipboardprint?

public MyObject Copy()

{

MyObject oNewObject = new MyObject();

oNewObject.Value1 = this.Value1;

oNewObject.Value2 = this.Value2;

oNewObject.Value3 = this.Value3;

return oNewObject;

}

public bool Compare(MyObject oNewObject)

{

return (oNewObject.Value1 == this.Value1

&& oNewObject.Value2 == this.Value2

&& oNewObject.Value3 == this.Value3);

}

public MyObject Copy()

{

MyObject oNewObject = new MyObject();

oNewObject.Value1 = this.Value1;

oNewObject.Value2 = this.Value2;

oNewObject.Value3 = this.Value3;

return oNewObject;

}

public bool Compare(MyObject oNewObject)

{

return (oNewObject.Value1 == this.Value1

&& oNewObject.Value2 == this.Value2

&& oNewObject.Value3 == this.Value3);

}

如果每個物件(Object )隻有十多個屬性(Properties)的話這樣隻是小菜一碟，但當你有數十個物件...每個物件有數十個屬性的話，那就有夠腦殘了...

以下是用Reflection的PropertyInfo去提取物件屬性的例子:

view plaincopy to clipboardprint?

using System.Reflection;

for(int i = 0; i < oOldObject.GetType().GetProperties().Length; i ++)

{

//根據索引提取個别屬性

PropertyInfo oOldObjectProperty = (PropertyInfo) oOldObject.GetType().GetProperties().GetValue(i);

//得到該屬性的資料

Object oOldObjectValue = oOldObjectProperty.GetValue(oOldObject, null);

if (oOldObjectProperty.CanRead)

{

Console.WriteLine(oOldObjectProperty.Name + " = " + oOldObjectValue.ToString());

}

using System.Reflection;

for(int i = 0; i < oOldObject.GetType().GetProperties().Length; i ++)

{

//根據索引提取個别屬性

PropertyInfo oOldObjectProperty = (PropertyInfo) oOldObject.GetType().GetProperties().GetValue(i);

//得到該屬性的資料

Object oOldObjectValue = oOldObjectProperty.GetValue(oOldObject, null);

if (oOldObjectProperty.CanRead)

{

Console.WriteLine(oOldObjectProperty.Name + " = " + oOldObjectValue.ToString());

}

如此便能列出物件中的所有屬性，用同樣的方法應該就能輕松複制/比較兩個物件了:

view plaincopy to clipboardprint?

using System.Reflection;

public MyObject Copy()

{

MyObject oNewObject = new MyObject();

for(int i = 0; i < this.GetType().GetProperties().Length; i ++)

{

PropertyInfo oOldObjectProperty = (PropertyInfo) this.GetType().GetProperties().GetValue(i);

Object oOldObjectValue = oOldObjectProperty.GetValue(this, null);

PropertyInfo oNewObjectProperty = (PropertyInfo) oNewObject.GetType().GetProperties().GetValue(i);

if (oOldObjectProperty.CanRead)

{

//設定oNewObject的目前屬性的值為oOldObjectValue(資料類型必須(必定)一緻)

oNewObjectProperty.SetValue(oNewObject, oOldObjectValue, null);

}

return oNewObject;

}

public bool Compare(MyObject oNewObject)

{

bool bResult = true;

for(int i = 0; i < this.GetType().GetProperties().Length; i ++)

{

PropertyInfo oOldObjectProperty = (PropertyInfo) this.GetType().GetProperties().GetValue(i);

Object oOldObjectValue = oOldObjectProperty.GetValue(this, null);

PropertyInfo oNewObjectProperty = (PropertyInfo) oNewObject.GetType().GetProperties().GetValue(i);

Object oNewObjectValue = oNewObjectProperty.GetValue(oNewObject, null);

//防止屬性是NULL

if (oOldObjectValue != null && oNewObjectValue != null)

{

switch(oOldObjectProperty.PropertyType.ToString())

{

case "System.Double":

//Double 會有機會變成如2.49999999...的無限小數, 變成String才準确

bResult = (((double)oOldObjectValue).ToString("0.000000") == ((double)oNewObjectValue).ToString("0.000000"));

break;

case "System.DateTime":

//量度到秒就夠了

bResult = (((DateTime)oOldObjectValue).ToString("yyyy/MM/dd HH:mm:ss") == ((DateTime)oNewObjectValue).ToString("yyyy/MM/dd HH:mm:ss"));

break;

case "System.Boolean":

bResult = (((bool)oOldObjectValue) == ((bool)oNewObjectValue));

break;

default:

bResult = (oOldObjectValue.ToString() == oNewObjectValue.ToString());

break;

}

else

{

//驗證個别屬性是NULL

if (!(oOldObjectValue == null && oOldObjectValue == null))

{

bResult = false;

}

//如發現有不同就不用再比對了

if (!bResult)

{

break;

}

return bResult;

}

posted @ 2011-06-28 09:20 李sir 閱讀(58) 評論(0) 編輯

NameValueCollection詳解

1.NameValueCollection類集合是基于 NameObjectCollectionBase 類。

但與 NameObjectCollectionBase 不同，該類在一個鍵下存儲多個字元串值（就是鍵相同，值就連接配接起來如下例子）。該類可用于标頭、查詢字元串和窗體資料。

每個元素都是一個鍵/值對。NameValueCollection 的容量是 NameValueCollection 可以儲存的元素數。

NameValueCollection 的預設初始容量為零。随着向 NameValueCollection 中添加元素，容量通過重新配置設定按需自動增加。

如下例子：

NameValueCollection myCol = new NameValueCollection();

myCol.Add("red", "rojo");//如果鍵值red相同結果合并 rojo,rouge

myCol.Add("green", "verde");

myCol.Add("blue", "azul");

myCol.Add("red", "rouge");

2.NameValueCollection與Hashtable的差別

a.引用差別

hashtable:using System.Collections;

NameValueCollection:using System.Collections.Specialized;

b.鍵是否重複

NameValueCollection:允許重複.

HashTable是鍵-值集合,但鍵不能出現重複.

Hashtable ht = new Hashtable();

ht.Add("key","value");

ht.Add("key", "value1"); //出錯

ht["key"] = "value1"; //正确

3.初始化NameValueCollection

初始化NameValueCollection需引用using System.Collections.Specialized;

完整例子源碼：

using System; using System.Collections;

using System.Collections.Specialized;

namespace SamplesNameValueCollection

{

class Program

{

public static void Main()

{

//初始化NameValueCollection需引用using System.Collections.Specialized;

NameValueCollection myCol = new NameValueCollection();

myCol.Add("red", "rojo");//如果鍵值red相同結果合并 rojo,rouge

myCol.Add("green", "verde");

myCol.Add("blue", "azul");

myCol.Add("red", "rouge");

// Displays the values in the NameValueCollection in two different ways.

//顯示鍵，值

Console.WriteLine("Displays the elements using the AllKeys property and the Item (indexer) property:");

PrintKeysAndValues(myCol);

Console.WriteLine("Displays the elements using GetKey and Get:");

PrintKeysAndValues2(myCol);

// Gets a value either by index or by key.

//按索引或值擷取

Console.WriteLine("Index 1 contains the value {0}.", myCol[1]);//索引1的值

Console.WriteLine("Key \"red\" has the value {0}.", myCol["red"]);//鍵為red的對應值rouge

Console.WriteLine();

// Copies the values to a string array and displays the string array.

String[] myStrArr = new String[myCol.Count];

myCol.CopyTo(myStrArr, 0);

Console.WriteLine("The string array contains:");

foreach (String s in myStrArr)

Console.WriteLine(" {0}", s);

Console.WriteLine();

//查找green鍵值然後删除

myCol.Remove("green");

Console.WriteLine("The collection contains the following elements after removing \"green\":");

PrintKeysAndValues(myCol);

//清空集合

myCol.Clear();

Console.WriteLine("The collection contains the following elements after it is cleared:");

PrintKeysAndValues(myCol);

}

//顯示鍵，值

public static void PrintKeysAndValues(NameValueCollection myCol)

{

IEnumerator myEnumerator = myCol.GetEnumerator();

Console.WriteLine(" KEY VALUE");

foreach (String s in myCol.AllKeys)

Console.WriteLine(" {0,-10} {1}", s, myCol[s]);

Console.WriteLine();

}

//顯示索引, 鍵,值

public static void PrintKeysAndValues2(NameValueCollection myCol)

{

Console.WriteLine(" [INDEX] KEY VALUE");

for (int i = 0; i < myCol.Count; i++)

Console.WriteLine(" [{0}] {1,-10} {2}", i, myCol.GetKey(i), myCol.Get(i));

Console.WriteLine();

}

4.NameValueCollection周遊

與Hashtable相似:

NameValueCollection myCol = new NameValueCollection();

myCol.Add("red", "rojo");//如果鍵值red相同結果合并 rojo,rouge

myCol.Add("green", "verde");

myCol.Add("blue", "azul");

myCol["red"] = "dd";

foreach (string key in myCol.Keys)

{

Console.WriteLine("{0}:{1}", key, myCol[key]);

}

Console.ReadLine();