我是靠谱客的博主 淡淡草莓,最近开发中收集的这篇文章主要介绍游戏架构设计的一些整理四.正文网络通讯,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

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

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

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

一、单进程多线程的服务器设计模式

只有一个进程,但一个进程包好多个线程:

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

优点:

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

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

缺点:

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

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

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

二、多进程单线程的服务器设计模式

多个进程,每个进程只有一个线程:

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

优点:

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

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

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

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

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

缺点:

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

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

三、游戏框架

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

  1. 早期的MMORPG服务器结构

Client<->GameServer<->DB 所有业务,数据集中处理


GameServe1

Client | DB

玩家不断增多->分线->程序自动或玩家手动选择进入

优点:

缺点:

解决:多网关技术。顾名思义,“多网关” 就是同时存在多个网关服务器,比如一组服务器可以配置三台GameGme。当负载较大时,可以通过增加网关服务器来增加网关的总体通讯流量,当一台网关服务器宕机时,它只会影响连接到本服务器的客户端,其它客户端不会受到任何影响。

DCServer:数据中心服务器。主要的功能是缓存玩家角色数据,保证角色数据能快速的读取和保存

改进:将网关服务器细化为LogingateServer和多个GameGateServer.

5. 按业务分离式集群

改进:甚至可以将登陆服务器细化拆分建角色,选择角色服务器

下图中每个方框表示一个独立的进程APP组件,每个服务进程如果发生宕机会影响部分用户,整体服务但不会全部中断。在宕机进程重启后,又可以并入整体,全部服务得以继续。

7.另一个架构图

四.正文网络通讯

1.网络协议

根据游戏类型 实时性要求/是否允许丢包 来决定 TCP/UDP协议

a.TCP:面向连接,可靠,保证顺序,慢,有延迟

b.长连接/短连接

2.IO模型

Unix5中io模型

IO分两个阶段:

根据这2点IO类型可以分成:

3.线程阻塞的原因:

1.Thread.sleep(),线程放弃CPU,睡眠N秒,然后恢复运行

4.阻塞/非阻塞/同步/异步

同步/异步关注的是消息如何通知的机制。而阻塞和非阻塞关注的是处理消息。是两组完全不同的概念。

5.几个常用概念

Select Poll

Reactor

Proactor

两个模式的相同点,都是对某个IO事件的事件通知(即告诉某个模块,这个IO操作可以进行或已经完成)。在结构上,两者也有相同点:demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步),然后当条件满足时,就回调handler。

6.网络通讯框架

TCP Server框架:

7.消息编码协议

AMF/JSON/XML/自定义/ProtocolBuffer

无论是做何种网络应用,必须要解决的问题之一就是应用层从字节流中拆分出消息的问题,也就是对于 TCP 这种字节流协议,接收方应用层能够从字节流中识别发送方传输的消息.

|separator | header | body |

8. 粘包:

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。

解决措施:

分包算法思路:

在单位设计上必须冲头到尾贯彻面向对象的“继承”观念

地图寻路

寻路的问题在于自然的移动,追着一个单位打,或者进入射程中停下来,比起如何自然的经过一个单位打,成为了一个,为什么你要在A站或者B站坐公交的问题,Why,如何才能符合逻辑的设计—敌人进攻的单位,这个AI,不但是策略的问题,还是行为的问题,所以,将敌人的最终目标确定在哪里呢?

回答:AI 和 行为控制模块要分成两个模块来做

行为控制模块复制地图上所有单位的移动、攻击等动作,目标、目的的指示;

如果有必要 还需要一个监控模块,监控单位的状态改变

AI ,就是上面写过的 Why , 我要在A站乘车 还是B站乘车的逻辑,我是优先攻击单位,还是优先攻击建筑物的逻辑。。。本虎还没想明白,这是一个逻辑怪圈。。。。

最后

以上就是淡淡草莓为你收集整理的游戏架构设计的一些整理四.正文网络通讯的全部内容,希望文章能够帮你解决游戏架构设计的一些整理四.正文网络通讯所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(58)

评论列表共有 0 条评论

立即
投稿
返回
顶部