前一年写的多的是web server,最近可能要开始写game server了,所以也是认真考虑了下game server的各个方面了,本文主要是从概念上探讨实现一个高性能、可伸缩game server的各个方面,最终也会给出一个demo,两者相互支撑,算是行文框架吧!

一般而言,现在写的最多的server也就两个,web server & game servers,而这两者的区别也正是写好这两种server 的关键点。

  • web server 不用保存连接,而game server需要
  • web server 是 stateless,而game server是stateful
  • web server 消息以req-rep模式为主,game server broadcast消息占很大比重

相对来说,statelessstateful 是两种server不同的中心点,web server 是无状态的,所以前一个请求和后一个请求之间是没有关联的,request所做的更改一般都会体现在数据库这一层,所以可以很方便的做负载均衡,伸缩也很方便,简单的添加服务器即可;而game server的特点也正是体现在stateful上,前一个请求和后一个请求是有关系的,对于最简单的mmo,玩家进入了一个副本,那么以后的命令就和玩家在这个副本中有关了,玩家上一个请求加了10点血,下一个请求必须知道,解决这个问题的办法有两种,一是把所以玩家的state即时同步到数据库,那么在逻辑server上就不用再保存用户的state了,但是这个办法明显不适合稍微大一点的游戏,操作数据库的延迟基本不可能忍受;二是在server保存用户的session,session是在内存中的,在玩家完成某一阶段的事件后将session的数据flush到db中,在玩家意外断线的时候保存session即可,那么着引起的问题就是,玩家session数据只会保存在一台server上,所以关于这个玩家的所有请求都必须route到这台server,这就不像web server那么简单的增减服务器就可以伸缩了。

而消息模式也是两种server不同的极大关键点,web server中基本都是简单的req-rep模式,而game server中普遍存在的broadcast模式则需要我们思考消息的处理模式。例如在一个游戏中,同一个房间的人发出一个状态更改信息,那么我们要通知房间内的其他人,而这些人可能连接在不同的服务器上,那么这个时候我们的消息应该怎么发送?

基本上,完成一个game server的重点就在于我们如何处理stateful和broadcast这两个问题,那么我们先直接提出一个可行的方案。

image

其中connector主要接收用户请求,保持用户连接,一般而言在connector中不处理具体事务,它会将受到的数据forward到后端;logic server处理具体的游戏逻辑,并将返回值reply给connector,由connector发给用户,同时它也会broadcast信息给connector。

烂尾了…… 以后再写吧!可运行的框架代码