游戏服务器架构简介

  游戏的架构设计非常重要,好的架构代码清晰,责任明确,扩展性强,易于调试。这些会为我们的开发省下不少时间,对于游戏服务器的架构设计,我们首先要了解游戏的服务器架构都有什么组成?一款游戏到上线,需要具备哪些功能?游戏架构本身代表是一个体系,它包括:

1.系统初始化

系统初始化是在没有客户端链接的时候,服务器启动时所需要做的工作。基本上就是配置文件的读取,初始化系统参数

但是需要注意一些问题:
系统初始化需要的参数配置在哪儿,是配置在本地服务器还是配置在数据库。

服务器启动的时候去数据库取;

配置的修改需不需要重启服务器等;

2.游戏逻辑

代码必须分层,不然后期要修改需求,比较麻烦,Netty是目前比较流行的NIO框架。

协议层,也叫后台交互层,它主要负责前台交互协议的解析和返回数据。在这一层基本上没有什么业务逻辑实现。与前台交互的数据都在这一层开始,也在这一层终止。比如用Netty框架,那么Netty的Ctx只能出现在这一层,他不能出现到游戏业务逻辑代码的实现中,接收到客户端的请求,在这一层把需要的参数解析出来,再把参数传到业务逻辑方法中,业务逻辑方法处理完后,把要返回给客户端的数据再返回到这一层,在这一层组织数据,返回给客户端,这样就可以把业务逻辑和网络层分离,业务逻辑只关心业务实现,而且也方便对业务逻辑进行单元测试。

业务逻辑层,这里处理真正的游戏逻辑,该计算价格计算价格,该通关的通关,该计时的计时。该保存数据的保存数据。但是这一层不直接操作缓存或者数据库,只是处理游戏逻辑计算。因为业务逻辑层是整个游戏时间的处理核心,所以他的处理是否正确直接决定游戏的正确性。所以这一层的代码要尽量使用面向对象的方法去实现。不要出现重复代码或相似的功能进行复制粘贴

这样修改起来十分不便,可能是修改了某一处,而忘记修改另外同样的代码。还要考虑每个方法都是可测试的,一个方法的行数最好不要超过一百行。另外可以多爱看设计模式的书,它可以帮助我们设计出灵活,整洁的代码。

3.数据库系统

数据库是存储数据的核心,但是游戏数据在存储到数据库的时候会经过网络和磁盘的IO,它·的访问速度相对于内存来说是很慢的。一般来说每次访问数据库都要和数据库建立链接,访问完成之后,为了节省数据库的链接资源,再把链接断开。

但是这种链接无形中又为服务器增加额开销,在大量的数据访问时,可能会更慢,而游戏又是要求低时延的,这时该怎么办?

有一个数据库连接池,即把访问数据库的链接放到一个地方管理,用完不断开,用的时候去拿,用完再放回去。这样不用每次都建立新的链接了。

但是如果要我们自己去实现一套连接池管理组建的话,需要时间不说,对技术的把控又是一个考验,还要经过测试等等,幸好互联网开源的今天,有一些先成的可以使用,这里推荐Mybatis,即实现了代码与SQL的分离,又有足够的SQL编写的灵活性,是一个不错的选择。

4.缓存系统

游戏中,客户端与服务器的交互就是要求低时延的,延迟越低,用户体验越好。像之前说过的一样,低时延就是要求服务器处理业务尽量的快,客户端一个请求过来,要在最短的时间内相应结果,最低不得超过500ms,因为加上来回的网络传输消耗,基本上就是600ms-700ms,再长就会觉得卡。

如果直接从数据库中取数据,处理完之后再·存回数据库的话,这个性能是跟不上的。在服务器,数据在内存中处理是最快的,所以我们要把一部分常用的数据提前加载到内存中。比如说游戏数据配置表,经常登录的玩家数据等。这样在处理业务时,就不用走数据库了,直接从内存中取就可以了,速度更快。

游戏中常见的缓存:

1.直接把数据存储在JVM或服务器内存中

2.使用第三方缓存工具,推荐Redis.

5.游戏日志

日志一定要记录详细。它是玩家在整个游戏中的行为记录,有了这个记录,我们就可以分析玩家的行为,查找游戏的不足,在处理玩家在游戏中的问题时·,日志也是一个良好的凭证和快速处理方式。

在游戏中,日志分为:

1.系统日志,主要记录服务器的系统情况。比如:数据库能否正常链接,服务器是否正常启动,数据是否正常加载;

