游戏开发论坛

 找回密码
 立即注册
搜索
查看: 11014|回复: 9

数据广播方案的优化

[复制链接]

7

主题

82

帖子

110

积分

注册会员

Rank: 2

积分
110
QQ
发表于 2008-3-22 18:07:00 | 显示全部楼层 |阅读模式
Blog: http://blog.csdn.net/lfhfut
MSN: beyondlimit2001@hotmail.com
QQ: 26085163



在服务器组的架构下,我们一般会引入一个网关服务器,或类似功能的组件,所有的客户端连接都是到这里,数据然后转发给当前所在的地图服务器。

这样,在数据广播时便存在一个很大的优化可能性。以前的单服务器架构时,比如要广播移动消息,可以直接找出周围的玩家列表,构造要发送的数据,然后依次调用send即可。但是在多服务器架构下要是还这么做的话,那地图服务器与网关服务器之间的数据传输量将会非常大,而且这些数据之间除了目标IP地址不一样外,实际内容完全相同。

其实在以前单服务器架构时就曾考虑过该优化方案。最初使用的立即发送数据包的方式在遇到需要同时发送大量数据时出现了问题,为了避免由于在逻辑线程内的send调用导致的游戏逻辑被阻塞,我们将数据发送工作放到了一个独立的线程中,游戏逻辑线程在需要向客户端发送数据时,只是将要发送的数据包和客户端连接句柄递交给了发包线程。这个过程也就和带网关的多服务器架构完全类似了。

当时也是为了避免给发包线程递交太多的请求,因为每个发包请求都需要拷贝一次数据包并添加到发送队列中,显而易见的弊端就是数据多次拷贝的CPU消耗和队列中存在多份数据的内存消耗,所以优化的必要性非常高。

最终采取的方案是只递交一次发包请求,在请求包里面包含了这个数据包要发送到的客户端句柄列表,这样数据完全不需要做拷贝,而且内存占用也只有一份。

放到多服务器架构下也可以这样做,区别仅在于发包请求是发送给了网关服务器。


以前的方案只做到了这一步,再继续考虑一下,其实还有进一步优化的可能。

拿比较简单的聊天数据包来说,比如在一个小组频道内聊天,服务器在广播此类数据包时,每次递交的发包请求中的客户端句柄列表都是相同的,除非队员发生变动。所以,可以考虑的是这个列表其实不用每次都发送。通过控制命令在网关服务器上先建立好这些广播组,以后广播数据时只需要指明广播组编号即可。在云风的《游戏服务器内的组播》一文中对此有介绍。

这里的组我们也可以称之为频道,比如小组频道,团队频道,公会频道,世界频道,本地频道,当前频道等,当然还可能会有自建的频道,每个频道有一个唯一ID。不同玩家间的当前频道需要独立,但其他频道可以共用。

关于当前频道需要特别说明一下。这里的当前频道指的是以玩家当前所在位置为中心点的一个可见范围,也就是当玩家移动,或者说话时需要广播到的范围。因为玩家位置是经常会变动的,所以这个频道内的玩家列表变动也非常频繁,而且不同玩家间的当前频道不能像小组频道一样进行共用。

这个方案对于玩家列表变动不频繁的组队聊天这类情况很有效,但是对于玩家列表会频繁变动的当前频道广播却有些麻烦,维护这类频道会使得地图服务器与网关服务器之间的频道成员管理命令非常频繁。

但是这里也有个选择,一是在频道成员发生变化时立即向网关服务器通知变动,另外一种做法是只在有频道数据要递交时才检查有无成员变动。

比如一个玩家坐着没有动,不停有玩家从其旁边经过,这时他的当前频道玩家列表是不断变化的,但如果该玩家不做任何操作,比如移动和在当前频道聊天,这个变动情况其实是不需要反馈到网关服务器的,因为不会有这个频道内的数据需要广播。

当然,如果这样做的话,可能就需要在地图服务器上也保留两份当前频道玩家列表,用于比较该列表的变动情况,这也就是要在内存占用和网络数据传输量上做个权衡。虽然未经实践验证,目前来说我还是比较倾向于后一种方案。

