网页游戏服务端-人物移动广播优化

【本文转自网络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.总结

不少问题的解决是来自对问题的透彻理解。遇到问题，咱们应该庆幸，又有折腾了。