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