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