大型网络游戏服务器的框架设计

服务器是用来处理高并发的请求,同时能够满足扩展的业务逻辑的需求,最重要的是满足三点:并发性,稳定性,扩展性。

经历过两款上线游戏产品,见识到了游戏行业的杂乱无章,虽然和传统软件行业相比,少了那么些规范,但是对个人能力要求还真不比传统软件行业低。

今天开始,陆续利用业余时间将自己设计的一个服务器的框架贴出来,也会包好一些基本的代码,也会用到一些开源库。从最基础的讲起,首先看看一个实时网络游戏服务器的框架:

目前市面上的游戏,总的来说分为两类:

1.弱联网类游戏,像手机上的卡牌类游戏(MT,Dota传奇等),大部分逻辑在客户端处理,不需要实时联网,这类游戏只有一个玩家,而且只有PVE模式,就是打游戏中的机器人(AI),不存在玩家与玩家的实时交互。例如一场副本打斗,只有在开始和结束,才会连接服务器,请求获取或者存储数据,打斗过程由客户端计算完成,最后将战斗结果提交服务器就行了。

2.强联网类游戏,典型的就是MMORPG或者MMARPG的类型的游戏,一般常见于端游或者页游,也包含手游。在一个地图中,同时有很多玩家,任何一个玩家的状态或者属性发生变化,服务器就需要实时更新游戏中角色的状态,并且通知到周围的玩家。例如在副本中,一个玩家释放技能,攻击范围,伤害计算这些逻辑都是服务器来完成的,而客户端只需要负责特效的显示,这个过程中需要实时的数据交互。

显然,第2种,MMORPG类游戏需要服务器做更多的事情,对服务器的运算要求更高,实时性要求更高,自然实现起来更复杂。

一个大型的网落游戏服务器应该包含几个模块:网络通讯,业务逻辑,数据存储,守护监控(不是必须),其中业务逻辑可能根据具体需要,又划分为好几个子模块。

这里说的模块可以指一个进程,或者一个线程方式存在,本质上就是一些类的封装。

对于服务器的并发性,要么采用单进程多线程,要么采用多进程单线程的方式,说说两种方式的优缺点:

一、单进程多线程的服务器设计模式,只有一个进程,但一个进程包好多个线程:

网络通讯层,业务逻辑,数据存储,分别在独立的线程中,无守护进程。

优点:

1.数据共享和交换方便,使用全局变量或者单例就可以,数据存储方便。

2.单进程,服务器框架结构相对简单,编码容易。

缺点:

1.所有功能只能在单个物理服务器上,不能做成分布式。

2.不方便监控各个线程状态,容易死锁

3.一个线程出错,例如内存非法访问,栈空间被破坏,那么服务器进程就退出,所有玩家掉线,影响大。

二、多进程单线程的服务器设计模式,多个进程,每个进程只有一个线程:

网路通讯,业务逻辑,数据存储,守护进程,分别在不同的进程。

优点:

1.各个进程可以分布在不同的物理服务器上,可以做成分布式的服务器框架,例如可以将数据存储单独放到一个物理服务器上,供几个区的服务器使用。将网络通讯进程独立出来,甚至可以做成导向服务器,实现跨服战。

2.可以通过守护进程监控其它进程状态,例如有进程死掉,马上重启该进程,或者某个进程cpu使用率接近100%(基本可以判断是某个逻辑死循环了), 强制kill掉该进程,然后重启。

3.单个服务器进程异常退出,只要不是网络通讯进程(一般这个都会比较稳定,没什么逻辑),那么就可以及时被守护进程重启,不会造成玩家掉线,只会造成在1-2秒内,某个逻辑功能无法使用,甚至玩家都感觉不到。

4.服务器通过共享内存进行数据交换,那么如果其中一个服务器死掉,数据还在,可以保护用户数据(当然多线程也可以使用共享内存)。

5.并发性相对多线程要高点。

缺点:

1.不方便使用互斥锁,因为进程切换的时间片远远于线程切换,对于一个高并发服务器是无法允许这么高时间片的切换代价的。因此必须设计好服务器的框架,尽量避开使用锁机制,但要保证数据不出错。

2.多进程编程,在各个进程间会有很多通讯,跨服务器进程的异步消息较多,会让服务器的编码难度加大。

下面先按照一个游戏的功能,将服务器的功能分块框架画出来:

大型网络游戏服务器的框架设计

以上是一个游戏服务器最基础的功能框架图,接下来要做的就是设计服务器的框架了。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwpyjx.html