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

            Daly的游戲人生

            基于binlog的游戲數(shù)據(jù)儲存引擎

                最近組內發(fā)表一篇小論文,是關于改進游戲儲存系統(tǒng)的IO性能思路。老大原來早有相同的想法,并且已經(jīng)實現(xiàn)了大部分模塊,后來和老大一同努力,新的儲存引擎終于逐步完善。在外服環(huán)境跑了兩個多月,性能和可靠性得到了明顯的提升。具體的細節(jié)就不方便發(fā)表了,實踐證明,用binlog來做MMORPG的數(shù)據(jù)儲存是行得通的。

            幾個事實:
               1. 磁盤IO的瓶頸在尋道,順序寫性能比隨機寫性能高一個數(shù)量級。

            目前典型硬盤的順序寫入速度大約是60MB/s , 而尋道時間在5~8ms (200/)。可以看到硬盤IO的主要瓶頸在于磁頭尋道,也就是隨機寫。在linux開發(fā)服(非虛擬機,Xeon 3.0G 4/16G內存)上做了一個benchmark

            順序寫50MB: 700ms

            5000個文件,每個10KB(50MB): 12

                    10000次隨機寫,每次1KB(10MB): 21
               2. 游戲數(shù)據(jù)都是K-V數(shù)據(jù),關系查詢需求極少;k-v數(shù)據(jù)的update很頻繁(實測是每玩家每5秒一次修改)
               3. MMORPG單服的玩家同時在線數(shù)量是10K級別, 這個數(shù)量級可以有效估算binlog的規(guī)模,使得方案可行。

                 一般MMORPG系統(tǒng)的存盤策略: 定時存盤。就是過一段時間(比如5分鐘)把在線有修改過的玩家數(shù)據(jù),整個snapshot存下去(mysql也好,文件系統(tǒng)也好)。這樣有兩個主要問題:一到保存點,IO隨機寫暴增,玩家卡機;如果系統(tǒng)down機, 數(shù)據(jù)就會有幾分鐘的回檔。而性能和數(shù)據(jù)可靠性兩則是矛盾的,存盤間隔過小,玩家卡機,過大,故障后數(shù)據(jù)回檔時間長。需知現(xiàn)在的MMORPG,貴價武器價值都成千上萬RMB,數(shù)據(jù)可靠性對游戲營運影響還是很大的。
                so,   可以用定制的binlog來記錄玩家數(shù)據(jù),也就是說,不記錄整個snapshot,而是每個k-v變化時記錄opcode馬上寫入binlog文件, binlog的格式根據(jù)游戲情況可以高度定制,盡量減少空間。由于是順序寫,性能可以非常高。如果down機,可以根據(jù)binlog來恢復,基本上沒有回檔。不過要解決一個問題:binlog增長過大 --> 崩潰恢復時間過程 & binlog文件本身損壞的風險增大 & 磁盤空間用光。因此binlog需要有rotate機制, rotate的時候需要存一次在線玩家數(shù)據(jù)的snapshot, 這樣舊的binlog就可以存到遠處或者丟棄。rotate的過程中需要考慮恢復時玩家數(shù)據(jù)一致性和完備性等等一系列細節(jié)問題,后來一一解決了。
                這是最近做的成就感的事。幾年沒寫blog了,筆記都記在evernote里,最近又想在公開的地方寫點東西,發(fā)個文紀念一下。


            posted on 2012-07-01 18:05 Daly 閱讀(2237) 評論(6)  編輯 收藏 引用 所屬分類: 游戲開發(fā)

            評論

            # re: 基于binlog的游戲數(shù)據(jù)儲存引擎 2012-07-02 09:08 zuhd

            能詳細說下binlog的幾個缺陷嗎?  回復  更多評論   

            # re: 基于binlog的游戲數(shù)據(jù)儲存引擎 2012-07-02 12:39 Daly

            @zuhd

            其實snapshot的保存還是需要的,只是用來binlog可以大大延長存盤間隔。
            主要缺陷是:
            1. 如果熱數(shù)據(jù)很多,并且很頻繁。binlog文件增長非常快, 硬盤很容易吃滿. 對于熱數(shù)據(jù)量大的項目不合適

            2. 要勾住項目里的k-v變化, 對引用型的復雜類型(map或list),有可能會漏掉。如果代碼里的k-v set都是用統(tǒng)一接口,則問題不大。

            3. 要對復雜類型(map或list)的改變定義opcode比較難,要依賴于具體數(shù)據(jù)意義做opcode的定義,不然要整個map給dump下去,太耗了。

            4. 這個binlog系統(tǒng)的opcode由于是高度定制,不同項目間不具有移植性。

            5. 寫log一般是單獨的線程或進程,要注意數(shù)據(jù)一致性等等細節(jié),要詳細驗證。  回復  更多評論   

            # re: 基于binlog的游戲數(shù)據(jù)儲存引擎 2012-07-02 12:43 Daly

            @zuhd

            當數(shù)據(jù)變化寫binlog的順序IO大到一定程度,則系統(tǒng)性能更糟糕(就是diff的數(shù)據(jù)量大于數(shù)據(jù)snapshot本身), 這個做法就不適合。所以要考慮數(shù)據(jù)規(guī)模,數(shù)據(jù)變化頻率等因素。  回復  更多評論   

            # re: 基于binlog的游戲數(shù)據(jù)儲存引擎 2012-07-17 22:12 liutp

            做個存儲服務進程 應該就可以  回復  更多評論   

            # re: 基于binlog的游戲數(shù)據(jù)儲存引擎 2012-08-25 22:03 ZealotYin

            我可不可以這樣理解,你們游戲行業(yè)的數(shù)據(jù)基本都是全基于內存和DB的,你們需要定時給用戶設置一個存檔點(將某個時間的用戶數(shù)據(jù)存盤),傳統(tǒng)的操作是只使用snapshot來實現(xiàn),而你們是使用定期(較長時間)snapshot加binlog的方式.這樣可以減少做snapshot的次數(shù),提高性能.對嗎?
            抱歉,我是非游戲行業(yè)的,所以您的應用場景有點看不懂,但是我專注于存儲.所以以后有機會可以多交流一下。我新浪微博ID:殷偉雄  回復  更多評論   

            # re: 基于binlog的游戲數(shù)據(jù)儲存引擎 2012-12-07 16:41 Daly

            @ZealotYin
            嗯,是這個意思。另外兩次snapshot保存之間如果crash會丟數(shù)據(jù),binlog可以保證恢復。  回復  更多評論   

            久久亚洲中文字幕精品一区四| 成人午夜精品久久久久久久小说| 日产久久强奸免费的看| 久久人妻少妇嫩草AV无码蜜桃| 久久成人国产精品免费软件| 久久精品国产一区二区三区日韩| 国产亚洲成人久久| 国产成人精品综合久久久久 | 久久久久亚洲AV成人网人人软件| 久久久91人妻无码精品蜜桃HD| 狠狠色综合网站久久久久久久高清| 国产日产久久高清欧美一区| 一本色道久久综合| 91精品国产91久久| 久久精品人人做人人爽97| 合区精品久久久中文字幕一区 | 伊人久久大香线焦综合四虎| 亚洲天堂久久久| 亚洲国产二区三区久久| 久久精品国产亚洲AV蜜臀色欲| 精品久久久久久国产免费了| 久久99精品国产一区二区三区| 精品国产99久久久久久麻豆| 无码人妻久久一区二区三区蜜桃| 久久免费国产精品一区二区| av午夜福利一片免费看久久| 久久这里只有精品18| 午夜天堂av天堂久久久| 免费精品久久天干天干| 久久婷婷色香五月综合激情| 亚洲国产精品嫩草影院久久| 欧美久久一区二区三区| 狠狠人妻久久久久久综合| 国产精品伦理久久久久久| 色综合久久综合网观看| MM131亚洲国产美女久久| 国产精品免费福利久久| 精品国产乱码久久久久久1区2区 | 国产精品狼人久久久久影院 | 欧洲成人午夜精品无码区久久| 久久精品人妻中文系列|