• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆-379  評論-37  文章-0  trackbacks-0
            在網絡應用中,“負載均衡”已經不能算是什么新鮮話題了,從硬件到軟件,也都有了很多的方法來實現負載均衡。我們這里討論的負載均衡,并不是指依靠DNS轉向或其它硬件設備等所作的負載均衡,而是指在應用層所作的負載均衡。
              一般而言,只有在大型在線系統當中才有必要引入負載均衡,那么,多大的系統才能被稱為大型系統呢?比如動輒同時在線數十萬的網絡游戲,比如同時在線數在10萬以上的WEB應用,這些我們都可以理解為大型系統,這本身就是一個寬泛的概念。
             
             設計再好的服務器程序,其單個程序所能承載的同時訪問量也是有限的,面對一個龐大且日益增長的網絡用戶群,如何讓我們的架構能適應未來海量用戶訪問,這
            自然就牽涉到了負載均衡問題。支持百萬級以上的大型在線系統,它的架構核心就是如何將“百萬”這么大的一個同時在線量分攤到每個單獨的服務器程序上去。真
            正的邏輯處理應該是在這最終的底層的服務器程序(如QQ游戲平臺的游戲房間服務器)上的,而在此之前所存在的那些服務器,都可以被稱為“引路者”,它們的
            作用就是將客戶端一步步引導到這最終的負責真正邏輯的底層服務器上去,我們計算“百萬級在線”所需要的服務器數量,也是首先考慮這底層的邏輯服務器單個可
            承載的客戶端連接量。
              比如:按上篇我們所分析QQ游戲架構而言,假設每個服務器程序最高支持2W的用戶在線(假設一臺機子只運行一個
            服務器程序),那么實現150萬的在線量至少需要多少臺服務器呢?如果算得簡單一點的話,就應該是:150/2=75臺。當然,這樣算起來,可能并不能代
            表真正的服務器數量,因為除了這底層的服務器外,還要包括登錄/賬號服務器以及大廳服務器。但是,由于登錄/賬號服務器和大廳服務器,它們與客戶端的連接
            都屬于短連接(即:取得所需要信息后,客戶端與服務器即斷開連接),所以,客戶端給這兩類服務器帶來的壓力相比于長連接(即:客戶端與服務器始終保持連
            接)而言就要輕得多,它們的壓力主要在處理瞬間的并發訪問上。
              “短連接”,是實現應用層負載均衡的基本手段!!!如果客戶端要始終與登錄/賬號服務器以及大廳服務器保持連接,那么這樣作的分層架構將是無意義的,這也沒有辦法從根本上解決用戶量不斷增長與服務器數量有限之間的矛盾。
             
             當然,短連接之所以可以被使用并能維護正常的游戲邏輯,是因為在玩家看不到的地方,服務器與服務器之間進行了大量的數據同步操作。如果一個玩家沒有登錄
            到登錄服務器上去而是直接連接進了游戲房間服務器并試圖進行游戲,那么,由于游戲房間服務器與大廳服務器和登錄/賬號服務器之間都會有針對于玩家登錄的邏
            輯維護,游戲房間服務器會檢測出來該玩家之前并沒有到登錄服務器進行必要的賬號驗證工作,它便會將玩家踢下線。由此看來,各服務器之間的數據同步,又是實
            現負載均衡的又一必要條件了。
              服務器之間的數據同步問題,依據應用的不同,也會呈現不同的實現方案。比如,我們在處理玩家登錄這個問
            題上。我們首先可以向玩家開放一些默認的登錄服務器(服務器的IP及PORT信息),當玩家連接到當前的登錄服務器后,由該服務器首先判斷自己同時連接的
            玩家是不是超過了自定義的上限,如果是,由向與該服務器連接著的“登錄服務器管理者”(一般是一個內部的服務器,不直接向玩家開放)申請仲裁,由“登錄服
            務器管理者”根據當前各登錄服務器的負載情況選擇一個新的服務器IP和PORT信息傳給客戶端,客戶端收到這個IP和PORT信息之后重定向連接到這個新
            的登錄服務器上去,完成后續的登錄驗證過程。
              這種方案的一個特點是,在面向玩家的一側,會提供一個外部訪問接口,而在服務器集群的內部,會提供一個“服務器管理者”及時記錄各登錄服務器的負載情況以便客戶端需要重定向時根據策略選擇一個新的登錄接口給客戶端。
             
             采用分布式結構的好處是可以有效分攤整個系統的壓力,但是,不足點就是對于全局信息的索引將會變得比較困難,因為每個單獨的底層邏輯服務器上都只是存放
            了自己這一個服務器上的用戶數據,它沒有辦法查找到其它服務器上的用戶數據。解決這個問題,簡單一點的作法,就是在集群內部,由一個中介者,提供一個全局
            的玩家列表。這個全局列表,根據需要,可以直接放在“服務器管理者”上,也可以存放在數據庫中。
              對于邏輯相對獨立的應用,全局列表的
            使用機會其實并不多,最主要的作用就是用來檢測玩家是不是重復登錄了。但如果有其它的某些應用,要使用這樣的全局列表,就會使數據同步顯得比較復雜。比
            如,我們在超大無縫地圖的MMORPG里,如果允許跨服操作(如跨服戰斗、跨服交易等)的話,這時的數據同步將會變得異常復雜,也容易使處理邏輯出現不可
            預測性。
              我認為,對于休閑平臺而言,QQ游戲的架構已經是比較合理的,也可以稱之為休閑平臺的標準架構了。那么,MMORPG一般的架構是什么樣的呢?
             
             MMORPG一般是把整個游戲分成若干個游戲世界組,每個組內其實就是一個單獨的游戲世界。而不同的組之間,其數據皆是相互獨立的,并不象QQ休閑平臺
            一樣所有的用戶都會有一個集中的數據存放點,MMORPG的游戲數據是按服務器組的不同而各自存放的。玩家在登錄QQ游戲時,QQ游戲相關的服務器會自動
            為玩家的登錄進行負載均衡,選擇相對不忙的服務器為其執行用戶驗證并最終讓用戶選擇進入哪一個游戲房間。但是,玩家在登錄MMORPG時,卻沒有這樣的自
            動負載均衡,一般是由玩家人為地去選擇要進入哪一個服務器組,之所以這樣,是因為各服務器組之間的數據是不相通的。其實,細致想來,MMORPG的服務器
            架構思想與休閑平臺的架構思想有異曲同工之妙,MMORPG的思想是:可以為玩家無限地開獨立的游戲世界(即服務器組),以滿足大型玩家在線;而休閑平臺
            的思想則是:可以為玩家無限地開游戲房間以滿足大量玩家在線。這兩種應用,可以無限開的都是“具有完整游戲性的游戲世界”,對于MMORPG而言,它的一
            個完整的游戲地圖就是一個整體的“游戲世界”,而對于休閑平臺,它的一個游戲房間就可以描述為一個“游戲世界”。如果MMORPG作成了休閑平臺那樣的全
            服皆通,也不是不可以,但隨之而來的,就是要解決眾多跨服問題,比如:好友、組隊、幫派等等的問題,所有在傳統MMORPG里所定義的這些玩家組織形式的
            規則可能都會因為“全服皆通”而改變。
              架構的選擇是多樣性的,確實沒有一種可以稱得上是最好的所謂的架構,適合于當前項目的,不一定就適合于另一個項目。針對于特定的應用,會靈活選用不同的架構。但有一點,是可以說的:不管你如何架構,你所要作的就是--要以盡可能簡單的方案實現盡可能的穩定、高效!
            posted on 2009-01-02 02:19 小王 閱讀(792) 評論(1)  編輯 收藏 引用 所屬分類: 游戲服務器端開發

            評論:
            # re: 負載均衡--大型在線系統實現的關鍵(下篇)[未登錄] 2009-03-05 09:31 | robin
            分析得真好,頂  回復  更多評論
              
            久久精品免费大片国产大片| 亚洲国产天堂久久综合网站| 国产精品18久久久久久vr| 久久久精品人妻无码专区不卡| 久久综合亚洲欧美成人| 久久久一本精品99久久精品88| 精品久久国产一区二区三区香蕉 | 一本大道久久东京热无码AV| 97久久久久人妻精品专区| 欧美亚洲色综久久精品国产| 99精品国产综合久久久久五月天| 午夜福利91久久福利| 中文国产成人精品久久亚洲精品AⅤ无码精品| 免费国产99久久久香蕉| 人人狠狠综合久久亚洲88| 好久久免费视频高清| 日本久久久精品中文字幕| 亚洲午夜精品久久久久久人妖| 91精品免费久久久久久久久| 久久精品国产第一区二区| 欧美亚洲日本久久精品| 狠狠综合久久AV一区二区三区| 亚洲午夜久久久影院| 97久久精品国产精品青草| 久久亚洲国产欧洲精品一| 久久av免费天堂小草播放| 无码人妻少妇久久中文字幕 | 久久久91精品国产一区二区三区| 99精品国产在热久久| 99精品伊人久久久大香线蕉| 久久久久99精品成人片三人毛片| 久久毛片一区二区| 久久人人爽爽爽人久久久| 国产精品成人99久久久久 | 久久久久亚洲精品日久生情 | 国产精品美女久久久| 国产亚洲色婷婷久久99精品91| 亚洲综合久久久| 久久国产免费观看精品| 国产免费久久精品99re丫y| 996久久国产精品线观看|