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

作者｜挑戰賽季軍隊伍工一611

一、背景介紹

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

團隊簡介

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

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

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

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

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

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

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

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

一些概念

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

方案目的

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

二、設計方案

整體架構

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

日誌採集及資訊反饋

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

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

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

資料傳輸

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

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

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

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

資料處理

對資料進行 ETL

將資料缺失的日誌清除掉

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

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

主輸出流收集當前時間內掉落物的數量，每來一條遊戲日誌，判斷是否為掉落物類，如果是，判斷日誌型別為掉落或為拾取，分別加上掉落的 amount 或者減去拾取 amount。
側輸出流收集當前時間內掉落物的物品種類以及他們的座標位置，同樣每來一條遊戲日誌，判斷是否為掉落物類，如果是，將掉落物型別和它們的座標放進 map 中輸出。
分別將主輸出流和測輸出流寫進 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 表中。伺服器檢測到表資料就會對該中心點所在區塊的資料進行清理。