Archives

帖子来自 xiaohyy RSS

游戏服务器的架构设计

作者： xiaohyy (2 篇文章) 日期： 一月 5, 2010 在 6:19 下午
评论 (24)

游戏服务器的设计是一项颇有挑战性的工作，游戏服务器的发展也由以前的单服结构转变为多服机构，甚至出现了bigworld引擎的分布式解决方案，最近了解到Unreal的服务器解决方案atlas也是基于集群的方式。 负载均衡是一个很复杂的课题，这里暂不谈bigworld和atlas的这类服务器的设计，更多的是基于功能和场景划分服务器结构。 首先说一下思路，服务器划分基于以下原则： 1：分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器 2：在同一服务器架构下的不同游戏，应尽可能的复用某些服务器（进程级别的复用） 3：以多线程并发的编程方式适应多核处理器。 4：宁可在服务器之间多复制数据，也要保持清晰的数据流向 5：主要按照场景划分进程，若需按功能划分，必须保持整个逻辑足够的简单，并满足以上1，2点 服务器结构图： 各个服务器的简要说明： Gateway：应用网关，主要用于保持和client的连接，该服务器需要2种IO，对client采用高并发连接，低吞吐量的网络模型，如IOCP等，对服务器采用高吞吐量连接，如阻塞或异步IO。 网关主要有以下用途： 1：分担了网络IO资源 2：同时，也分担了网络消息包的加解密，压缩解压等cpu密集的操作。 3：隔离了client和内部服务器组，对client来说，它只需要知道网关的相关信息即可（ip和port）。 4：client由于一直和网关保持常连接，所以切换场景服务器等操作对client来说是透明的。 5：维护玩家登录状态 World Server 是一个控制中心，它负责把各种计算资源分布到各个服务器 它具有以下职责： 1：管理和维护多个Scene Server 2：管理和维护多个功能服务器，主要是同步数据到功能服务器 3：复杂转发其他服务器和Gateway之间的数据 4：实现其他需要跨场景的功能，如组队，聊天，帮派等 Phys Server 主要用于玩家移动，碰撞等检测 所有玩家的移动类操作都在该服务器上做检查，所以该服务器本身具备所有地图的地形等相关信息。具体检查过程是这样的：首先，Worldserver收到一个移动信息，WorldServer收到后向Phys Server请求检查，Phys Server检查成功后再返回给world Server，然后world server传递给相应的Scene ...

继续 ›

分类: 博客征文专栏, 游戏
标签：

关于多核的发展对网络游戏设计影响的一些思考

作者： xiaohyy (2 篇文章) 日期： 十二月 15, 2009 在 6:04 下午
评论 (8)

早在几年前，Herb sutter就发表了《免费午餐已经结束，软件历史性的向并发靠拢》一文，引起了业内很大的反应，现在双核早已普及，09年应该是国内普及4核的一年。 Erlang这种老古董也因为多核的发展而逐渐热起来，网上关于普通程序员是否需要掌握多核编程技术也有很多争论，不论大家观点是否正确，至少多核相关技术引起了开发人员的注意。 我是做游戏服务器开发的，公司的老游戏的服务器机器配置一般是带超线程的双至强cpu，逻辑上是4个cpu（关于超线程的性能提升姑且不谈），照理说，游戏服务器早就应该是多线程的设计，但是据我了解，国内大部分的游戏服务器游戏逻辑部分都是单线程的，即存在所谓主线程的说法，单线程的设计是基于以下几个因素（以3000个玩家同时在线为列）： 1：大概有20-30%的cpu被网络IO占用，网络层很容易用多线程实现 2：可通过架构上的设计剥离数据访问，IO等容易采用多线程实现的部分，剩下的占用cpu密集的操作就是所谓的主线程 3：多线程的设计会导致开发周期延长，设计变得更加复杂，可维护性降低。 3：最关键的一点：多线程带来的复杂性和bug数量，频繁的宕机回档是任何游戏都不能忍受的。 4：再来分析一下以前的双cpu服务器采用单线程的方式带来的性能损失（超线程带来的性能极为有限，暂不做讨论），粗略的来看，网络IO部分可由2个 cpu平均分摊，再抛开一些锁和缓存同步带来的开销及一些其他软件（如监控，统计），损失大概30%-40%的性能，损失的性能和稳定性及开发周期等之间权衡，当然选择单线程的设计。 再来看如果现在启动一个新项目，对性能的考虑又该如何。首先做2个假设，1：项目周期为2年，即2年后游戏公测，或大规模内测。2：2年后服务器主流配置为16核，低端配置8核。如果仍采用单线程的服务器设计，以16核的cpu计算，损失的性能最少会达到800%，这个时候可能有人会说，我把所有的服务器放到一台机器上，甚至数据库也放过来，这样就能充分的利用到所有的cpu资源。不错，我承认这样基本上完全能利用cpu资源，但这不是游戏的核心内容，以前只能支持3000个玩家，10000个激活npc的服务器，现在仍然如此。硬件在发展，玩家的体验需求也在发展，就像网络的带宽提升了100倍，我们仍然只能看到断断续续的视频一样无法接受。说了这么多，也无非是得出一个结论：多核的发展在游戏开发当中必须引起重视。 那么，又如何利用多核资源呢？我总结了一下，大概有以下几种做法： 1：多进程设计，这是云风走的路线 2：挑战逻辑复杂性，设计良好的线程模型和数据结构 3：采用intel openmp 和 tbb 等技术 下面就以上几种设计谈谈个人看法： 多进程的设计很符合unix哲学，很kiss，难点在于进程的管理，通信，协调。优点是易于维护，调试，结构清晰。缺点是进程的管理麻烦，有一些效率损失，最重要的一点是，多进程设计可能仍然无法有效的在多核cpu上提高效率，根据80-20法则，可能80%的cpu消耗在20%的进程内，如果根据功能模块划分进程，即使设计良好的数据流水线，在20%的进程内也是需要做并行计算的。 第2中做法风险太大，需要多年的游戏设计经验和很好很强大的设计能力。 第3中做法比较折中，分析出占用80%cpu的那20%的代码，并行化。当然说起来比做起来容易，这种方式仍需要良好的数据结构的设计。举个例子，同时对1000个怪物做寻路操作，这种只读的操作是无需加锁很容易并行化。 结合以上几种设计，我认为最合适的做法是采用较粗粒度的进程，结合tbb等库在cpu密集操作的进程内部做并行化 是一种相对较好的设计 写的比较乱，有些地方不够严谨，以上的想法只是提供一种思路，还并未在实践中运用 ：） ps：tbb中有pipeline框架，可在进程内部方便的提供流水线机制

继续 ›

分类: 博客征文专栏