讓無數中國玩家為之矚目的“魔獸世界”，隨著一系列內測前期工作的逐步展開，正在一步步地走近中國玩家，但是，“魔獸”的伺服器，卻著實讓我們為它捏了一把汗。搭建網遊伺服器的選擇一直多是一項艱鉅而富有挑戰的專案。

造成一個網遊伺服器當機的原因有很多，但主要有以下兩種：一，伺服器線上人數達到上限，伺服器處理效率嚴重遲緩，造成當機;二，由於外掛或其它遊戲作弊 工具導致的非正常資料包的出錯，導致遊戲伺服器邏輯出現混亂，從而造成當機。在這裡，我主要想說說後者如何儘可能地避免。

要避免以上 所說到的第二種情況，我們就應該遵循一個基本原則：在網遊伺服器的設計中，對於具有較強邏輯關係的處理單元，伺服器端和客戶端應該採用“互不信任原則”， 即：伺服器端即使收到了客戶端的資料包，也並不是立刻就認為客戶端已經達到了某種功能或者狀態，客戶端到達是否達到了某種功能或者狀態，還必須依靠伺服器 端上記載的該客戶端“以往狀態”來判定。

也就是說：伺服器端的邏輯執行並不單純地以“當前”的這一個客戶端封包來進行，它還應該廣泛參考當前封包的上下文 環境，對執行的邏輯作出更進一步地判定，同時，在單個封包的處理上，伺服器端應該廣泛考慮當前客戶端封包所需要的“前置”封包，如果沒有收到該客戶端應該 發過來的“前置”封包，則當前的封包應該不進行處理或進行異常處理(如果想要效能高，則可以直接忽略該封包;如果想讓伺服器穩定，可以進行不同的異常處 理)。

之所以採用“互不信任”原則設計網遊伺服器，一個很重要的考慮是：防外掛。對於一個網路伺服器(不僅僅是遊戲伺服器，泛指所有 伺服器)而言，它所面對的物件既有屬於自己系統內的合法的網路客戶端，也有不屬於自己系統內的非法客戶端訪問。所以，我們在考慮伺服器向外開放的介面時， 就要同時考慮這兩種情況：合法客戶端訪問時的邏輯走向以及非法客戶端訪問時的邏輯走向。

即：你伺服器端不要我客戶端發什麼你就信什麼，你還得進行一系列的邏輯驗證，以判定我當 前執行的操作是不是合法的。這樣，伺服器端可以透過以下邏輯執行驗證功能：只有當客戶端的使用者名稱和密碼透過驗證後，該客戶端才會進入線上玩家列表 中。而只有在線玩家列表中的成員，才可以在登陸伺服器的引導下進入各分組伺服器。

當然，安全性和效率總是相互對立的。為了實現我們所說的“互不信任”原則，難免的，就會在遊戲邏輯中加入很多的異常檢測機制，但異常檢測又是比較耗時 的，這就需要我們在效率和安全性方面作個取捨，對於特別重要的邏輯，我們應該全面貫徹“互不信任”原則，一步扣一步，步步為營，不讓遊戲邏輯出現一點漏 洞。而對於並非十分重要的場合，則完全可以採用“半信任”或者根本“不須信任”的原則進行設計，以儘可能地提高伺服器效率。

1、伺服器CPU的挑選

網頁遊戲伺服器每天接受至少幾百、至多上千萬的訪問量，對CPU的快速吞吐量、穩定性、長時間執行都有著嚴格的要求，因而伺服器CPU是衡量伺服器效能的首要指標。目前市面上對網頁遊戲伺服器CPU已經達到八核16執行緒，CPU已經不再是網頁遊戲伺服器選型的瓶頸所在。客戶需求 :需要高速計算，低配機器無法承載解決方案 :高配物理伺服器，使用者獨享硬體資源

2、磁碟I/O能力

針對於網頁遊戲邏輯伺服器以及GameDB的小資料塊對磁碟隨機I/O能力有著較高的要求，是遊戲架構與設計中需要重點考慮的環節。網頁遊戲伺服器商通常會選擇隨時讀寫速率高、故障率低的SATA、SAS硬碟作為伺服器的標準配置。值得注意的是：傳統高速SAS硬碟在面對大量小圖片元素時，磁碟I/O還是吃力，但SSD固態硬碟技術可以有效解決此類問題。壹互聯資料香港網遊伺服器租用都是採用SATA硬碟，讀寫速度高且穩定。

3、機房頻寬以及伺服器頻寬

網頁遊戲有著一定的時間性，需要儲存足夠大的頻寬來應對突發傳輸速率，在遊戲玩家訪問的高峰期保證玩家的使用者的使用者體驗。在機房頻寬直接連線國家骨幹網的訪問速度國內高防伺服器會更快。

4、Ping值，線路穩定

對於遊戲玩家來說，伺服器對請求的響應和流暢度至關重要。如果延遲過長，就會影響使用者體驗度。香港機房透過海底光纜直連中國網路,採用CN2作為主要傳輸路線，並針對中國大陸網路進行全面最佳化，中國大陸各個地區訪問延遲平均在180ms。客戶需求 :需要較好的網路，線路不擁堵不掉線解決方案 :11線BGP，智慧調優，ping值穩定。

5、接入支援及接入安全