2.玩家行为日志,比如玩家发送了什么请求,得到了什么物品,消费了多少货币等等。

3.统计日志,这种日志是对游戏中所有玩家某种行为的一种统计,根据这个统计来分析大部分玩家的行为,得出一些共性或不同之处,以方法运营做不同的活动吸引用户消费。

在架构设计中,日志记录一定要作为一种强制行为,因为如果不强制的话,可能由于某种原因某个功能忘记加日志了,那么当这个功能出问题了,或者运营跟我们要这个功能的一些数据库,就GG了,又得加需求,改代码了。日志一定要设计一种良好的格式。日志记录的数据要容易读取,分解。日志行为可以用枚举描述,在功能最后的处理方法里面加上这个枚举作为参数,这样不管谁在调用这个方法时,都要去加参数描述。

6.游戏管理工具

俗话说,工欲善其事,必先利其器。游戏管理工具是对游戏运行种的一系列问题处理的一种工具。它不仅是给开发人员用,大多是给运营是哟个。游戏上线后,我们需要针对线上的问题进行不同的处理。不可能把所有问题都让程序员去处理,于是程序员们想到了一个办法,做个工具,爱谁谁。

这个管理工具是一个不断增涨的系统,因为它很多时候是伴随着游戏种遇到的问题而实现的。

但是根据经验,有些是必须有的,比如:

服务器管理,主要负责服务器的开启,关闭,服务器配置信息,玩家信息查询;

玩家管理,比如踢人,封号;

统计查询,玩家行为日志查询,统计查询,次留率查询,邮件服务,修改玩家数据等。

根据游戏的不同需求,凡是可以通过工具实现的,都做到游戏管理工具里面。它是针对所有服务器的管理。

一个好的,全的游戏管理工具,可以提高游戏运营中遇到问题处理的效率,为玩家提供更好的服务。

7.公共服务组件

公共服务组件是为游戏运行中提供公共的服务。例如:

充值服务器,我们没必要一个服用一个充值,而且也不能对外提供多个充值服务器地址,和第三方公司对接,他们绝对不干。

还有运营搞活动时的礼包码;

还有注册用户的管理,玩家一个注册账号可以进不同的区等。

这些都是对所有区服提供的服务,所以要单独做,与游戏逻辑分开,这样方便管理,部署和负载均衡。

还有SDK登录验证,现在手游比较多,与渠道对接里要进行验证,这往往是很多http请求,速度慢,所以这个也要拿出来单独做,不要在游戏逻辑中去验证,因为网络IO的访问时间是不可控制的,http是阻塞的请求。

所以,综上来看,一个游戏服务器起码有几个大的功能模块:

游戏逻辑工程;

日志处理工程;

充值工程;

游戏管理工具工程;

用户登录工程;

公共活动工程;

根据游戏的不同需要,可能还有其他的。所在架构的设计中,一定要考虑到系统的分布式部署,,尽量把公共的功能拆出来做,这样可以增强系统的可扩展性。

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
C++棋牌游戏服务器架构通常包括以下几个主要组件: 1. 游戏逻辑层:负责处理游戏规则、游戏状态的更新和管理,以及处理玩家的操作请求。这一层通常由C++编,包括游戏逻辑的实现和相关算法。 2. 网络通信层:负责处理客户端和服务器之间的网络通信。这一层通常使用TCP或UDP协议进行数据传输,并提供网络连接的建立、断开、数据收发等功能。常用的C++网络库有Boost.Asio、libevent等。 3. 数据库层:负责存储和管理游戏数据,如玩家信息、游戏记录等。这一层通常使用关系型数据库(如MySQL)或NoSQL数据库(如Redis)来存储数据,并提供相应的读接口。 4. 多线程/多进程管理:为了提高服务器的并发处理能力,可以采用多线程或多进程的方式来处理客户端请求。多线程可以使用C++标准库中的std::thread或第三方库如pthread来实现,多进程可以使用fork或者第三方库如boost.process来实现。 5. 负载均衡与高可用性:为了提高服务器的性能和可用性,可以采用负载均衡技术将客户端请求分发到多台服务器上进行处理,同时可以使用集群和备份机制来实现高可用性。常用的负载均衡软件有Nginx、HAProxy等。 6. 安全认证与防作弊:为了保证游戏的公平性和安全性,可以在服务器端进行安全认证和防作弊处理。常见的技术包括数据加密、防止外挂和作弊程序的检测与防御等。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值