Posted on 2011-01-19 19:24
點點滴滴 閱讀(1224)
評論(0) 編輯 收藏 引用 所屬分類:
10 服務器
都已經看出來了，這種每切換一次地圖就要重新連接服務器的方式實在是不夠優雅，而且在實際游戲運營中也發現，地圖切換導致的卡號，復制裝備等問題非常多，這里完全就是一個事故多發地段，如何避免這種頻繁的連接操作呢？
最直接的方法就是把那個圖倒轉過來就行了。客戶端只需要連接到中心服上，所有到地圖服務器的數據都由中心服來轉發。很完美的解決方案，不是嗎？
這種結構在實際的部署中也遇到了一些挑戰。對于一般的MMORPG服務器來說，單臺服務器的承載量平均在2000左右，如果你的服務器很不幸地只能帶1000人，沒關系，不少游戲都是如此；如果你的服務器上跑了3000多玩家依然比較流暢，那你可以自豪地告訴你的策劃，多設計些大量消耗服務器資源的玩法吧，比如大型國戰、公會戰爭等。
2000人，似乎我們的策劃朋友們不大愿意接受這個數字。我們將地圖服務器分開來原來也是想將負載分開，以多帶些客戶端，現在要所有的連接都從中心服上轉發，那連接數又遇到單臺服務器的可最大承載量的瓶頸了。
這里有必要再解釋下這個數字。我知道，有人一定會說，才帶2000人，那是你水平不行，我隨便寫個TCP服務器都可帶個五六千連接。問題恰恰在于你是隨便寫的，而MMORPG的服務器是復雜設計的。如果一個演示socket API用的echo服務器就能滿足MMOG服務器的需求，那寫服務器該是件多么愜意的事啊。
但我們所遇到的事實是，服務器收到一個移動包后，要向周圍所有人廣播，而不是echo服務器那樣簡單的回應；服務器在收到一個連接斷開通知時要向很多人通知玩家退出事件，并將該玩家的資料寫入數據庫，而不是echo服務器那樣什么都不需要做；服務器在收到一個物品使用請求包后要做一系列的邏輯判斷以檢查玩家有沒有作弊；服務器上還啟動著很多定時器用來更新游戲世界的各種狀態......
其實這么一比較，我們也看出資源消耗的所在了：服務器上大量的復雜的邏輯處理。再回過頭來看看我們想要實現的結構，我們既想要有一個唯一的入口，使得客戶端不用頻繁改變連接，又希望這個唯一入口的負載不會太大，以致于接受不了多少連接。
仔細看一看這個需求，我們想要的僅僅只是一臺管理連接的服務器，并不打算讓他承擔太多的游戲邏輯。既然如此，那五六千個連接也還有滿足我們的要求。至少在現在來說，一個游戲世界內，也就是一組服務器內同時有五六千個在線的玩家還是件讓人很興奮的事。事實上，在大多數游戲的大部分時間里，這個數字也是很讓人眼紅的。
什么？你說夢幻、魔獸還有史先生的那個什么征途遠不止這么點人了！噢，我說的是大多數，是大多數，不包括那些明星。你知道大陸現在有多少游戲在運營嗎？或許你又該說，我們不該在一開始就把自己的目標定的太低！好吧，我們還是先不談這個。
繼續我們的結構討論。一般來說，我們把這臺負責連接管理的服務器稱為網關服務器，因為內部的數據都要通過這個網關才能出去，不過從這臺服務器提供的功能來看，稱其為反向代理服務器可能更合適。我們也不在這個名字上糾纏了，就按大家通用的叫法，還是稱他為網關服務器吧。
網關之后的結構我們依然可以采用之前描述的方案，只是，似乎并沒有必要為每一個地圖都開一個獨立的監聽端口了。我們可以試著對地圖進行一些劃分，由一個Master Server來管理一些更小的Zone Server，玩家通過網關連接到Master Server上，而實際與地圖有關的邏輯是分派給更小的Zone Server去處理。
最后的結構看起來大概是這樣的：
Zone Server Zone Server
\ /
\ /
Master Server Master Server
/ \ /
/ \ /
Gateway Server \ /
| \ \ /
| \ \ /
| Center Server
|
|
Client