原文鏈接：http://codemacro.com/2012/04/25/game-server-info-2/
上一篇談了一些關(guān)鍵技術(shù)的實(shí)現(xiàn)方案。本篇描述一些遇到的問題。
一
在策劃制作完了幾個(gè)職業(yè)后（主要是技能制作），大概去年年底公司內(nèi)部進(jìn)行了一次混戰(zhàn)測試。30個(gè)角色在一個(gè)場景進(jìn)行混戰(zhàn)，測試結(jié)果從技術(shù)上來說非常不理想。首先是客戶端和服務(wù)器都巨卡無比。服務(wù)器CPU一直是滿負(fù)載狀態(tài)。而客戶端又頻繁宕機(jī)。
我們關(guān)注的主要問題，是服務(wù)器CPU滿負(fù)載問題。最開始，我通過日志初步定位為網(wǎng)絡(luò)模塊問題，因?yàn)檫壿嬀€程表現(xiàn)不是那么差。然后考慮到技能過程中的特效、動(dòng)作都是通過服務(wù)器消息驅(qū)動(dòng)，并且本身特效和動(dòng)作就比一般網(wǎng)游復(fù)雜，通過逐一屏蔽這一部分功能，最終確認(rèn)確為網(wǎng)絡(luò)模塊導(dǎo)致。然后團(tuán)隊(duì)決定從兩方面努力：重寫網(wǎng)絡(luò)模塊，改善性能；改善技能實(shí)現(xiàn)機(jī)制，將表現(xiàn)類邏輯移到客戶端。
至于網(wǎng)絡(luò)模塊，在后來才發(fā)現(xiàn)，雖然網(wǎng)絡(luò)流量過高，但導(dǎo)致網(wǎng)絡(luò)線程CPU滿的原因竟然是網(wǎng)絡(luò)模塊自身的流量限制導(dǎo)致。而技能實(shí)現(xiàn)機(jī)制的改善，考慮到改動(dòng)的成本，最終使用了一種RPC機(jī)制，讓服務(wù)器腳本可以調(diào)用客戶端腳本，并且支持傳入復(fù)雜參數(shù)。然后策劃通過一些關(guān)鍵數(shù)據(jù)在客戶端計(jì)算出特效、動(dòng)作之類。
此外，程序?qū)⒏嗟募寄軐傩詮V播給客戶端，一個(gè)客戶端上保存了周圍角色的技能數(shù)據(jù)，從而可以進(jìn)行更多的客戶端邏輯。這一塊具體的修改當(dāng)然還是策劃在做（我們的腳本策劃基本就是半個(gè)程序員）。后經(jīng)測試，效果改善顯著。
二
在策劃制作了一個(gè)PVP競技副本后，服務(wù)器在10V10測試過程中又表現(xiàn)出CPU負(fù)載較高的情況。這個(gè)問題到目前為止依然存在，只不過情況略微不同。
首先是觸發(fā)器生命周期的問題。觸發(fā)器自身包含最大觸發(fā)次數(shù)、存留時(shí)間等需求，即當(dāng)觸發(fā)一定次數(shù)，或超過存留時(shí)間后，需要由程序自動(dòng)刪除；另一方面，觸發(fā)器可以是定時(shí)器類型，而定時(shí)器也決定了觸發(fā)器的生命周期。這一塊代碼寫的非常糟糕，大概就是管理職責(zé)劃分不清，導(dǎo)致出現(xiàn)對(duì)象自己刪除自己，而刪除后還在依賴自己做邏輯。
但這樣的邏輯，最多就是導(dǎo)致野指針的出現(xiàn)。不過，這種混亂的代碼，也更容易導(dǎo)致BUG。例如，在某種情況下觸發(fā)器得不到自動(dòng)刪除了。但這個(gè)BUG并不是直接暴露的，直接暴露的，是CPU滿了。我們的怪物AI在腳本中是通過定時(shí)器類觸發(fā)器驅(qū)動(dòng)的，每次AI幀完了后就注冊一個(gè)觸發(fā)器，以驅(qū)動(dòng)下一次AI幀。由于這個(gè)BUG導(dǎo)致觸發(fā)器沒有被刪除，從而導(dǎo)致服務(wù)器上觸發(fā)器的數(shù)量急劇增加。但，這也就導(dǎo)致內(nèi)存增長吧？
另一個(gè)巧合的原因在于，在當(dāng)時(shí)的版本中，觸發(fā)器是保存一個(gè)表里的，即定時(shí)器類觸發(fā)器、屬性類觸發(fā)器、移動(dòng)類觸發(fā)器等都在一個(gè)表里。每次任意觸發(fā)器事件發(fā)生時(shí)，例如屬性改變，都會(huì)遍歷這個(gè)表，檢查其是否觸發(fā)。
基于以上原因，悲劇就發(fā)生了。在這個(gè)怪物的AI腳本里，有行代碼設(shè)置了怪物的屬性。這會(huì)導(dǎo)致程序遍歷該怪物的所有觸發(fā)器。而這個(gè)怪物的觸發(fā)器數(shù)量一直在增長。然后就出現(xiàn)了在很多游戲幀里出現(xiàn)過長的遍歷操作，CPU就上去了。
找到這個(gè)問題了幾乎花了我一天的時(shí)間。因?yàn)槟_本代碼不是我寫的，觸發(fā)器的最初版本也不是我寫的。通過逐一排除可能的代碼，最終竟然發(fā)現(xiàn)是一行毫不起眼的屬性改變導(dǎo)致。這個(gè)問題的查找流程，反映了將大量邏輯放在腳本中的不便之處：查起問題來實(shí)在吃力不討好。
修復(fù)了這個(gè)BUG后，我又對(duì)觸發(fā)器管理做了簡單的優(yōu)化。將觸發(fā)器列表改成二級(jí)表，將觸發(fā)器按照類型保存成幾個(gè)列表。每次觸發(fā)事件時(shí)，找出對(duì)應(yīng)類型的表遍歷。
改進(jìn)
除了修改觸發(fā)器的維護(hù)數(shù)據(jù)結(jié)構(gòu)外，程序還實(shí)現(xiàn)了一套性能統(tǒng)計(jì)機(jī)制，大概就是統(tǒng)計(jì)某個(gè)函數(shù)在一段時(shí)間內(nèi)的執(zhí)行時(shí)間情況。最初這套機(jī)制僅用于程序，但考慮到腳本代碼在整個(gè)項(xiàng)目中的比例，又決定將其應(yīng)用到腳本中。
這個(gè)統(tǒng)計(jì)需要在函數(shù)進(jìn)入退出時(shí)做一些事情，C++中可以通過類對(duì)象的構(gòu)建和析構(gòu)完成，但lua中沒有類似機(jī)制。最初，我使用了lua的調(diào)試庫來捕獲函數(shù)進(jìn)入/退出事件，但后來又害怕這種方式本身存在效率消耗，就取消了。我們使用lua的方式，不僅僅是全局函數(shù)，還包括函數(shù)對(duì)象。而函數(shù)對(duì)象是沒有名字標(biāo)示的，這對(duì)于日志記錄不是什么好事。為了解決這個(gè)問題，我只好對(duì)部分功能做了封裝，并讓策劃顯示填入函數(shù)對(duì)于的字符串標(biāo)示。
除此之外，因?yàn)橛|發(fā)器是一種重要的敏感資源，我又加入了一個(gè)專門的觸發(fā)器統(tǒng)計(jì)模塊，分別統(tǒng)計(jì)觸發(fā)器的類型數(shù)量、游戲?qū)ο髶碛械挠|發(fā)器數(shù)量等。
END
到目前為止，導(dǎo)致服務(wù)器CPU負(fù)載過高，一般都是由BUG導(dǎo)致。這些BUG通常會(huì)造成一個(gè)過長的列表，然后有針對(duì)這個(gè)列表的遍歷操作，從而導(dǎo)致CPU負(fù)載過高。更重要的，我們使用了這么多的腳本去開發(fā)這個(gè)游戲，如何找到一個(gè)更有效合理的監(jiān)測方法，如何讓程序框架更穩(wěn)定，則是接下來更困難而又必須去面對(duì)的事情。