注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Code@Pig Home

喜欢背着一袋Code傻笑的Pig .. 忧美.欢笑.记忆.忘却 .之. 角落

 
 
 

日志

 
 

[网游设计] 服务器构架小论  

2009-06-07 12:04:34|  分类: 网游设计 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

单服结构
---------------------------------
[client01] <--\
[client02] <---> [NetProcess] <---> [LogicProcess] <---> [DBProcess] <=> [DB/MySQL]
       ...     <--/
---------------------------------
结构简单,所有逻辑都放在 [LogicProcess],包括世界聊天、战斗、帮派等等,一切一切。
[NetProcess]只负责收/发、加/解密、fd管理、转发到[LogicProcess]等事情。
如果使用数据库,一般还会有个[DBProcess],专门处理数据库相关的逻辑。直接用文本文件作为数据存储,其实也不来,和数据库比起来,各有优缺点吧,比如:MudOS 就是啥都是用文件来存储的。
甚至log也可以专门独立一个进程or线程来负责。中心思想就是让[LogicProcess]尽量不要block在某个系统调用,能调动更多的cpu时间来做计算。
为何分为几个进程?因为目前的小型服务器都是4核,不用多进程,太浪费了。
单服结构,一般这几个进程都跑在一台物理机器上,比较适合“回合制”游戏,“即时制”一般 [LogicProcess] 运算量太大,负载不过来。


典型多服结构
---------------------------------
[client01] <--\                                         /--> [LogicProcess01] <--\
[client02] <---> [NetProcess/Manager] <---> [LogicProcess02] <---> [DBProcess] <=> [DB/MySQL]
       ...     <--/                                         \-->             ...              <--/
---------------------------------
就是上面单服结构的改良版,把 [LogicProcess] 分离出来了。不过因为多个 [LogicProcess] 只见需要协调,所以 [NetProcess] 还需要多支持些中转的逻辑。
多个 [LogicProcess] 可以放到不同的物理机器上,以分担负载。每个 [LogicProcess] 具体做些啥内容,可以根据具体的游戏逻辑来划分。
比如:休闲游戏,一个 [LogicProcess] 可以管理上百个房间;而“即时制”可以放每个 [LogicProcess] 管理一个场景。
也有很多棒子的游戏把不同的 [LogicProcess] 作为独立的游戏 channel,你看到很多游戏有“频道1”、“频道2”就是这种,除了聊天/人物数据,频道只见不共享其他任何东西。


星型多服结构
---------------------------------
                                                              /--> [DBProcess] <==> [DB/MySQL]
[client01] <--\                                         /--> [LogicProcess01]
[client02] <---> [NetProcess/Manager] <---> [LogicProcess02]
      ...      <--/                                         \-->     ...
---------------------------------
再进一步简化上面的多服结构,减少两个进程间的交互,就会进化为如此的星状结构。让所有的事情都是 [Manager] 来转发。可以有效减少逻辑层面上的复杂度。


蜘蛛网多服结构
---------------------------------
地图服务器1(区域服务器)\   
              .......                       | <--> 世界服务器  <--> (帐号服务器 &  角色服务器) <--> \
              .......                       | <--> 邮件服务器  <--------------------------------------------> | <--> DB Server
地图服务器N                        / <--> 聊天服务器  <--------------------------------------------> /
---------------------------------
客户端连接对应的地图服务器(区域服务器)。
优点:每一个服务器只负责自己的简单功能,符合KISS原则,同时一个地图服务器down掉不会影响其他地图服务器,而且可以把压力比较大(计算比较大的地图服务器)分布在不同的物理机器上,简单的负载平衡。
缺点:通信非常的繁琐,比如:商城举例,首先客户端发送到区域服务器,区域服务器计算后到世界服务器,世界服务器到帐号服务器,帐号服务器到世界服务器,世界服务器到区域服务器,区域服务器到邮件服务器,然后邮件服务器到区域服务器,区域服务器到客户端。
蜘蛛网其实就是去掉了 Manager 这一层,让有联系的进程之间都直接通讯,这会导致多个进程之间的关系比较复杂,写玩法逻辑的时候十分麻烦,不利于debug。不推荐使用。上面的结构图只是蜘蛛网结构的一种特例,根据游戏逻辑的不同,都可能分为不同的服务器(进程),但特点都是进程间的交互过多。


负载均衡/纯分布式多服务器
---------------------------------
待稿
---------------------------------
Erlang? DarkStar?

 

 

----------------------
:-) 感谢拉拉同学贡献蜘蛛网结构图。

  评论这张
 
阅读(1471)| 评论(3)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017