基於 Flink+Pravega 的遊戲伺服器監控與調節系統設計

01

背景介紹

瀏覽完賽題，經團隊討論將應用場景鎖定在了遊戲伺服器最佳化上，一是因為這方面趣味性較高，另外則是團隊中的一員常年用愛發電^[1] 開服，對此比較有業務經驗。

1.1 團隊簡介

團隊四人均為本科生，相識於 Topview 工作室大資料組，現於廣東工業大學就讀。

溫嘉誠：大三本科生，負責整體架構的設計與資料處理部分。

胡錦峰：大三本科生，負責整體架構的設計與日誌採集部分。

鄭梓遊：大二本科生，負責資料傳輸部分。

鄧媚：大二本科生，負責資料展示部分。

遊戲服務端的各種最佳化方案層出不窮，大多是出於 IO/CPU 耗費等方向進行最佳化，不同遊戲亦沒有所謂通用方案。我們希望藉助 Flink 的實時性，從統計分析和資訊內容監控的角度進行進一步深化擴充，以資料分析的方式迅速找到需要最佳化的中心點，實時解決服務端卡頓問題，最佳化玩家體驗，減少人工監控調整成本。重要的是，其應用場景不侷限於某款遊戲，同型別的遊戲只要實現給定的日誌介面和反饋介面，都可透過這套系統進行最佳化。

團隊的系統以 Minecraft 為例，因該遊戲生態豐富，且易於開發。

(你甚至可以在方塊的世界裡前進四^[2]，這遊戲簡直是一個完美的實驗品，Flink 與之結合再好不過了)

1.2 一些概念

• Minecraft 中的遊戲實體包括三部分，掉落物實體、方塊實體、生物實體，極少量玩家線上時，無模組伺服器平均每分鐘都會有上千條實體更新事件產生。
  
  
• 當玩家增多時，玩家擺放的方塊，玩家身邊的實體會進行 tick 計算(1 秒=20 tick)。由於一些歷史和執行順序的原因，區塊生成、實體運算等加起來佔比超過 60%的部分，都在一個主執行緒上執行，市面上大多數嘗試拆分運算到多執行緒的服務端，都因為一些莫名其妙的 bug (破壞“遊戲機制” 或者 導致一些執行緒安全、執行順序、多執行緒反而造成效能下降的問題) 而不慍不火。
  
  
• 對於大型伺服器，任何 bug 都可能導致嚴重後果，本方案几乎不篡改遊戲機制，避免遇到上述 bug。
  
  
• 大型刷怪場 / 大型紅石機器 / 刷石機刷鐵機 /.../ 過大的生存建築包含過量的方塊實體。頭顱、箱子、信標、牌子、發射器、投擲器、旗幟、盔甲架等等都屬於方塊實體，每 1/20 秒都需要參與一次運算。讓這些東西扎堆出現，顯然對服務端不利，會嚴重影響伺服器TPS(Tick Per Second)。直接在服務端進行統計運算是不合適的，這會嚴重影響到玩家體驗。

1.3 方案目的

1. 統計服務端叢集當前時刻實體的異常點，採用定點清除或限制等策略處理異常點，提升服務端運算效率，提高玩家體驗。
   
   
2. 將 Minecraft 的日誌傳送到大資料後端，透過 Flink 進行演算法統計，將演算法引數，輸出結果寫入資料庫報表檢視，或者反饋到服務端對生物生成等引數動態調優。

02

設計方案

2.1 整體架構

該系統的簡化架構如下圖：

2.2 日誌採集及資訊反饋

遊戲服務端實現日誌介面和反饋介面，對接大資料後端

借用 Bukkit 的事件監聽器機制，監聽遊戲內實體的生成及消失資訊，實現我們的日誌介面和反饋介面

1. 對掉落物、生物、狀態方塊進行埋點，獲取其唯一標籤
   
   
2. 定時獲取伺服器 tps、gc 資訊，輸出到大資料後端
   
   
3. 實時獲取玩家資料資訊，記錄玩家聊天資訊，互動資訊等
   
   
4. 從 mysql 獲取大資料後端輸出的異常點，採用不同策略處理
   
   
5. 實時獲取 mysql 資料庫中的服務端動態配置資訊，調整生物重新整理率，降低伺服器負載

2.3 資料傳輸

該部分選用 Pravega 出於以下考慮：

1. 相對於傳統的 Kafka+Flume 組合，使用 Pravega 可以簡化系統處理架構。Pravega 能夠自動的將資料由熱儲存轉為冷儲存，不需要額外的 ETL 開發。
   
   
2. Pravega 對於高吞吐的歷史資料和低延遲的實時資料有一致的訪問方式，能夠有效滿足離線計算和實時計算兩種處理方式的統一。Pravega 便於後續擴充批資料處理業務，如基於長時間段內的資料進行深度學習模型訓練等。
   
   
3. Pravega 相比於 Kafka 可以節省資料儲存開銷。資料在 Pravega 只需要儲存一份，而 Kafka 需要儲存副本。
   
   
4. 系統內部將 Pravega 作為儲存引擎與訊息佇列，利用其能夠自動伸縮的特性，能夠很好地代替 Kafka，並且透過 Pravega Flink Connectors 能夠使其與 Flink 之間絲滑對接。
   
   
5. 出於學習的目的選擇使用 Pravega。Pravega 批流一體的儲存設計具有有大的發展潛力。

