CEDEC16:FateGO伺服器開發經驗分享

FateGO開發商DelightWorks在CEDEC上分享了頭號人氣遊戲這段時間以來的server開發經驗:http://gamebiz.jp/?p=167795

--

client / server都用C#:並非是為了降低學習成本,而是著眼compile(執行速度快/不易出錯)跟好用的IDE

server架構(早先使用MS Azure,後來是AWS)
http://goo.gl/Iea3da
http://goo.gl/VdgMHm

初期設計原則是「盡量減少server / client通訊」以降低負荷:例如任務開放條件就丟給client判斷、戰鬥中也極力避免跟server通訊,只有在玩家更新數值時才會跟server通訊。只有好友資料是固定每隔一段時間就更新。

只不過在開放時大量玩家湧入,server還是掛了;當時仍使用MS Azure,在遊戲server部分能動態調整,但DB卻成了效能瓶頸(bottleneck),即使在區塊內增加機器(Scale-out),負荷能力仍不足以承載;最後DB server記憶體不足,導致了玩家道具錯置的現象。

於是在DB方面採取了以下對策:
http://goo.gl/8k2A5p
。使用當時最高階的機器StandardDS14
。DB重構 。將資料暫存在Redis

為了改善DB,最後決定轉移至AWS(記憶體從112G擴增至244G),總算是穩定下來;但接著卻是來自海外的不正常大量創建帳號,又吃光了DB server記憶體,再度導致玩家道具錯置(4月下旬~5月上旬);以及單位時間內連結量太大,Redis connection pool用光(8/11)
。先用NewRelic找出問題出在哪
。最後把DB垂直分割為四塊解決上述問題

營運遊戲的一大特徵就是規格變動頻繁,因此DB格式也會隨著新從者登場而變動,為此公司還開發了專用工具,能更便利的變更表格格式;其中值得一提的是:供活動使用的泛用Flag欄位(譯註:從簡報上看起來是把任務怪物等所有表格的flag整合在一起)、以及以json型式作成script的任務/怪物資料。

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.