客戶需求 :海量節點全覆蓋，保證玩家不流失解決方案 :亞太CDN線路最佳化全球玩家接入;客戶需求 :服務端對攻擊敏感，保證遊戲不停服解決方案 :高防ip+流量遷移清洗保證安全無憂。

總之，在從事網遊伺服器的選擇過程中，要始終不移地 堅持一個信念：我們的伺服器，不僅僅有自己的遊戲客戶端在訪問，還有其它很多他人寫的遊戲客戶端在訪問，所以，我們應該確保我們的伺服器是足夠強壯的，任 它風吹雨打也不怕，更不會倒。如果在租用香港網遊伺服器中，沒有很好地領會這一點，那麼，你的網遊伺服器將是無比脆弱的。

可以簡單的理解為宕機.伺服器是硬體裝置.而且是全年二十四小時不間斷執行的.通常負載量也較大.所以時間一長就容易出現宕機的情況.只要不是太頻繁.就是完全正常的.一般常用伺服器的人都知道.每隔一段時間定期手動重啟下機器.對機器的效能有很大幫助.而且可以避免宕機的情況.畢竟伺服器也是硬體.長期執行中間也應該有個喘氣的過程. 作者：葵芳IDC

1、伺服器環境的客觀原因。比如機房斷電導致的伺服器斷電、機房溫度過高，導致的伺服器宕機、關機等。不過這種情況般很少發生，因為像景安雲機房等資料中心，通常都有很好預防措施，比如備用電路、備用發電機、全時段機械及自然製冷、只能恆溫系統等。

2、伺服器不堪負重。這種情況是比較常見的主要原因，網站流量暴增、程式中毒、遭受攻擊等大規模高消耗伺服器資源情況，而導致的伺服器資源耗盡不敢負重，終無法響應和宕機。

3、就是不合理的應用了。比如種很常見的現象就是，由於考慮成本，些站長常會租用較低配置的VPS、雲伺服器等，用來建設網站，但又同時安裝諸多與網站建設毫無相關的其他大型軟體，讓伺服器以小轎車之能，擔負大貨車的負載，結果可想而知，宕機宕機屬常事才是應該。

總之，宕機的常見原因也還有很多細節原因，比如，錯誤的環境配置、陷於死迴圈的錯誤程式、資料庫索引缺失、資料庫丟失等都會無端消耗大量伺服器CPU、記憶體等資源，從而導致的伺服器宕機宕機等。不過，基本大多數宕機的原因都不出以上三種常見原因範疇。出現這種情況，可聯絡自己的IDC服務商。

作為一個穩定的系統是不會崩潰的，這輩子都不會，要不怎麼能叫穩定呢。那為什麼實踐中我們確實會遇到訪問量過大而伺服器趴窩呢？因為實際情況比較複雜。

第一個是記憶體的問題。服務每個請求都是要吃記憶體的，請求越多記憶體用量越大，但記憶體畢竟是有限的，可能是物理記憶體確實用光了，也可能是OS或者中間層的限制。但不管怎樣，一旦發生後果嚴重。daemon大機率會被os殺死，或者內部出現了問題導致完全失去響應。伺服器就趴窩了。

第二個是設計上的侷限。有些東西設計上就不是為大負載高併發來做的。比如早年的mysql/myisam。速度快不快？飛快。但一定資料庫大到一定程度，效能就會直線下降。雖然在這個階段還只是反應慢，伺服器沒有趴窩，但這種慢並非是線性增長的，而是近似於指數那這樣增長方式。比如100個請求的時候每個請求1秒，200個請求的時候每個1.5秒，300個請求的時候每個5秒，到了1000個的時候就每個一個小時了。就像高速公路，車少的時候大家都能跑到法定速度。車一旦增多就會堵車。更嚴重的是即使堵車之後即使進入的車流沒有繼續增加，因為出高速的車流越來越慢，堵車也會越來越嚴重，最後堵到所有人都堵死。到這個程度就可以認為是事實上的趴窩了，因為幾乎所有人的請求都會因為超時而掛掉。

第三個是設計上的缺陷其實說第二個問題的時候已經提到這個問題了，雖然擁堵本身是等一等就能消解，但一旦系統負荷增大到遠超預期，那就不一定會發生什麼事。比如大量的擁堵導致緩衝區爆了，導致了一連串連鎖反應，比如前面提過的記憶體也爆了，進而引發一些不可逆的後果，最後導致伺服器宕機。

現實生活中，情況可能會更復雜，宕機可能是多重作用的結果。比如一個系統有4個節點做負載分散，哪怕4個死了3個也不會完全宕機。結果一波高峰導致其中兩個節點暫時負荷變高，反映變慢。然後導致接下來短時間所有的流量都被匯入剩下的兩個節點，把剩下兩個節點搞到完全不動了。這個時候雖然前兩個反應過來了，但面對海量的求情也很快就趴窩了。畢竟是是需要四個人才能搞定的活，現在兩個兄弟趴了，剩下兩個孤軍奮戰趴也是遲早的事。這樣伺服器就全趴了。

第一就是作業系統，超負荷了。

第二就是機房散熱不好，伺服器啊，這個環境受到嚴重的考驗。

第三就是機器硬體問題，硬碟了，風扇了，電源了等等。