C/C++伺服器架構機制設計總結
近期在寫基於go的遊戲伺服器框架, 在全面脫離C/C++前, 需要對老架構進行一個總結
基於C/C++遊戲伺服器框架總體設計的還是不錯的, 兄弟們總體使用效果都是好評. 因為在技術上喜歡"偷懶", 所以在很多設計上, 都是力求簡單, 高效(開發效率).
基於任務的非同步DB查詢系統, 帶多重非同步的同步
程式碼示例:
1:
2: void BatchQueryPlayerInfo( uint32 ClientID, const std::string& AccountName, int64 CharID )
3: {
4: GDBExecutor->Commit
5: (
6: dynamic_cast<DBDataTask*>( (new DBQueryCharInfo( ClientID, CharID ) )
7: ->LinkAtomTask( new DBQueryQuest( ClientID, CharID ) )
8: ->LinkAtomTask( new DBQuerySkill( ClientID, CharID ) )
9: ->LinkAtomTask( new DBQueryHero( ClientID, CharID ) )
10: ->LinkAtomTask( new DBQueryAccountInfo( ClientID, AccountName ) )
11: ->LinkAtomTask( new DBQueryEquip( ClientID, CharID ) )
12: ->LinkAtomTask( new DBQueryObject( ClientID ,CharID ) )
13: ->LinkAtomTask( new DBQueryLevel(ClientID, CharID))
14:->LinkAtomTask( new DBQueryChapter(ClientID, CharID))
15: ->LinkAtomTask( new DBQueryActivity( ClientID, CharID ))
16: )
17: );
18:
19: }
這段主要處理玩家在登陸時, 需要從DB查詢大量的不同分類的資料. 為了保證效率, 我讓每個Task並行執行, 然後通過一個機制, 讓所有任務完成後, 回撥第一個任務的一個函式. 這樣就無需手動實現很多粘合程式碼, 避免了反覆除錯和錯誤
基於protobuf反射機制的語句自動合成
1: DBUpdateCharInfo::DBUpdateCharInfo( int64 CharID, const std::string& Buffer )
2: {
3: char buffer[256];
4:
5: sprintf( buffer, "update tb_char set $FIELD$ where charid = %lld;", CharID );
6:
7: ExecuteCommand( buffer, Buffer, dbopr::FET_Equation );
8: }
這段就是一個典型的DB任務, 建構函式提供了CharID和一個由結構體序列化好的buffer, $FIELD$欄位, 是通過反射根據Buffer內容, 自動填充欄位
這段例子中, $FIELD$可以填充為 hp=100, mp=100之類的. 自動填充避免了因為新增欄位的到處新增程式碼, 還需要除錯, 容易搞錯
配置系統概念
基於同一個配置系統, 分層實現不同的需求. 更簡單的說, 解決的1個實際問題是:
自己改了配置檔案中的ip, 上傳svn後, 覆蓋了別人的配置, 很多人的解決方法都是, 本地配置不提交. 但同時問題又來了:
當配置中有別人新加的系統配置, 怎麼保證每個人都能更新到?
上線後, 伺服器交付運維, 他們會對配置有一定程度的修改, 這個時候怎麼合併程式配置和運維配置?
其實對於衝突的需求, 只要對系統進行分層就可以解決問題,我的處理方式:
配置分為:
全域性配置: 所有服務的總體配置
單服務配置: 本服務的配置, 涉及網路及邏輯
本地配置: 這個配置每個人一份, 不上傳SVN
命令列配置: 格式和前面的一致, 這塊就可以通過運維進行配置
總體結構其實就是OO的派生概念, 下層可以覆蓋, 修改上層的配置
伺服器互聯及識別框架
基本功能: 基於一些簡單的配置就可以將多臺伺服器, 同種類的不同伺服器互相連線起來, 斷線自動重連.
伺服器連線後, 所有伺服器可知曉並可自動按需連線
邏輯端也很方便的進行廣播或者單獨傳送等
也就是說, 每個伺服器的連線和接受端都是帶識別名稱或id的.
後面覺得這套東西實在是做的複雜, 多整出一臺中心伺服器來做. 但好歹框架穩定下來了, 也就好了.
基於lua的伺服器web後臺框架
思想是很不錯的, C++ 配合lua本身絕對是個失敗
問題出在web處理,本身都是一個同步阻塞過程, 而這個後臺框架是非同步方式來做, 所以特別彆扭
不過比起以前的本地GM系統, 這塊的設計是偉大的進步
現在正在設計基於golang的伺服器框架, 基本框架已經完工, 等待編寫邏輯後的實戰測試
以上的很多思想在golang的伺服器框架都有改進, 特別是golang本身做web也是優秀的, 外加martini這種牛X框架, 更是水到渠成
如果你對伺服器框架設計有特別的認識, 或者想碰撞思想, 可以加部落格群 309800774或者我的qq: 20998333討論