站务联系

经典游戏服务器端架构概述 (2)

发布时间:2021-05-16   来源:网络整理    
字号:

接前篇精典游戏服务器端构架绪论(1)

全服分线模型一. 模型描述

由于多进程服务器模型的发展,游戏开发者们首先发觉,由于游戏业务的特性,那些还要持久化的数据,一般都是玩家的存盘,以及一些游戏本来还要用的,在运行期只读的数据。这对于储存进程的分布,提供了十分有利的条件。于是玩家数据可以储存于同一个集群中,可以不再跟游戏服务器绑定在一起,因为登陆的时侯便可依照玩家的ID去储存集群中定位想要存取的储存进程。

经典游戏服务器端架构概述 (2)

[图-分表分库]

以玩家ID作为分表分库是一个十分自然的选择,但是这些方案,往往还要在逻辑代码中,对玩家数据根据自定义的规则,做储存进程的选择。但是若果发觉这个分表分库的算法(原则)不符合需求,就须要把大量的数据做迁建。如上图是按玩家ID做奇偶规则分布至两个表中,一旦还要提高第三台服务器,数据储存的目的服务器编号就弄成了id%3,这样就须要把很多数据还要从原先的第一、二台数据库中拷贝下来,非常麻烦。

有的开发者会预先构建几十个表(如120个表=2x3x4x5),一开始是全部都置于一个服务器上,然后在提高数据库服务器的时侯,把对应的整个表迁建下来。这样能减少在迁建数据的时侯导致的复杂度,但还是还要迁建数据的。最后假如与推行的表还是放不下了,依然还是还要很复杂跟历时的再次拷贝数据。

NoSQL

在这些开发者绞尽脑汁忙活MySQL的时侯,NoSQL横空出世了。实际上在很早,目录型储存进程就在DNS等特定领域默默工作了。NoSQL系统最大的弊端正是关系型数据库最大的弱点——分布。

由于字段只有一个,因此外置的分布功能使用上去十分简便。而且游戏玩家数据,绝大多数的操作都是按照字段来读写的。“自古以来”游戏就有“SL大法”之称,其本质就是对存盘数据的简略读、写。在网游的初期版本MUD游戏时代,玩家存盘也是简略的置于硬碟的文件上,文件名就是玩家的ID。这些,都说明了游戏中的玩家数据,其读写都是有显著约束的——玩家ID。这跟NoSQL简直是天作之合。

经典游戏服务器端架构概述 (2)

[图-分布式缓存]

集成缓存的NoSQL

根据前面的描述,读者应当也会想起,如果数据库系统,或者叫持久化系统,自带了缓存,是否更好呢?这样确实是会更好的,而且非常是对于NOSQL系统来说,能以一些内部的算法策略,来增加后端逻辑开发的复杂程度。一般来说,我们还要对集成缓存的NOSQL系统有以下几方面的需求:首先是冷热数据手动交换,就是对于常用数据有算法来判断其冷热,然后换入至显存以增加存取性;其次是分布式扩容跟容灾功能,由于NOSQL是可以晓得数据的主关键字的,所以自然就可以手动的去界定数据所在的分段,从而可以自动化的追寻至目标储存位置来做操作;最后是数据导入功能,由于NOSQL支持的查询索引只好是字段,对于这些后台游戏操作来说是不够的,所以一定要才能四处至传统的SQL服务器起来。

在这方面,有太多产品都做过一定的尝试,比如在Redis或则MangoDB上做插件更改,或者以ORM系统封装MySQL以企图构造这些系统等等。

经典游戏服务器端架构概述 (2)

[图-开房间型游戏]

这类游戏服务器,玩家先登入“大厅服务器”,然后选择组队游戏的功能,服务器会通告参与的所有游戏客户端,新开一条连结至屋内服务器上,这样所有参与的用户能够在屋内服务器里进行游戏交互了。

由于“大厅服务器”只负责“组队”,所以其承载力会比详细的卧室服务器更高一些,但这儿仍旧会是功耗难题。所以通常我们还要尽量减低大厅服务器的功能,比如把登陆功能单独列进去、把玩家的订购物品商城功能也单独下来等等。最后,我们也可以直接想办法把“组队”功能也按组队逻辑做一定界定,比如不同的组队打法、副本类别、组队用户等级等等。

虽然这些模型早已可以对这些游戏做挺好的承载了,但是在大厅服务器这儿仍旧未能做到垂直扩充,原因是玩家的在线数据比较难分布至不同的服务进程起来,而且还带有大量复杂的数据查询逻辑。

专用聊天服务器

不管是MMORPG还是开房间类游戏,聊天时常都是网路游戏中一个重要的功能。而这个功能在“在线数量”很多,“聊天频道”很多的状况下,会给功耗带给特别大的挑战。在这些类别的页游跟少部份相机游戏上面,在线聊天并且是惟一的“带公共状态”的服务。

聊天服务处理点对点的聊天,还有群聊。用户可能会添加好友、建立好友群组等各类功能。这些功能,都是跟通常的游戏逻辑有一定区别的功能。这些功能常常并不是十分容易实现。很多游戏都期望推行类似腾讯QQ的游戏聊天功能,但是QQ是一整个公司在做开发,要用只是一个游戏团队弄成这样完整的功能,是有一定困难的。

因此游戏开发者们往往会专门的针对聊天功能来开发一系列的服务进程,以便能使游戏的聊天功能独立下来,做到负载分流跟代码重用的逻辑。很多网游系统,其聊天系统从客户端来说就是跟主游戏进程分开的。

聊天服务器的本质是对客户端数据做广播,从而使玩家可以交互,所以有很多游戏开发者也直接拿聊天服务器来做棋牌游戏的卧室服务器,或者反过来用。由于在游戏“分服”里面单独布署了聊天服务器,这类服务器也常常被拿来承当做“跨服打法”的进程。比如国战团队战、跨服副本等等。不管这种服务器最终叫哪些名子,实际上它们承当的主要功能还是广播,而且是运行玩家“二次登陆”的广播服务器。以至于之后,有部份游戏直接全部都用聊天服务器来取代原始的“游戏服务器”,这样就能实现一个叫“跳线”的功能,也就是玩家从一个“在线环境”跳至另外一个“在线环境”去。——这些都是对于“广播”功能的灵活利用。

经典游戏服务器端架构概述 (2)

[图-全服全线模型]

一. 服务进程的组织

静态配置

全服全线模型的本质是一个各类不同功能进程组成的分布式系统,因此这种进程间的关系是在维保布署其间应当关注的信息。最简略的处理方式,就是预先规划出详细的进程人数、以及进程布署的地理位置,然后通过一套配置文件来描述这个规划的内容。对于每位进程,需要配置列明每位进程的pid文件位置;内部通信用的地址,如IP+端口或则消息队列ID;启动跟停止脚本路径;日志路径等等……由于有了一套那样的配置文件,我们还可以撰写工具对所有的这种进程进行监控跟操作批量启停。

图说天下

×
二维码生成