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