最近組內(nèi)發(fā)表一篇小論文，是關(guān)于改進(jìn)游戲儲(chǔ)存系統(tǒng)的IO性能思路。老大原來(lái)早有相同的想法，并且已經(jīng)實(shí)現(xiàn)了大部分模塊，后來(lái)和老大一同努力，新的儲(chǔ)存引擎終于逐步完善。在外服環(huán)境跑了兩個(gè)多月，性能和可靠性得到了明顯的提升。具體的細(xì)節(jié)就不方便發(fā)表了，實(shí)踐證明，用binlog來(lái)做MMORPG的數(shù)據(jù)儲(chǔ)存是行得通的。
幾個(gè)事實(shí)：
1. 磁盤(pán)IO的瓶頸在尋道，順序?qū)懶阅鼙入S機(jī)寫(xiě)性能高一個(gè)數(shù)量級(jí)。
目前典型硬盤(pán)的順序?qū)懭胨俣却蠹s是60MB/s , 而尋道時(shí)間在5~8ms (200次/秒)。可以看到硬盤(pán)IO的主要瓶頸在于磁頭尋道，也就是隨機(jī)寫(xiě)。在linux開(kāi)發(fā)服(非虛擬機(jī)，Xeon 3.0G 4核/16G內(nèi)存)上做了一個(gè)benchmark。
順序?qū)?/span>50MB: 700ms
寫(xiě)5000個(gè)文件，每個(gè)10KB(共50MB): 12秒
10000次隨機(jī)寫(xiě)，每次1KB(共10MB): 21秒
2. 游戲數(shù)據(jù)都是K-V數(shù)據(jù)，關(guān)系查詢需求極少；k-v數(shù)據(jù)的update很頻繁(實(shí)測(cè)是每玩家每5秒一次修改)
3. MMORPG單服的玩家同時(shí)在線數(shù)量是10K級(jí)別, 這個(gè)數(shù)量級(jí)可以有效估算binlog的規(guī)模，使得方案可行。
一般MMORPG系統(tǒng)的存盤(pán)策略: 定時(shí)存盤(pán)。就是過(guò)一段時(shí)間(比如5分鐘）把在線有修改過(guò)的玩家數(shù)據(jù)，整個(gè)snapshot存下去（mysql也好，文件系統(tǒng)也好)。這樣有兩個(gè)主要問(wèn)題：一到保存點(diǎn)，IO隨機(jī)寫(xiě)暴增，玩家卡機(jī)；如果系統(tǒng)down機(jī)， 數(shù)據(jù)就會(huì)有幾分鐘的回檔。而性能和數(shù)據(jù)可靠性兩則是矛盾的，存盤(pán)間隔過(guò)小，玩家卡機(jī)，過(guò)大，故障后數(shù)據(jù)回檔時(shí)間長(zhǎng)。需知現(xiàn)在的MMORPG，貴價(jià)武器價(jià)值都成千上萬(wàn)RMB，數(shù)據(jù)可靠性對(duì)游戲營(yíng)運(yùn)影響還是很大的。
so, 可以用定制的binlog來(lái)記錄玩家數(shù)據(jù)，也就是說(shuō)，不記錄整個(gè)snapshot，而是每個(gè)k-v變化時(shí)記錄opcode馬上寫(xiě)入binlog文件, binlog的格式根據(jù)游戲情況可以高度定制，盡量減少空間。由于是順序?qū)懀阅芸梢苑浅８摺Ｈ绻鹍own機(jī)，可以根據(jù)binlog來(lái)恢復(fù)，基本上沒(méi)有回檔。不過(guò)要解決一個(gè)問(wèn)題：binlog增長(zhǎng)過(guò)大 --> 崩潰恢復(fù)時(shí)間過(guò)程 & binlog文件本身?yè)p壞的風(fēng)險(xiǎn)增大 & 磁盤(pán)空間用光。因此binlog需要有rotate機(jī)制, rotate的時(shí)候需要存一次在線玩家數(shù)據(jù)的snapshot, 這樣舊的binlog就可以存到遠(yuǎn)處或者丟棄。rotate的過(guò)程中需要考慮恢復(fù)時(shí)玩家數(shù)據(jù)一致性和完備性等等一系列細(xì)節(jié)問(wèn)題，后來(lái)一一解決了。
這是最近做的成就感的事。幾年沒(méi)寫(xiě)blog了，筆記都記在evernote里，最近又想在公開(kāi)的地方寫(xiě)點(diǎn)東西，發(fā)個(gè)文紀(jì)念一下。