|
在寫這東西之前,我有個事情要澄清一下: 本博客的目的,最重要的一點是記錄某志學習的或喜歡的一些東西 以及 記錄或發泄心情的日記 所用。後者大家都明白,前面的那個動機卻給某志帶來許多麻煩. 我要承認的是,在本博客中,極少資料是原創的. 不,應該說,沒有資料是原創的.我現在處於學習技能的階段,除了一些自己寫的代碼以外,我更多的是學習其他人的資料,總結了一下貼上來的，當然,一些非程序的資料更是直接轉載來的. 可惜個人有個壞習慣,若轉的帖子上沒有標明"嚴禁轉載"或"轉載時必須表明作者,網站"該類信息提醒我一下的話,我實在沒有興趣去做額外的說明.但是這樣不好,想了想,直接在博客標籤上進行個全局說明好了,希望之後這種問題不會再麻煩我. 嘛,接下來說明正文. 一般來說,現在網絡遊戲的服務器設計大致分爲以下三大類: 1:單服務器結構 2:多服務器結構. (根據服務器負責功能不同,有按地圖範圍進行劃分的服務器設計,有按功能劃分的服務器設計) 3:分佈式服務器結構. 一:單服務器結構 在比較起先的MMORPG遊戲中,大部分使用的是單服務器結構,一臺服務器容納人數大約爲1500-2000人左右,根據硬件不同和遊戲需要涉及的AI,邏輯等複雜度不同會有少許出入. 但是這種方式慢慢被淘汰了,因爲網絡遊戲用戶對遊戲的品質要求越來越高,用戶羣也越來越大,開發者們不得不犧牲這種開發效率快,邏輯簡單,但容載量小的單服務器結構. 二:多服務器結構 爲了提高同服在線人數,多服務器結構慢慢流行起來,現在大部分遊戲服務器結構也是基於該類結構設計的. 根據策劃需求不同,多服務器結構可以設計爲多種,一般來說,比較主流的功能分佈方式有以下兩中: 按地圖劃分服務器,按功能劃分服務器. 按地圖劃分服務器,結構清晰,實現難度小,效率也相對比較高.但是會有部分資源的浪費(因爲玩家不可能平均分佈在每個地圖上),另外一旦總控服務器(負責地圖服務器間的分配管理的服務器)掛掉的話,會導致所有的地圖服務器無法正常工作,而且由於每個地圖保存一份數據,數據保存方面是相對獨立的,所以數據安全性無法保障,一旦某地圖服務器掛掉,則很大可能會遺失數據. 按地圖劃分服務器的話,一般服務器是分爲以下三部分,世界服務器,地圖服務器,網關服務器. 世界服務器負責世界地圖的管理,它一般負責管理地圖服務器的工作分配,數據轉移通知功能,一些全局性的功能它也負責,包括讀取發佈網絡遊戲配置信息,全地圖聊天公告的發佈等. 地圖服務器各自間是完全獨立的，各自負責該地圖區域內的一切功能,包括怪物AI,該地圖的NPC,怪物,玩家,物品等所有信息,而且各自擁有獨立的數據庫進行記錄.當一個玩家從一個地圖切換到另一個地圖時,地圖數據庫將通知世界數據庫,世界數據庫再通知另一個地圖服務器,進行這倆地圖服務器之間的用戶數據傳輸. 網關數據庫通常是負責玩家登陸的功能,同時也兼責一些世界服務器的調配功能. //----------------------------------------- 按功能劃分服務器的話,則是一種面象服務的設計思想,將遊戲邏輯中某些常用密集型的功能分離開來,單獨做爲一個服務器進行控制操作,例如,怪物AI單獨由一個服務器負責,物品管理單獨由一個服務器負責等等,按照邏輯職能進行服務器分割. 這樣做的好處是,當一個服務器出現問題的時候,是不會影響其他模塊的運行,而且擴充性相對比較優秀簡便. 但是一旦重要的服務器掛掉,如物品服務器掛掉,依舊是一個很災難性的結果.不過,由於劃分出了單獨的服務器,保證了數據的分佈式存放,比起場景劃分服務器來說,多少還是安全了許多.另外,功能劃分服務器還有一個比較大的問題就是,由於各模塊之間有直接或間接聯繫,在服務器進行調試的時候難度會比較大. 三:分佈式結構. 無特殊研究,待補充.僅知道支持遠程對象調用,動態分佈節點吞吐數據確保了服務器受壓平衡,能夠支持關鍵數據的多節點冗餘確保了數據安全性. 服務器的設計考慮應從幾個方面進行: 1:各服務器的吞吐數據平衡性 2:C-S-C的消息響應時間 3:數據的安全可靠性 4:開發測試效率,維護效率 |
