案例分享：夢(mèng)幻西游服務(wù)器的優(yōu)化
在歷史工程上修補(bǔ)是件麻煩的事情。
前兩天說起夢(mèng)幻西游服務(wù)器的優(yōu)化。這幾天我到廣州住下來，打算專門花一周時(shí)間搞定這件事。由于以前都是網(wǎng)上聊天，只有坐到一起才能真正理解問題。
目前，夢(mèng)幻西游，只使用單臺(tái)機(jī)器，***配置 8 個(gè) CPU ，配置 8G 內(nèi)存。就算最熱鬧的服務(wù)器，也用不完這些資源（大約只用滿了 3 個(gè) CPU ，一半的內(nèi)存）。核心程序差不多就是 10 年前寫的，從大話西游延續(xù)至今。這兩年一直在享受免費(fèi)的午餐，隨著硬件配置提升，現(xiàn)在單臺(tái)服務(wù)器同時(shí)在線容量達(dá)到一萬兩千人。觀察服務(wù)器回應(yīng)速度的圖表可以發(fā)現(xiàn)，目前的問題在于，定期會(huì)出現(xiàn)反應(yīng)遲鈍的現(xiàn)象。周期性的，服務(wù)器回應(yīng)時(shí)間會(huì)超過 1000ms 。查得原因在于那個(gè)時(shí)候，磁盤 IO 非常擁塞。有定期保存玩家數(shù)據(jù)的服務(wù)對(duì) 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)定。“歷史原因”造成的種種，也只能在閑聊時(shí)抱怨一句，如果重新設(shè)計(jì)，肯定不會(huì)這樣寫了。近兩年，我越發(fā)的對(duì)重構(gòu)這件事情顯的興趣漠然，為何不這樣做，為何不那樣? 更多的時(shí)候都只是程序員們飯局上的聊資。每個(gè)系統(tǒng)一旦編寫完成，就充滿了種種的遺憾。如果它能用，***的可能就是它就將一直用下去。一切的新想法，留給下一次吧。
對(duì)于已經(jīng)穩(wěn)定運(yùn)行了很多年的陳舊的系統(tǒng)，找到好的方法去改造的意義不大。最重要的是，如何對(duì)已有系統(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ù)庫(kù)，而是直接使用的本地文件系統(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 來做。對(duì)于當(dāng)初低一個(gè)數(shù)量級(jí)的時(shí)候，這沒有問題。但在線人數(shù)從千級(jí)達(dá)到萬級(jí)后，問題就顯露出來了。畢竟你為最終需求最更多的定制，越能充分發(fā)揮硬件的性能。
下面記錄一下我已經(jīng)實(shí)現(xiàn)好的內(nèi)存 Key/Value 數(shù)據(jù)庫(kù)的設(shè)計(jì)思路。
要實(shí)現(xiàn)前幾天想好的，只保存差異信息的策略（經(jīng)實(shí)測(cè)，可以減少 90% 的寫 IO 操作），必須先統(tǒng)一數(shù)據(jù)讀寫服務(wù)的位置。不能依賴本地文件系統(tǒng)做數(shù)據(jù)交換。我之前考察過若干內(nèi)存數(shù)據(jù)庫(kù)，比如 Redis ，最終決定自己實(shí)現(xiàn)一個(gè)。因?yàn)槲乙呀?jīng)非常了解需求，可以高度定制算法，***發(fā)揮硬件的能力。代碼量也不會(huì)太大。（控制在 500 行 C 代碼之內(nèi)，***實(shí)際寫下來，不過 300 行 C 程序）
我們的需求是這樣的：服務(wù)程序每周會(huì)停機(jī)一次。每周總共涉及的玩家數(shù)據(jù) 10 萬組。每組數(shù)據(jù) 4k 到 32K 之間。都是文本數(shù)據(jù)?？梢钥闯梢粋€(gè) id 到數(shù)據(jù)串的 key/value 數(shù)據(jù)儲(chǔ)存服務(wù)。經(jīng)估算，總數(shù)據(jù)可以全部放入內(nèi)存。數(shù)據(jù)會(huì)頻繁更新，更新后長(zhǎng)度會(huì)改變。
我花了一天實(shí)現(xiàn)這個(gè) k/v 內(nèi)存數(shù)據(jù)服務(wù)。為了***利用內(nèi)存，并同時(shí)保證效率，以及代碼實(shí)現(xiàn)的簡(jiǎn)潔。我采用預(yù)先分配好整塊內(nèi)存的方案，把內(nèi)存切割成 1K 為單位的區(qū)塊。并用單向鏈表串起來?？紤]到內(nèi)存 cache 的命中效率。鏈表指針本身和數(shù)據(jù)儲(chǔ)存區(qū)分離。（大多數(shù)時(shí)候，我們只需要訪問鏈表指針，而不需要訪問具體數(shù)據(jù)）
鏈表指針采用序號(hào)，而非內(nèi)存地址。這樣即使在 64bit 系統(tǒng)上，依然使用 4 字節(jié)索引（可以***可管理 4T 數(shù)據(jù)，足夠了）。單向鏈表可以比雙向鏈表節(jié)省一半的指針操作以及節(jié)約少量?jī)?nèi)存。代價(jià)是代碼寫起來繁雜一點(diǎn)。
所有內(nèi)存區(qū)塊分成兩部分：空閑區(qū)塊和已用區(qū)塊。一開始全部空間都是空閑。一旦向內(nèi)放入一段數(shù)據(jù)，就從空閑鏈表上摘下夠用的區(qū)塊，放到已用鏈表的尾部。如果 cache 空間滿，則從已用區(qū)塊鏈表頭部移掉一些空間還給空間區(qū)塊（這些數(shù)據(jù)區(qū)是長(zhǎng)久未訪問過的）。每次讀取一段數(shù)據(jù)，都將其調(diào)整到已用鏈表的末尾，保證***才清理。
另外做一個(gè) hash 表，從 id 映射到在 cache 中區(qū)塊段的頭（由于是單向鏈表，具體實(shí)現(xiàn)時(shí)應(yīng)保存上一個(gè)節(jié)點(diǎn)）。這樣可以用 O(1) 時(shí)間查詢指定 id 對(duì)應(yīng)的數(shù)據(jù)區(qū)，
保存在 cache 中的數(shù)據(jù)不必在地址上完全連續(xù)，這好比磁盤的分簇管理。和磁盤不同，內(nèi)存的隨機(jī)訪問性能和順序訪問性能差異更小。這樣有利于內(nèi)存空間利用效率。
【編輯推薦】
