Posted on 2011-01-19 14:32
點點滴滴 閱讀(870)
評論(0) 編輯 收藏 引用 所屬分類:
10 服務器
回想一下我們在玩wow時的操作流程：運行wow.exe進入游戲后，首先就會要求我們輸入用戶名和密碼進行驗證，驗證成功后才會出來游戲世界列表，之后是排隊進入游戲世界，開始游戲...
可以看到跟前面的描述有個很明顯的不同，那就是要先驗證帳號再選擇游戲世界。這種結構也就使得登錄服不是固定配備給個游戲世界，而是全區共有的。
我們可以試著從實際需求的角度來考慮一下這個問題。正如我們之前所描述過的那樣，登錄服在大多數情況下都是比較空閑的，也許我們的一個擁有20個游戲世界的大區僅僅使用10臺或更少的登錄服即可滿足需求。而當在開新區的時候，或許要配備40臺登錄服才能應付那如潮水般涌入的玩家登錄請求。所以，登錄服在設計上應該能滿足這種動態增刪的需求，我們可以在任何時候為大區增加或減少登錄服的部署。
當然，在這里也不會存在要求添加太多登錄服的情況。還是拿開新區的情況來說，即使新增加登錄服滿足了玩家登錄的請求，游戲世界服的承載能力依然有限，玩家一樣只能在排隊系統中等待，或者是進入到游戲世界中導致大家都卡。
另外，當我們在增加或移除登錄服的時候不應該需要對游戲世界服有所改動，也不會要求重啟世界服，當然也不應該要求客戶端有什么更新或者修改，一切都是在背后自動完成。
最后，有關數據持久化的問題也在這里考慮一下。一般來說，使用現有的商業數據庫系統比自己手工技術先進要明智得多。我們需要持久化的數據有玩家的帳號及密碼，玩家創建的角色相關信息，另外還有一些游戲世界全局共有數據也需要持久化。
好了，需求已經提出來了，現在來考慮如何將其實現。
對于負載均衡來說，已有了成熟的解決方案。一般最常用，也最簡單部署的應該是基于DNS的負載均衡系統了，其通過在DNS中為一個域名配置多個IP地址來實現。最新的DNS服務已實現了根據服務器系統狀態來實現的動態負載均衡，也就是實現了真正意義上的負載均衡，這樣也就有效地解決了當某臺登錄服當機后，DNS服務器不能立即做出反應的問題。當然，如果找不到這樣的解決方案，自己從頭打造一個也并不難。而且，通過DNS來實現的負載均衡已經包含了所做的修改對登錄服及客戶端的透明。
而對于數據庫的應用，在這種結構下，登錄服及游戲世界服都會需要連接數據庫。從數據庫服務器的部署上來說，可以將帳號和角色數據都放在一個中心數據庫中，也可分為兩個不同的庫分別來處理，基到從物理上分到兩臺不同的服務器上去也行。
但是對于不同的游戲世界來說，其角色及游戲內數據都是互相獨立的，所以一般情況下也就為每個游戲世界單獨配備一臺數據庫服務器，以減輕數據庫的壓力。所以，整體的服務器結構應該是一個大區有一臺帳號數據庫服務器，所有的登錄服都連接到這里。而每個游戲世界都有自己的游戲數據庫服務器，只允許本游戲世界內的服務器連接。
最后，我們的服務器結構就像這樣：
大區服務器
/ | \
/ | \
登錄服1 登錄服2 世界服1 世界服2
\ | | |
\ | | |
帳號數據庫 DBS DBS
這里既然討論到了大區及帳號數據庫，所以順帶也說一下關于激活大區的概念。wow中一共有八個大區，我們想要進入某個大區游戲之前，必須到官網上激活這個區，這是為什么呢？
一般來說，在各個大區帳號數據庫之上還有一個總的帳號數據庫，我們可以稱它為中心數據庫。比如我們在官網上注冊了一個帳號，這時帳號數據是只保存在中心數據庫上的。而當我們要到一區去創建角色開始游戲的時候，在一區的帳號數據庫中并沒有我們的帳號數據，所以，我們必須先到官網上做一次激活操作。這個激活的過程也就是從中心庫上把我們的帳號數據拷貝到所要到的大區帳號數據庫中。