4

主题

16

帖子

16

积分

新手上路

Rank: 1

积分
16
发表于 2008-4-25 15:33:00 | 显示全部楼层

Re: 数据广播方案的优化

呵呵,我就是这么做的... [em1] [em1] [em2] [em1]

0

主题

34

帖子

34

积分

注册会员

Rank: 2

积分
34
发表于 2008-4-26 14:43:00 | 显示全部楼层

Re:数据广播方案的优化

学到很多谢谢

0

主题

11

帖子

11

积分

新手上路

Rank: 1

积分
11
发表于 2008-6-2 16:45:00 | 显示全部楼层

Re:数据广播方案的优化

关于当前频道玩家列表,可不可以让客户端自己提交?也就是客户端自己监视周围的玩家,每次发送消息时附要可以接收该消息的玩家列表。
当然这会加大网络传输量,具体情况下得权衡。

10

主题

69

帖子

69

积分

注册会员

Rank: 2

积分
69
发表于 2008-6-2 20:06:00 | 显示全部楼层

Re: 数据广播方案的优化

123
sf_20086220613.jpg

0

主题

5

帖子

9

积分

新手上路

Rank: 1

积分
9
发表于 2008-8-21 14:30:00 | 显示全部楼层

Re:数据广播方案的优化

不错.
能否进一步完善一下, 以使GateServer简化一些? 比如, 像MapServer广播信息的时候, 采用如下的包结构:
role1, role2, ... roleN, data....
给GateServer, GateServer只根据包进行广播,这样GateServer无须增加复杂的业务管理工作.

15

主题

368

帖子

406

积分

中级会员

Rank: 3Rank: 3

积分
406
发表于 2008-8-28 21:07:00 | 显示全部楼层

Re:数据广播方案的优化

楼上的做法也行。根据实际需要了。
不过如果gateserver上也保存一份,gate可以做的事情可以相当多。

一个成功游戏的服务器硬件的价格和网络带宽购买的花钱相比实在算不了什么。让gate承担更多的工作可以做很多优化。比如干脆就在gate上做zip压缩。一台gate服务器吃不消再多加一台。如果做得好的话,省下来的带宽钱过不了几个月就能收回服务器的硬件成本。(当然那种一两个月就完蛋的游戏除外~~)

15

主题

368

帖子

406

积分

中级会员

Rank: 3Rank: 3

积分
406
发表于 2008-8-28 21:09:00 | 显示全部楼层

Re:数据广播方案的优化

网游服务器解决方案没有银弹的。根据自身需要来吧。也别太迷信别人~呵呵

7

主题

82

帖子

110

积分

注册会员

Rank: 2

积分
110
QQ
 楼主| 发表于 2008-8-29 19:03:00 | 显示全部楼层

Re: Re:数据广播方案的优化

alittlewolf: Re:数据广播方案的优化

不错.
能否进一步完善一下, 以使GateServer简化一些? 比如, 像MapServer广播信息的时候, 采用如下的包结构...


之前做优化的时候采用的这种方法,socketid, socketid, socketid, data

这篇文章中说的方法是进一步考虑之后想到的方法,打算在这个游戏中做,目前还未完成,所以可能会存在问题,或者是有更好的方法

写出来只是给自己做个记录,也希望能有好的反馈,给自己些帮助

7

主题

82

帖子

110

积分

注册会员

Rank: 2

积分
110
QQ
 楼主| 发表于 2008-8-29 19:05:00 | 显示全部楼层

Re: Re:数据广播方案的优化

yukun84: Re:数据广播方案的优化

网游服务器解决方案没有银弹的。根据自身需要来吧。也别太迷信别人~呵呵



确实,没有绝对的方法,其实一直也是在不停折腾,试验各种不同的做法

很多时候这跟个人的喜好也有关,只要最终的目标达到了,中间的过程自由发挥
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2026-1-21 11:49

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表