• <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>

            記錄自己的程序人生和感悟,記錄自己成長的點(diǎn)點(diǎn)滴滴

            目前興趣,游戲開發(fā)。

             

            大規(guī)模多人在線系統(tǒng)的思考

            目前的互聯(lián)網(wǎng)應(yīng)用,一個(gè)突出的焦點(diǎn)就是用戶量非常大,給服務(wù)器開發(fā)和設(shè)計(jì)帶來了許多挑戰(zhàn),這里想談本人對這些問題的思考和體會(huì).
            大規(guī)模的多人在線系統(tǒng),我接觸的比較多的,有一下幾種:
            1. p2p 系統(tǒng),p2p直播軟件,在播放比較熱點(diǎn)的節(jié)目時(shí),會(huì)遇到數(shù)十萬甚至上百萬人同時(shí)觀看的問題,由于p2p的特殊性質(zhì),一般不會(huì)去統(tǒng)一保持用戶信息,
            服務(wù)器需要的只是給p2p客戶提供節(jié)目源, 以及為p2p 客戶查找其他p2p節(jié)點(diǎn)提供tracker服務(wù)。所以p2p在對付大規(guī)模的人數(shù)在線時(shí),只要簡單的添加tracker
            和界目源即可。這種多人在線是在軟件設(shè)計(jì)時(shí)需要考慮的最少的一種。
            2. 網(wǎng)游服務(wù)器系統(tǒng)。 網(wǎng)游服務(wù)器對付這種問題的方法是, 把整個(gè)用戶空間隔離為n個(gè)世界, 譬如mmo中的某區(qū)某服, 或者休閑游戲中的房間。
            當(dāng)用戶量不斷增加時(shí),只需不斷的增加服務(wù)器組和房間服務(wù)器即可。 唯一麻煩的地方,就是在于一個(gè)用戶的統(tǒng)一認(rèn)證和經(jīng)濟(jì)系統(tǒng)這塊。由于這兩塊負(fù)載不大,
            邏輯也相對簡單,實(shí)現(xiàn)起來難度不太大。
            3. IM 系統(tǒng), im系統(tǒng)的問題就在于,他的整個(gè)用戶空間,是完全統(tǒng)一在一起的,沒法采用區(qū)服,房間的方式來隔離。 當(dāng)im服務(wù)器的在線人數(shù)突破10,20萬之后,
            設(shè)計(jì)一套集群系統(tǒng)就是勢在必行的了。這個(gè)時(shí)候單臺邏輯服務(wù)器,單臺數(shù)據(jù)庫已經(jīng)無法滿足系統(tǒng)的性能要求了。 必須采用把數(shù)據(jù),服務(wù),分散在各個(gè)物理服務(wù)器內(nèi),
            采用集群的方式來進(jìn)行管理。
            當(dāng)并發(fā)人數(shù)在100萬以下時(shí),我設(shè)計(jì)的一種做法是, 后臺的db部分,采用一臺或者幾臺類似mysql proxy的服務(wù)器來統(tǒng)一進(jìn)行訪問。
            db 內(nèi)的數(shù)據(jù)采用按照數(shù)字賬號分段,或者按照某種hash 算法進(jìn)行 分塊的存儲(chǔ)。 前臺的邏輯服務(wù)器,不直接和db 打交道。而是通過DB Proxy來訪問數(shù)據(jù)庫,
            這樣可以保證數(shù)據(jù)庫的存儲(chǔ)策略不透明,可以于前臺的邏輯部分進(jìn)行獨(dú)立的變化,前臺邏輯服務(wù)器,連數(shù)據(jù)庫的表結(jié)構(gòu)都不需要知道,只需要發(fā)送請求,去DB Proxy請求指定條件的查詢和結(jié)果集就可以了。 而邏輯服務(wù)器之間,當(dāng)100萬人以下同時(shí)在線時(shí),邏輯服務(wù)器的數(shù)目并不會(huì)太多。這些邏輯服務(wù)器之間可以直接互聯(lián)。每個(gè)邏輯服務(wù)器負(fù)責(zé)一段數(shù)字賬號的邏輯處理,每個(gè)邏輯服務(wù)器向其他服務(wù)器通報(bào)自己負(fù)責(zé)的數(shù)字段范圍。當(dāng)遇到不是本服務(wù)器能處理的請求時(shí),譬如給其他邏輯服務(wù)器上的用戶發(fā)送文本消息時(shí), 直接轉(zhuǎn)發(fā)給其他邏輯服務(wù)器即可。
            DB Proxy 在db server前端,單臺DB Proxy的處理能力畢竟有限,這里可能還要考慮每幾臺DB服務(wù)器就配置一臺DB Proxy。每幾臺前臺邏輯服務(wù)器共享一臺DB Proxy.  im 系統(tǒng)的數(shù)據(jù)庫訪問非常頻繁,在im系統(tǒng)中實(shí)現(xiàn)數(shù)據(jù)庫cache,對于性能的提高是非常有幫助的。前臺邏輯服務(wù)器,也應(yīng)該盡量的cache數(shù)據(jù),減少訪問DB
            Proxy的次數(shù),以提高系統(tǒng)的整體性能。
             
            這里為了把客戶端指引到連接指定的邏輯服務(wù)器,前臺需要有Dispatch 服務(wù)器,提供邏輯服務(wù)器的地址,端口。im 客戶端連接邏輯服務(wù)器前必須查詢Dispatch Server,來獲知邏輯服務(wù)器地址。 為了增強(qiáng)靈活性,可以設(shè)置一臺中心服務(wù)器,。來動(dòng)態(tài)的提供邏輯服務(wù)器,DB Proxy等的配置信息。以及方便進(jìn)行服務(wù)器組的后臺管理。
            這里的設(shè)計(jì)是針對udp 的im 系統(tǒng)來的。tcp 的im系統(tǒng),成本偏高,研究的較少。
            實(shí)際的應(yīng)用中,還需要一些性能測試數(shù)據(jù)的配合和運(yùn)營數(shù)據(jù),才能得出比較優(yōu)化了的架構(gòu)。 
             

            posted on 2008-06-14 10:07 Hellfire 閱讀(2995) 評論(6)  編輯 收藏 引用

            評論

            # re: 大規(guī)模多人在線系統(tǒng)的思考 2008-06-14 10:29

            QQ游戲的服務(wù)器好像也是采用幾層設(shè)計(jì)的,如登錄服務(wù)器,游戲服務(wù)器。
            他們所有的服務(wù)都是用同一套數(shù)據(jù)庫,不知道數(shù)據(jù)庫的服務(wù)器是如何架構(gòu)的。  回復(fù)  更多評論   

            # re: 大規(guī)模多人在線系統(tǒng)的思考 2008-06-14 10:43 Hellfire

            @水
            這個(gè)我也想知道,有一個(gè)辦法,可以采用一個(gè)統(tǒng)一的數(shù)據(jù)庫訪問平臺。
            對所有的系統(tǒng)開放接口,然后每個(gè)系統(tǒng)保存自己相關(guān)的數(shù)據(jù),平臺保存公共數(shù)據(jù)。

            這個(gè)只是我的猜測,不知道騰訊是不是有更好的辦法、  回復(fù)  更多評論   

            # re: 大規(guī)模多人在線系統(tǒng)的思考 2008-06-14 11:03 true

            系統(tǒng)的架構(gòu)按支撐的業(yè)務(wù)來劃分,還是比較穩(wěn)定的,大同小異,關(guān)鍵是怎么實(shí)現(xiàn),而且是高校的實(shí)現(xiàn)。我覺得  回復(fù)  更多評論   

            # re: 大規(guī)模多人在線系統(tǒng)的思考 2008-06-14 11:10 Hellfire

            @true
            高效的實(shí)現(xiàn),是后期的細(xì)節(jié)工作,前期的努力,不應(yīng)該在高效,而在于把功能實(shí)現(xiàn),優(yōu)化是需要時(shí)間的。  回復(fù)  更多評論   

            # re: 大規(guī)模多人在線系統(tǒng)的思考 2008-06-14 18:22 Kven

            看了大大的2篇文章,小弟覺得大大對Server的研究很深。
            其實(shí)我有想在家用幾臺二手舊電腦(就是那些網(wǎng)吧不要的那些),
            組合一個(gè)MMO游戲服務(wù)器(朋友和朋友之間的)。
            大大你覺得我的想法行嗎?(我怕買了回來什么都弄不到,心痛)  回復(fù)  更多評論   

            # re: 大規(guī)模多人在線系統(tǒng)的思考 2008-06-18 14:07 阿福

            謝謝!
            看起來好像是大家都懂得的道理,第一次有人清晰的說出來,還是覺得受益匪淺。  回復(fù)  更多評論   


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            留言簿(4)

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            国内精品综合久久久40p| 久久精品国产精品亚洲人人| 超级97碰碰碰碰久久久久最新| 久久99精品九九九久久婷婷| 午夜精品久久久久久| 亚洲国产视频久久| jizzjizz国产精品久久| 久久久久亚洲AV无码专区桃色 | 婷婷久久久亚洲欧洲日产国码AV| 亚洲国产精品高清久久久| 久久亚洲私人国产精品| 色偷偷888欧美精品久久久| 精品久久久久久久久久中文字幕| 少妇熟女久久综合网色欲| 久久精品国产亚洲av高清漫画 | 久久国产成人午夜AV影院| 久久精品aⅴ无码中文字字幕不卡 久久精品成人欧美大片 | 日本欧美国产精品第一页久久| 亚洲va久久久噜噜噜久久天堂| 久久综合丁香激情久久| 亚洲欧美伊人久久综合一区二区| 中文字幕亚洲综合久久2| 久久人人爽人人爽人人片AV不| 久久香蕉一级毛片| 99久久夜色精品国产网站| 久久国产精品波多野结衣AV| 久久精品国产亚洲av水果派| 久久久久波多野结衣高潮| 久久精品二区| 久久久黄片| 久久99精品久久久久久不卡 | 国产精品久久久99| 99久久99久久精品免费看蜜桃| 一级做a爰片久久毛片看看| 久久九九有精品国产23百花影院| 久久久久亚洲AV无码麻豆| 久久婷婷五月综合97色直播| 免费精品久久久久久中文字幕| 久久久久亚洲爆乳少妇无| 精品久久久久国产免费| 久久久久国产精品麻豆AR影院 |