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

【本文轉自網絡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.總結

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