網頁遊戲服務端-人物移動廣播最佳化

標籤：style   blog   c   http   a   strong   

【本文轉自網路http://janeky.iteye.com/blog/1614175】

這段時間在處理服務端人物移動廣播遇到了問題，記錄一下。

 

1.問題

現在的頁遊都朝著用戶端的方向靠齊了，大地圖，千人同屏。因此，也給頁遊的服務端開發帶來了不少的挑戰。假設一個情境地圖是8000*8000大小，同時有1000人在。1秒鐘內，每個玩家移動一次。按照最原始的做法，就是給同一個情境的使用者廣播訊息。簡單計算一下廣播量:1000*1000=1000000的廣播量，有點恐怖。

 

2.方案

最佳化的目標肯定是減少廣播量了。我們看到，情境特別大，這對於美術同事來說不是什麼好事了，對於服務端來說，未嘗是壞事。假設最理想的狀態下，使用者能夠遍布各個角落。那麼，我們只想向能看到移動目標的使用者廣播訊息就行了。假設一個螢幕大小為1600*1000，一個螢幕理論上分布了8000*8000/(1600*1000)=25人。還是每秒每個人移動一次，總的廣播訊息量是:25*25*40 = 25000.哈哈，整整少了40倍的廣播量，服務端壓力少了，替老闆省了不少錢，回去申請加點獎金吧。

 

3.實現

按照上面的思路，實現起來就非常簡單了。以前是給情境的每個使用者廣播，現在只需增加一步篩選的過程，根據座標選擇視範圍內能看到移動目標的玩家。方法比較簡單，這裡就不提供詳細的代碼實現了，還有不清楚的，可以留言討論一下。

 

4.最佳化

做到上面的，基本上已經符合標準了。但是，作為搞技術的，追求完美是無止境的。我們又在想，還能不能進一步最佳化？好的最佳化總是在仔細分析問題的基礎上產生的。我們相信分析一下廣播的內容，加入a移動了，那麼在同屏的b,c分別會受到一條廣播，內容大致是(a,from,to).同理，b移動了，a,c也是受到這樣類型的廣播。c在同一個時間段收到了兩條廣播。這兩條廣播能否合并呢，變成(a,from,to;b,from,to).這就是最佳化的靈感了。對於即時性不高的回合制頁遊（非即使戰鬥arpg)，玩家看到其他玩家的移動，並不要求一定即時。為此，我們可以考慮合并

訊息。

 

實現起來非常簡單，可以用一種類似生產者-消費者的模型來實現。每次前端發來的位移訊息都放入隊列。後端有個獨立的線程，每隔一段時間，取出來資料，合并訊息，廣播給相關的使用者。上述a,b位移後，c只收到一條訊息了

 

5.總結

很多問題的解決是來自對問題的透徹理解。遇到問題，我們應該慶幸，又有折騰了。