• 這裡使用 Springboot 將採集到的資料寫入 Pravega（demo 如下）：

• Flink 透過 Connectors 對 Pravega 資料進行消費。這部分使用起來跟 Kafka 差不多，非常方便。

2.4 資料處理

• 對資料進行 ETL

    將資料缺失的日誌清除掉

• 將總的日誌流按照類別進行分流處理，統計各類實體的數量，便於後續分析
  
  
• 資料處理中需要統計出當前時間內各類掉落物的數量以及當前的座標

以 Item 掉落物類為例，設計思路如下：

1. 主輸出流收集當前時間內掉落物的數量，每來一條遊戲日誌，判斷是否為掉落物類，如果是，判斷日誌型別為掉落或為拾取，分別加上掉落的 amount 或者減去拾取 amount。
   
   
2. 側輸出流收集當前時間內掉落物的物品種類以及他們的座標位置，同樣每來一條遊戲日誌，判斷是否為掉落物類，如果是，將掉落物型別和它們的座標放進 map 中輸出。
   
   
3. 分別將主輸出流和測輸出流寫進 MySQL 中，作為資料展示。

Entity 生物實體類以及 tileEntity 方塊實體類的資料處理與 Item 類相似，這裡就不一一列舉了

• 使用 DBSCAN 聚類演算法對資料點進行實時分析
  
  
• 考慮到伺服器中資料點的分佈是無規則的，而 DBSCAN 是一種可以處理任意形狀的空間聚類問題的基於密度的聚類演算法，所以該系統選用了 DBSCAN 對資料進行分析。DBSCAN 演算法還具有不需要劃分類別個數、可以處理噪聲點等優點。
  
  
• 這裡採用的是 org.apache.commons.math3.stat.clustering.DBSCANClusterer<T>

• 要實現實時分析，需要將舊的計算結果儲存起來，當新資料到來時能基於舊結果進行計算更新。我們採取的方案是：將每個 cluster 的密度 ρ（cluster 內資料點數/cluster 面積）作為 cluster 中心點的計算權值，既一批資料點經過聚類計算後得到的是各個 cluster 的中心點集，包含了中心點的座標和權值，將其儲存在 Flink 的 State中。當新的資料點到來時就將其與 State 中的中心點集一同進行聚類，並更新最新的中心點集到 State。
  
  
• 當某中心點 ρ 值大於設定的閾值，則判定為需要進行清理的點，將該點輸出至 MySQL 表中。伺服器檢測到表資料就會對該中心點所在區塊的資料進行清理。
  
  

系統檢測到密集點座標並對掉落物進行清理（雞與牛肉所屬類別不同所以不會被清理）

系統對密集點所屬區塊生物進行清理

服務端中目前可供調節的動態配置引數

2.5 效果展示

該部分使用 Quick BI 實時讀取 MySQL 中的資料進行展示。

• 服務端將實體座標資訊傳給大資料後端，經處理輸出到報表系統，實時檢視地圖生物資訊。實現衛星地圖效果

Entity（生物類別）資料的分佈

tileEntity（方塊類別）資料的分佈

實體資料統計圖

如果你有足夠的耐心，就可以在伺服器裡用方塊實體擺一幅這樣的圖出來

清理前 TPS：

清理後 TPS：

03

結語

離開 Minecraft，對大多數網遊而言，Flink 的實時性相當契合遊戲要求的即時運算，很多原本存在於遊戲服務端的計算資源，都可以被解放出來，由 Flink 後端代作處理，再迅速將結果返回服務端。舉一些我們能想到的對實時性要求比較高的例子；

1. 大型網遊的實時任務系統
   
   
2. Boss 掉落物的實時調整，物品推薦
   
   
3. 服務端沒法迅速響應的分類迴歸預測
   
   
4. NPC的自然語言處理任務

實際上，遊戲中實時處理的需求比比皆是，Flink 能做的遠不止於此，隨著更多需求的發掘和轉移，Flink 或為網遊業帶來一次"前進四"。

整體來說，該系統是對最佳化遊戲這一想法的成功實現，我們認為這次比賽學習到了很多，認識到同大佬間的差距。接下來就得好好準備考試月了，希望來年還有機會參加 Flink 挑戰賽，與參賽選手和評委們產生思維和技術的碰撞！

參考

•  解構流儲存 — Pravega（）
• MCBBS-外掛開發教程（）

[1] 用愛發電指在收益較低或沒有收益的情況下仍然堅持做某事，這裡指我們團隊開遊戲伺服器

[2] 上圖取自網路動畫《我的三體章北海傳》，改編自劉慈欣著作的的科幻小說作品《三體 2：黑暗森林》，動畫早期由愛好者藉助遊戲 Minecraft 拍攝。前進四”出於作品中章北海劫持亞洲艦隊旗艦飛船發出了飛船前進四的指令。前進四，是該飛船的最大加速度檔位，最高速度達到光速的百分之十五。