| |
在歷史工程上修補是件麻煩的事情。
前兩天說起夢幻西游服務(wù)器的優(yōu)化。這幾天我到廣州住下來，打算專門花一周時間搞定這件事。由于以前都是網(wǎng)上聊天，只有坐到一起才能真正理解問題。
目前，夢幻西游，只使用單臺機器，最高配置 8 個 CPU ，配置 8G 內(nèi)存。就算最熱鬧的服務(wù)器，也用不完這些資源（大約只用滿了 3 個 CPU ，一半的內(nèi)存）。核心程序差不多就是 10 年前寫的，從大話西游延續(xù)至今。這兩年一直在享受免費的午餐，隨著硬件配置提升，現(xiàn)在單臺服務(wù)器同時在線容量達到一萬兩千人。觀察服務(wù)器回應(yīng)速度的圖表可以發(fā)現(xiàn)，目前的問題在于，定期會出現(xiàn)反應(yīng)遲鈍的現(xiàn)象。周期性的，服務(wù)器回應(yīng)時間會超過 1000ms 。查得原因在于那個時候，磁盤 IO 非常擁塞。有定期保存玩家數(shù)據(jù)的服務(wù)對 IO 的占用，以及 SA 做的定期備份數(shù)據(jù)的腳本占用了大量的 IO 時間。最終造成了機器負荷過重。
IO 負荷過重最終怎樣影響到游戲服務(wù)的性能，這個暫時不過于深入探討。我這兩天主要是分析以有的系統(tǒng)結(jié)構(gòu)，并想一下改進方案。
其實老的系統(tǒng)并不復(fù)雜，代碼量也相當之小。相關(guān)的服務(wù)代碼僅僅數(shù)千行干凈的 C 代碼而已。一直沒有人動它，因為事關(guān)重大，牽扯著數(shù)百萬用戶的數(shù)據(jù)，以及記費流程。無論設(shè)計是好是壞，實現(xiàn)的性能有無問題，都讓位于穩(wěn)定�！皻v史原因”造成的種種，也只能在閑聊時抱怨一句，如果重新設(shè)計，肯定不會這樣寫了。近兩年，我越發(fā)的對重構(gòu)這件事情顯的興趣漠然，為何不這樣做，為何不那樣? 更多的時候都只是程序員們飯局上的聊資。每個系統(tǒng)一旦編寫完成，就充滿了種種的遺憾。如果它能用，最大的可能就是它就將一直用下去。一切的新想法，留給下一次吧。
對于已經(jīng)穩(wěn)定運行了很多年的陳舊的系統(tǒng)，找到好的方法去改造的意義不大。最重要的是，如何對已有系統(tǒng)影響最小的增加一些東西，提高性能。模塊間清晰的劃分顯得相當重要。服務(wù)的獨立性也是必要的。現(xiàn)在運行的數(shù)據(jù)服務(wù)和記費以及用戶鑒權(quán)服務(wù)居然放在一個服務(wù)程序中恐怕是一個大失誤。它使得我們把數(shù)據(jù)讀寫剝離出來非常困難。
數(shù)據(jù)服務(wù)采用的是一個 C/S 結(jié)構(gòu)。但沒有使用數(shù)據(jù)庫，而是直接使用的本地文件系統(tǒng)。整個設(shè)計算是良好，但數(shù)據(jù)服務(wù)本身的機制卻很糟糕。C 和 S 之間采用共享內(nèi)存交換數(shù)據(jù)，這是為了提高 IPC 性能。C 只有一個，就是游戲主進程，而 S 可以有多個。可以并發(fā)的提供服務(wù)。多個 S 和 C 之間用管道傳輸命令，用共享內(nèi)存交換數(shù)據(jù)。本意是好的，但協(xié)議設(shè)計是有問題的。因為 C 直接操控數(shù)據(jù)區(qū)，而有唯一性，結(jié)果設(shè)計時，把數(shù)據(jù)區(qū)的區(qū)塊管理放在了 C 上，而不是由 S 提供。
舉例來說，如果游戲進程(C) 需要加載一個用戶的數(shù)據(jù)，它自己先尋找數(shù)據(jù)區(qū)中的空位，然后通知 S 把這個用戶的數(shù)據(jù)加載到它指定的數(shù)據(jù)位置。數(shù)據(jù)區(qū)的清理工作同樣是由 C 這邊做的。這使得 S 不能直接在數(shù)據(jù)區(qū)上做 Cache ，如果需要 Cache 暫時不用的數(shù)據(jù)（比如一個玩家離線）就得由 C 自己來做�；蛘哳~外的再做一個 Cache 服務(wù)（這需要多出一倍的內(nèi)存，以及內(nèi)存復(fù)制的操作）當初這么實現(xiàn)恐怕是考慮到有多個 S 同時為一個 C 服務(wù)的需求，但我只能認為是設(shè)計欠佳。
結(jié)果就是，整個數(shù)據(jù)服務(wù)，無論是讀還是寫，都是無 Cache 的。Cache 僅僅依賴 OS 來做。對于當初低一個數(shù)量級的時候，這沒有問題。但在線人數(shù)從千級達到萬級后，問題就顯露出來了。畢竟你為最終需求最更多的定制，越能充分發(fā)揮硬件的性能。
下面記錄一下我已經(jīng)實現(xiàn)好的內(nèi)存 Key/Value 數(shù)據(jù)庫的設(shè)計思路。
要實現(xiàn)前幾天想好的，只保存差異信息的策略（經(jīng)實測，可以減少 90% 的寫 IO 操作），必須先統(tǒng)一數(shù)據(jù)讀寫服務(wù)的位置。不能依賴本地文件系統(tǒng)做數(shù)據(jù)交換。我之前考察過若干內(nèi)存數(shù)據(jù)庫，比如 Redis ，最終決定自己實現(xiàn)一個。因為我已經(jīng)非常了解需求，可以高度定制算法，最大發(fā)揮硬件的能力。代碼量也不會太大。（控制在 500 行 C 代碼之內(nèi)，最后實際寫下來，不過 300 行 C 程序） |
| 【收藏】【打印】【進入論壇】 |
|
|
|
|
| |
|
|
|
