游戏服务器技术交流

qinglan

Zone Server确实是按空间来划分的

因为一个区域内的玩家会进行频繁的交互，消息包广播等

如果把他们分到不同的服务器上，那服务器间通讯的开销也大了，还会增加系统的复杂性

当然，如果像EQ2那样，普通区域内也分副本，而且各副本间完全独立的话倒是可以这样做

sjinny

这样的话，单个区域内的承载能力仍然很有限，而且玩家在各个区域的分布也不会很均匀，势必会造成部分服务器很空闲而另外一些服务器则不堪重负，也就是有资源但没有充分发挥作用的情况。现在有办法解决这样的问题吗？

qinglan

Zone Server做动态负载均衡，当某个Zone Server负载较大时，自动把自己分为四个，减少广播域

其他就只能让策划朋友从玩法上来限制，不要让一个区域出现太多人了

bigbook2000

这种结构在实际的部署中也遇到了一些挑战。对于一般的MMORPG服务器来说，单台服务器的承载量平均在2000左右

什么MMORPG的逻辑可以使单台服务器能上2000？

NPC都是死的？玩家都不干活？

qinglan

bigbook2000: Re: 游戏服务器技术交流



什么MMORPG的逻辑可以使单台服务器能上2000？

NPC都是死的？玩家都不干活？

终于有了一个反对的声音
[em1]


首先2000这个数字是我统计的一个平均值，统计的依据来自于与其他人的讨论和别人提供的数据，另外一些公司提供的运营数据打点折也可以估算个大概。或许是大家都夸大了自己的能力，或公司公开的数据水分超过了我的估计？呵呵

当然，我们的游戏也没有单台2000，但我认为现在的服务器存在很大的提升余地

至于你说的NPC是死的，玩家干不干活

NPC最消耗系统资源的当属AI了，特别是一些复杂的寻路，这个完全可以分离到一台单独的AI服务器上，不少游戏都是这么做的，从一些泄漏出来的服务器端上也可以看到

生物管理，状态更新和消息广播在Zone Server上做，其他公共逻辑模块在Master Server和Center Server上跑，那这样其实也就没有一个单台服务器承载量的概念了，可能要说数据的话还是以一组服务器为单位比较合适

另外我一直以wow的结构来做参考，希望实现的也跟wow差不多，所以这些数字也可以算做是我的目标吧

sjinny

Zone Server做动态负载均衡，当某个Zone Server负载较大时，自动把自己分为四个，减少广播域

这样又有一个问题，拆分区域之后，从哪里找来对应的服务器资源呢？设置一些平时不用的服务器来备用，这个似乎不太可能。那么是否意味着在拆分的同时还会对应着其他区域的合并呢？

qinglan

　　如果我们就此打住，可能马上就会有人要嗤之以鼻了，就这点古董级的技术也敢出来现。好吧，我们还是把之前留下的问题拿出来解决掉吧。

　　一般来说，当某一部分能力达不到我们的要求时，最简单的解决方法就是在此多投入一点资源。既然想要更多的连接数，那就再加一台网关服务器吧。新增加了网关服后需要在大区服上做相应的支持，或者再简单点，有一台主要的网关服，当其负载较高时，主动将新到达的连接重定向到其他网关服上。

　　而对于游戏服来说，有一台还是多台网关服是没有什么区别的。每个代表客户端玩家的对象内部都保留一个代表其连接的对象，消息广播时要求每个玩家对象使用自己的连接对象发送数据即可，至于连接是在什么地方，那是完全透明的。当然，这只是一种简单的实现，也是普通使用的一种方案，如果后期想对消息广播做一些优化的话，那可能才需要多考虑一下。

　　既然说到了优化，我们也稍稍考虑一下现在结构下可能采用的优化方案。

　　首先是当前的Zone Server要做的事情太多了，以至于他都处理不了多少连接。这其中最消耗系统资源的当属生物的AI处理了，尤其是那些复杂的寻路算法，所以我们可以考虑把这部分AI逻辑独立出来，由一台单独的AI服务器来承担。

　　然后，我们可以试着把一些与地图数据无关的公共逻辑放到Master Server上去实现，这样Zone Server上只保留了与地图数据紧密相关的逻辑，如生物管理，玩家移动和状态更新等。

　　还有聊天处理逻辑，这部分与游戏逻辑没有任何关联，我们也完全可以将其独立出来，放到一台单独的聊天服务器上去实现。

　　最后是数据库了，为了减轻数据库的压力，提高数据请求的响应速度，我们可以在数据库之前建立一个数据库缓存服务器，将一些常用数据缓存在此，服务器与数据库的通信都要通过这台服务器进行代理。缓存的数据会定时的写入到后台数据库中。

　　好了，做完这些优化我们的服务器结构大体也就定的差不多了，暂且也不再继续深入，更细化的内容等到各个部分实现的时候再探讨。

　　好比我们去看一场晚会，舞台上演员们按着预定的节目单有序地上演着，但这就是整场晚会的全部吗？显然不止，在幕后还有太多太多的人在忙碌着，甚至在晚会前和晚会后都有。我们的游戏服务器也如此。

　　在之前描述的部分就如同舞台上的演员，是我们能直接看到的，幕后的工作人员我们也来认识一下。

　　现实中有警察来维护秩序，游戏中也如此，这就是我们常说的GM。GM可以采用跟普通玩家一样的拉入方式来进入游戏，当然权限会比普通玩家高一些，也可以提供一台GM服务器专门用来处理GM命令，这样可以有更高的安全性，GM服一般接在中心服务器上。

　　在以时间收费的游戏中，我们还需要一台计费的服务器，这台服务器一般接在网关服务器上，注册玩家登录和退出事件以记录玩家的游戏时间。

　　任何为用户提供服务的地方都会有日志记录，游戏服务器当然也不例外。从记录玩家登录的时间，地址，机器信息到游戏过程中的每一项操作都可以作为日志记录下来，以备查错及数据挖掘用。至于搜集玩家机器资料所涉及到的法律问题不是我们该考虑的。

　　差不多就这么多了吧，接下来我们会按照这个大致的结构来详细讨论各部分的实现。

qinglan

　　再强调一下，服务器结构本无所谓好坏，只有是否适合自己。我们在前面探讨了一些在现在的游戏中见到过的结构，并尽我所知地分析了各自存在的一些问题和可以做的一些改进，希望其中没有谬误，如果能给大家也带来些启发那自然更好。

　　突然发现自己一旦罗嗦起来还真是没完没了。接下来先说说我在开发中遇到过的一些困惑和一基础问题探讨吧，这些问题可能有人与我一样，也曾遇到过，或者正在被困扰中，而所要探讨的这些基础问题向来也是争论比较多的，我们也不评价其中的好与坏，只做简单的描述。

　　首先是服务器操作系统，linux与windows之争随处可见，其实在大多数情况下这不是我们所能决定的，似乎各大公司也基本都有了自己的传统，如网易的freebsd，腾讯的linux等。如果真有权利去选择的话，选自己最熟悉的吧。

　　决定了OS也就基本上确定了网络IO模型，windows上的IOCP和linux下的epool，或者直接使用现有的网络框架，如ACE和asio等，其他还有些商业的网络库在国内的使用好像没有见到，不符合中国国情嘛。

　　然后是网络协议的选择，以前的选择大多倾向于UDP，为了可靠传输一般自己都会在上面实现一层封装，而现在更普通的是直接采用本身就很可靠的TCP，或者TCP与UDP的混用。早期选择UDP的主要原因还是带宽限制，现在宽带普通的情况下TCP比UDP多出来的一点点开销与开发的便利性相比已经不算什么了。当然，如果已有了成熟的可靠UDP库，那也可以继续使用着。

　　还有消息包格式的定义，这个曾在云风的blog上展开过激烈的争论。消息包格式定义包括三段，包长、消息码和包体，争论的焦点在于应该是消息码在前还是包长在前，我们也把这个当作是信仰问题吧，有兴趣的去云风的blog上看看，论论。

　　另外早期有些游戏的包格式定义是以特殊字符作分隔的，这样一个好处是其中某个包出现错误后我们的游戏还能继续。但实际上，我觉得这是完全没有必要的，真要出现这样的错误，直接断开这个客户端的连接可能更安全。而且，以特殊字符做分隔的消息包定义还加大了一点点网络数据量。

　　最后是一个纯技术问题，有关socket连接数的最大限制。开始学习网络编程的时候我犯过这样的错误，以为port的定义为unsigned short，所以想当然的认为服务器的最大连接数为65535，这会是一个硬性的限制。而实际上，一个socket描述符在windows上的定义是unsigned int，因此要有限制那也是四十多亿，放心好了。

　　在服务器上port是监听用的，想象这样一种情况，web server在80端口上监听，当一个连接到来时，系统会为这个连接分配一个socket句柄，同时与其在80端口上进行通讯；当另一个连接到来时，服务器仍然在80端口与之通信，只是分配的socket句柄不一样。这个socket句柄才是描述每个连接的唯一标识。按windows网络编程第二版上的说法，这个上限值配置影响。

　　好了，废话说完了，下一篇，我们开始进入登录服的设计吧。

口水龙

楼主写的不错，据我观察，WOW差不多2000人/组，其他即时战斗的MMO也差不多1000-2000人/组，回合的会多一些，梦幻差不多3K-4K人/组，单地图的承载也比较多，因为要同步的东西比较少

bigbook2000

最后是一个纯技术问题，有关socket连接数的最大限制。开始学习网络编程的时候我犯过这样的错误，以为port的定义为unsigned short，所以想当然的认为服务器的最大连接数为65535，这会是一个硬性的限制。而实际上，一个socket描述符在windows上的定义是unsigned int，因此要有限制那也是四十多亿，放心好了。

accept返回的SOCKET不占用端口吗？