系统分析与集成.doc

硕士研究生毕业论文 MMOG环境下服务端通用运行支撑平台研究与实现分类号 TP31 密级 公开 UDC 编号 硕士研究生学位论文题 目 MMOG环境下服务端通用运行支撑平台的研究与实现学院（所、中心） 软件学院 专业名称 系统分析与集成 研究生姓名 廖赟 学号 1200600983 导师姓名 梁志宏 职称 研究员 二OO九 年 四 月66声 明本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得云南大学或其他教育机构的学位或证明而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。研究生签名： 日 期： 论文使用和授权说明本人完全了解云南大学有关保留、使用学位论文的规定，即：学校有权保留并向国家有关部门或机构送交学位论文和论文电子版；允许论文被查阅或借阅；学校可以公布论文的全部或部分内容，可以采用影印、缩印或其他复制手段保存论文；授权学校将学位论文的全部或部分内容编入有关数据库进行检索。 （保密的论文在解密后应遵循此规定）研究生签名： 导师签名： 日 期： 摘要多人在线游戏，作为一个新兴产业在全球迅速发展着，但是，在面对如此巨大的市场的同时，我国网络游戏市场却同样面临着不少问题。其中一个重要方面就是游戏服务器的性能及稳定性不高而导致的服务器质量问题。针对如此现状，本文着重研究与设计多人在线游戏环境下服务端通用运行支撑平台，即通过对多人在线游戏服务端开发需要的各种服务器资源及现阶段存在的问题进行分类总结提取并设计封装成服务端通用运行支撑平台，使得网络游戏服务端开发人员利用该平台更容易开发出高效稳定的多人在线游戏。论文首先以一个国内知名的多人在线休息游戏平台为基础，介绍了其服务端网络体系结构和个服务器的基本功能及实际运行中存在的各种问题。其次，在此基础上分析了造成运行中问题的原因并给出了相应的解决办法，总结提出了服务端通用运行支撑平台需要使用基本技术及相关服务。第三，给出了平台设计的总体框架及各个子系统的详细设计过程。最后在基于平台的基础上重构了该多人在线休息游戏平台，并进行了相应的性能及稳定性分析。关键字：MMOG；内存池；网络编程模型；完成端口ABSTRACTAs an emerging industry, massively multiplayer online game is developing rapidly in the whole world. But, when facing so giant chance,Our domestic net game market still confront with many problems. The most important problem is low quality of game service due to the lower performance and poor stability of game serer.Face to this problem, the article is focus on developing general run time platform of MMOG server entertainment. The developers can easy to develop stability and high performance MMOG servers.The article first show a well-known game platform in China, introduced its net work architecture and functions of each server of the game platform, then narrate the problems which were emerge in practice.Based on this game platform, we analyse the reason of these problems and give solutions for each problem then calculate basic servics and technoloies whichi will be uesed in our run time platform. Thirdly,we give the architecture of the run time platform and the design of each Subsystem. Finally, Reconstruction the game platform with our run time platform and give performance and stability analyse in new Environment.Keywords:MMOG; Memory Pool; Net Programing model; Completion Port目录摘要3ABSTRACT4第一章 引言51.1研究目的及问题概述51.2研究范围及创新61.3论文结构7第二章 MMOG服务器架构分析72.1休息游戏平台背景介绍82.2 MMOG服务器架构实例分析82.3平台运行过程中的问题10第三章 问题分析及解决思路103.1稳定性问题分析113.1.2游戏状态管理问题143.1.3服务失效管理问题173.1.4客户连接管理问题173.2效率问题分析193.2.1网络编程模型的选择19第四章 服务端通用运行支持平台设计254.1总体设计254.2网络通信服务264.2.1 IOCP开发难点及要点及相关处理算法264.2.1网络通信服模块务体系结构384.1.3函数接口及关键数据结构设计394.1.4通信协议设计404.2内存管理服务设计424.2.1 内存池的数据结构424.2.2内存池算法分析434.3连接管理服务设计464.3.1连接管理服务带来的问题474.3.2“服务名称”与“玩家ID”474.3.3通信过程协议设计474.3.4数据结构级接口设计544.4游戏状态备份及恢复服务设计554.4.1游戏状态备份554.4.1、游戏状态恢复服务564.4.3、备份及回复接口说明574.5、全局监控管理服务设计58第五章 平台的实际应用及性能分析595.1、重构MMOG服务端网络体系结构595.2、性能与稳定性分析605.2.1、从技术层面分析605.2.2、服务配置层面分析605.2.3、从网络体系结构层面分析61第六章 总结和展望62致 谢64第一章 引言1.1研究目的及问题概述在中国网络游戏产业是一个新兴的朝阳产业，经历了上个世纪末的初期形成期阶段，及近几年的快速发展，现在中国的网络游戏产业处在成长期，并快速走向成熟期的阶段。在中国整个网络经济的发展过程中从无到有，发展到目前成为中国网络经济的重要组成部分。2007年中国网络游戏市场规模为128亿元，同比增长66.7%。2007年中国网络游戏用户达到4800万，环比增长17.1%。网络游戏的实时在线人数同时也在节节攀升，以魔兽世界为例，2005年魔兽世界刚刚进入中国大陆市场时最高实时在线人数为约为50万人，而到2008年，最高实时在线人数已经突破100万人，增长超过100%。伴随着网络游戏用户数的不断增加，玩家对服务质量的投诉也越发的平凡，其中针对游戏服务器问题的投诉占有不小的比重。据统计，2008年上半年，关于网游服务器问题的投诉占了25.30%，服务器卡、经常掉线，不按时开放服务器等，是产生此类投诉的主要原因。是什么原因导致服务器问题一直存在呢？1、 服务器性能低下，无法承担过高的并发访问量，并且这种性能低下的问题无法通过提升硬件性能或是提高网络带宽的方式解决。2、 服务器稳定性差无法保证服务器稳定长期的高效运行。3、 虽然有很多成熟的通信中间件产品可以使用但是对整个游戏项目来说缺乏总体框架上的指导作用，无法从整体上保证整个平台的高效率和稳定性。1.2研究范围及创新MMOG是多人在线游戏的缩写，多人在线游戏的种类繁多，不同游戏在服务器端的实现方式也各不相同。本文将通过分析某一休闲类游戏平台为例，找到现有MMOG在服务器端开发上可能存在的问题，并给出响应解决方案。本文讨论的重点之一是如何提高MMOG服务器执行效率，效率的提高可以通过改善硬件配置或改进算法来达到，本文将只关注如何通过算法的改进来提高系统性能。提高系统的容错性是本文讨论的另一重点，系统的容错性通常包括硬件及软件两个层面，随着计算机硬件技术的发展，计算机硬件造成的系统故障已经非常少，同时对硬件的故障处理已经有非常多的完善的解决方案。从近年来的各种统计数据我们可以看出，导致系统失效的绝大多数的系统故障均是由软件导致，因此本文将不考虑硬件容错，而只讨论软件层面的容错处理。我们知道MMOG不可能由一台或少数几台服务器构成，MMOG是一个分布式计算环境，其中包含有大量的并发运行的进程，这些进程可能物理上在同一台机器上，但绝大多数情况存在于物理上相距甚远的由网络互相连接的计算机构成。因此，对于这个系统的稳定、高效性来说绝不是一个设计良好的中间件所能完成的任务，而必须从系统整体出发进行考虑。因此，本文将以MMOG服务器端开发为核心，从整体系统的高度出发，设计一种以先进的通信技术为基础、其它基础服务为辅助，并能够对MMOG服务器端网络体系结构设计有一定指导作用的服务端运行支撑平台。1.3论文结构第一章，引言。介绍课题研究背景及研究内容，阐述了平台的设计目标。第二章，MMOG服务器架构分析。本章将以国内某一知名休闲游戏平台为例，分析其服务器架构，及其在实际运行中存在的问题。第三章，问题分析及解决思路。本章在第二章的基础之上深入分析造成各种问题的原因并给出相应解决方案。第四章， 平台设计。依次给出了平台设计的实现步骤，包括实现目标、体系结构，最后是模块划分实现。第五章，平台的实际应用及性能分析。本章在本文设计的运行支撑平台的基础之上，重构了第二章说讨论的MMOG服务端，并给出响应性能及稳定性分析。第六章，总结和展望。对所做工作进行了总结，并对未来的工作进行展望。第二章 MMOG服务器架构分析在本章中，我们将以某一国内知名休闲游戏平台为例，分析探讨 MMOG服务器的基本架构。描述这个游戏平台在实际运行中的主要问题。2.1休息游戏平台背景介绍该游戏平台在国内运营时间已经超过两年，提供的游戏类型主要是棋牌一类的休闲型小游戏，其服务器主要分布在上海、江苏、成都等地。虽然运行时间不短，但玩家在线人数一直维持在几百人的小规模上，迟迟没有突破，一个重要的原因就是服务器的效率及稳定性。2.2 MMOG服务器架构实例分析该休闲游戏平台服务端网络体系结构如图2.1所示图2-1休闲游戏平台服务端网络体系结构1、 登录服务器具有如下功能：1） 登录服务器主要用于检查用户登录信息是否合法，信息验证成功之后将询问全局信息服务器，客户端可以登录那一台大厅服务器，然后把登录信息返回给客户端。2） 登录成功后，发送玩家基本信息到全局用户信息服务器。2、 大厅服务器具有如下功能：1） 用于管理房间服务器基本信息，当用户请求进入房间时将从大厅服务器获得房间信息，如IP地址、端口号等基本信息。2） 管理大厅内基本用户信息列表，当用户请求进入房间时直接把用户信息发送给房间服务器。3） 在本大厅内广播聊天信息。3、 房间服务器具有如下功能：1） 管理房间信息，一个房间服务器中可以包含1个或多个房间，1个房间或多个房间对应一款休闲游戏，房间具有人数限制如200人，当某一休闲游戏玩家较多时可以增加房间，扩充可容纳玩家数量的上限。2） 管理房间中玩家信息，当玩家游戏状态变化时，将首先通知房间服务器，再由房间服务器转发到当前玩家所在房间的其他玩家。3） 房间服务器还将根据游戏的进程实时更新玩家的状态，使游戏保持同步。4、 对战转发服务器具有如下功能：1） P2P穿透，当玩家进入房间开始游戏的过程中，其游戏数据包将尽可能的通过P2P的方式发送以减少服务器的压力。玩家之间P2P穿透的过程就是有该服务器完成。2） 游戏数据转发，当玩家之间的P2P无法穿透时，为了保证玩家同样能够进行游戏，其数据包将通过该服务器转发。5、 数据库接口服务器具有如下功能：1） 数据库操作，其它所有服务器凡是需要与数据库打交道的操作都通过该服务器进行，而不是直接连接数据库。6、 全局信息服务器具有如下功能：1） 管理所有服务器基本信息，包括服务器的IP地址，端口号等，对于有些服务器如房间服务器还将管理如房间人数等信息。7、 用户信息服务器具有如下功能：1） 管理全局用户信息，该服务器管理者这个平台的用户基本信息，每当用户登录时都会把自己的基本信息在这里登记。2） 在各个大厅服务器之间转发信息，由于这个平台可以拥有多个大厅服务器，当有信息尤其是针对单个或部分特定玩家的信息需要要在多个大厅之间转发时，唯一可以获得全部玩家信息的服务器就是全局信息服务器，通过该服务器将找到玩家所在大厅，然后由大厅发送给玩家。8、 好友及战队服务器具有如下功能：1） 好友信息管理及点对点信息转发。2） 战队信息管理及战队信息转发。2.3平台运行过程中的问题1、 服务器性能低下，当连接并发量增加后，玩家发送的请求无法快速得到响应，玩家往往认为服务器已经失效。2、 服务器持续高效运行时间不长，长时间运行服务器性能下降严重，通常二至三天就必须重启一次服务器以提高服务器运行效率。3、 服务器不稳定，一个服务器失效有可能造成部分或全部玩家无法继续游戏。而且服务的恢复只能通过手工的方式进行。4、 游戏状态无法恢复，这就意味着服务器失效后，就算及时重启游戏服务器也无法为之前在服务器中的玩家继续提供服务。5、 每个玩家分散的连接于各个服务器之上，与任何一个服务器的断开都有可能导致玩家从平台断开连接。6、 各个服务器都保持着各自的玩家基本信息及状态，玩家状态副本过多，状态同步复杂困难。第三章 问题分析及解决思路作为一个产品级的应用软件来说，提供稳定的服务是一个基础，其次才是服务的效率。本章我们将首先围绕该游戏平台存在的稳定性问题，分析其原因并给出解决方案。之后我们将围绕该游戏平台存在的性能问题，分析其原因并给出解决方案。3.1稳定性问题分析3.1.1内存访问问题针对游戏平台长时间运行后程序性能下降严重这一问题，通过实地研究分析发现，服务器长时间运行之后性能下降的一个主要原因是由于系统可用内存几乎耗尽，然而仔细的分析服务器代码之后并没有发现内存泄漏的情况，观察服务器内存使用情况之后发现，系统存在大量的内存碎片，而这也正是系统可用内存几乎耗尽的原因。1、 什么是内存碎片“内存碎片”描述一个系统中所有不可用的空闲内存，这些内存以小而不连续的方式出现在系统内存中的不同位置。这些资源之所以不能使用，是因为负责分配内存的分配器无法有效使用这些内存13。即使在系统中事实上仍然有许多空闲内存，内存碎片最终都有可能导致出现内存用完的情况。一个不断产生内存碎片的系统，不管产生的内存碎片多么小，只要时间足够长，就会将内存用完。这种情况在MMOG这种高可用性系统中是不可接受的。有些软件环境，如OSE实时操作系统已经备有避免内存碎片的良好工具，然而该游戏平台所使用的Windows2003操作系统并不提供这一功能。2、 编译时间与运行时间的内存分配情况在windows系统和其它大多数操作系统中，内存的使用有两种方式：栈方式及堆方式。栈方式申请的内存由编译程序和链接程序完成内存分配功能，此时由于编译器完全清楚数据的生命周期，因此不会出现内存碎片。堆方式申请内存是通过诸如malloc()这样的函数在程序运行期间动态分配的，使用完毕后通过free()一类的函数将内存返还操作系统。这一过程就有可能产生内存碎片，因为内存分配程序的策略有可能导致有部分太小的内存永远无法使用。通过上面的分析，在程序开发过程中避免产生内存碎片的唯一办法就是不使用动态内存分配函数，而只使用栈内存分配方式。对于一个简单的应用程序来说这是可行的，但是对于MMOG服务器来说却是无法做到的，因为我们无法预知服务器会有多少用户，这些用户又会有多少种状态。在这种情况下我们只能减少内存碎片，使内存碎片维持在一个可接受的范围之内。3、内存池的定义和分类内存池的思想通过这个池字表露无疑，应用程序可以通过系统的内存分配调用预先一次性申请适当大小的内存作为一个内存池，之后应用程序自己对内存的分配和释放则可以通过这个内存池来完成。只有当内存池大小需要动态扩展时，才需要再调用系统的内存分配函数，其他时间对内存的一切操作都在应用程序的掌控之中，因此可以有效的避免内存碎片问题。应用程序自定义的内存池根据不同的适用场景又有不同的类型。从线程安全的角度来分，内存池可以分为单线程内存池和多线程内存池。单线程内存池整个生命周期只被一个线程使用，因而不需要考虑互斥访问的问题；多线程内存池有可能被多个线程共享，因此则需要在每次分配和释放内存时加锁。相对而言，单线程内存池性能更高，而多线程内存池适用范围更广3。从内存池可分配内存单元大小来分，可以分为固定内存池和可变内存池。所谓固定内存池是指应用程序每次从内存池中分配出来的内存单元大小事先已经确定，是固定不变的；而可变内存池则每次分配的内存单元大小可以按需变化，应用范围更广，而性能比固定内存池要低3。4、内存池工作原理示例下面以固定内存池为例说明内存池的工作原理，如图3-1所示。图3-1内存池工作原理固定内存池由一系列固定大小的内存块组成，每一个内存块又包含了固定数量和大小的内存单元。如图3-1 所示，该内存池一共包含4个内存块。在内存池初次生成时，只向系统申请了一个内存块，返回的指针作为整个内存池的头指针。之后随着应用程序对内存的不断需求，内存池判断需要动态扩大时，才再次向系统申请新的内存块，并把所有这些内存块通过指针链接起来。对于操作系统来说，它已经为该应用程序分配了4个等大小的内存块。由于是大小固定的，所以分配的速度比较快；而对于应用程序来说，其内存池开辟了一定大小，内存池内部却还有剩余的空间。例如放大来看第4个内存块，其中包含一部分内存池块头信息和3个大小相等的内存池单元。单元1和单元3是空闲的，单元2已经分配。当应用程序需要通过该内存池分配一个单元大小的内存时，只需要简单遍历所有的内存池块头信息，快速定位到还有空闲单元的那个内存池块。然后根据该块的块头信息直接定位到第1个空闲 的单元地址，把这个地址返回，并且标记下一个空闲单元即可；当应用程序释放某一个内存池单元时，直接在对应的内存池块头信息中标记该内存单元为空闲单元即可。可见与系统管理内存相比，内存池的操作非常迅速，它在性能优化方面的优点主要如下。1） 针对特殊情况，例如需要频繁分配释放固定大小的内存对象时，不需要复杂的分配算法和多线程保护。也不需要维护内存空闲表的额外开销，从而获得较高的性能。2） 由于开辟一定数量的连续内存空间作为内存池块，因而一定程度上提高了程序局部性，提升了程序性能。3） 比较容易控制页边界对齐和内存字节对齐，没有内存碎片的问题。3.1.2游戏状态管理问题1、游戏状态的重要性游戏状态对于MMOG来说是至关重要的，任何游戏状态的错误都有会影响MMOG的有效性，为什么在第二章提到的游戏平台实例中任何一个服务器失效或崩溃都会导致全部或部分玩家无法有效，其原因就在于游戏状态的丢失，设计并开发出一种有效的状态管理机制对于MMOG来说是非常有必要的。2、服务器的状态分类通过分析第二章中MMOG的各个服务器的功能及和目的之后，可以发现，服务器按是否维护游戏状态为标志可以大致分为两大类型：有状态服务器（简称状态服务器）、无状态服务器（或称为事务服务器）。状态服务器主要用于保存客户端在其生命周期内各种关键状态。对于一个客户端A来说，这些状态对自身来说十分重要，对于其他用户来说也是必须的，是其他用户与客户端A进行交互的基础，同时这些状态的访问及更新频率十分频繁，不可能存储于数据库等第三方的数据管理模块中，而必须存储在本进程的内存空间中以便实时访问及修改，这类服务器专门用于管理计算服务端的游戏状态，因此我们将其称为状态服务器。事务服务器或无状态服务器是与状态服务器向对应的一种服务器，这类服务器主要功能是进行原子性的事务处理，不缓存管理用户状态，其对用户状态的更改将实时提交数据库或文件系统一类的永久存储介质之中。对于事物服务器，只要处理逻辑没有异常，输入正确则得到的结果也必然正确。然而对于状态服务器来说，处理逻辑的正确只是基础，其运算环境的正确才是得到正确数据的关键，因此对于状态服务器来说，如何管理状态就成为一个关键点。3、冗余技术讨论对于MMOG服务端程序来说百分之百没有Bug是有可能的，但是不现实，尤其对于刚刚上线运行的新系统来说更是如此，因此提高软件的容错性来保证服务器持续运行是必不可少的。系统容错是建立在冗余基础上的，这种冗余是指超过正常系统操作所需要的信息、资源或时间的简单加和。软件系统同样是系统，所以软件容错也是靠冗余类完成。主要有恢复块方法和N版本程序设计。11） N-版本程序设计法N版本程序设计如图3-2，是一种静态的故障屏蔽技术，采用前向恢复的策略，其设计思想是用N个具有相同功能的程序同时执行一项计算，结果通过多数表决来选择。其中N份程序必须由不同的人独立设计，使用不同的方法，不同的设计语言，不同的开发环境和工具来实现。目的是减少N版本软件在表决点上相关错误的概率。另外，由于各种不同版本并行执行，有时甚至在不同的计算机中执行，必须解决彼此之间的同步问题1。 图3-2 N-版本程序设计法N-版本程序设计发由于其投入的开发成本及后期的维护成本较高，对于需要不断升级的MMOG系统并不适合。2） 恢复块方法故障的恢复策略一般有两种：前向恢复和后向恢复。所谓前向恢复是指使当前的计算继续下去，把系统恢复成连贯的正确状态，弥补当前状态的不连贯情况，这需有错误的详细说明。所谓后向恢复是指系统恢复到前一个正确状态，继续执行1。对于MMOG这种运行于Internet环境中的分布式应用系统来说，不论是在系统运行之前还是在系统运行期间，要明确的定义出每一个可能产生的错误本身就是一件不可能的任务。而后向恢复虽然实时性相对较差，但是在一个可以承受的范围内完成系统的恢复还是可以的，因此在MMOG中更适合采用后向回复技术。3、 各类型服务器恢复策略讨论1） 事务类服务器事务服务器由于不管理客户端状态，并且客户端状态的改变将原子性的交由数据库服务器或文件系统管理，因此对于事务型服务器，当服务器出现异常无法继续服务时只需要在可以接受的时间范围之内，简单的重新启动服务或找到一个新的可用服务即可。在本系统中我们将同时采用两种办法。对于严格要求无间断服务的核心事务服务器（如数据库接口服务器）我们将采用备份服务的办法，当主服务出问题后备份服务马上接管。对于短时间内停止服务并不会影响客户端整体感受的服务器（如登录服务器），我们将采用重启动的办法。2） 状态类服务器状态服务器的容错处理关键在于对状态的管理。通常有两种办法。a) 备份服务器方法客户端发往服务器的请求被同时发给主服务器及备份服务器，主、备服务器为同样的应用程序，但是运行于不同的进程之中（本地的或异地的），由于两台服务器以完全一样的算法运行，两台服务器的状态可基本保持一致，当一台服务器出问题后另一台服务器可以马上接替工作，实时性极高。然而这种服务器也存在问题，因为两台服务器均处理来自客户端的请求，而且处理逻辑一致，因此极有可能由于主备服务器存在同样的软件缺陷而导致主备服务器同时异常而失去容错处理能力。b) 状态的备份与恢复状态备份是指以给定的检查点为分界，不断的备份服务器的状态，这种方式可以有效避免“备份服务器方法”由于同样逻辑错误而导致主备服务器同时失效的问题，缺点就是备份算法复杂，比较耗时，恢复过程也比较复杂，该方法应用于更新频率较低的状态还是比较有效的。由于在本文中我们主要面对的问题是由于服务器可能存在逻辑错误的前提下来考虑异常处理的，所以对于状态的管理使用备份与恢复策略能够达到更好的效果。3.1.3服务失效管理问题对第二章中所提游戏平台各个服务器进行分析后，我们发现该游戏平台没有一种很好的机制发现并快速处理因为异常而退出的服务器。其发现和处理过程完全通过手工方式效率极低，很有必要引入一种有效机制解决这一问题失效管理包括失效发现及失效恢复两个部分。其中服务失效发现将用到一种叫做心跳检查的技术。在当前MMOG系统中，心跳服务通常是以独立的命令存在于必须保持热连接的服务器与服务器之间或服务器与客户端之间。当获得服务器发送心跳数据包到希望维持的另外一条服务器时，如果发送方能在规定的数据内得到响应，则说明该连接保持活动，而如果超过一定时间没有得到响应则认为已经与服务器失去连接或是连接的用户为僵死用户。该技术同样可用于检测服务器是否保持活动。3.1.4客户连接管理问题在第二章介绍的MMOG网络连接结构中，每一个客户端都会同时保持与大厅服务器及好友战队服务器的连接，进入房间的用户还会与房间服务器及对战服务器保持连接，其结构可见图3-3。这就意味着平台中绝大多数服务器都直接面对用户，他们都承担同样重的并发连接负荷，随着人数的上升，这些服务器都必须同时升级服务器硬件及网络带宽。此外，如果由于玩家一方的网络出现问题而必须重新连接服务器时，客户端必须与多台服务器交互，而这一过程可能较为缓慢。此结构还带来一个问题，由于有众多的服务器直接暴露在公网上也增加了受到工具的可能性。图3-3传统client/server结构为解决这个问题，我们的做法是：把处理外部连接和处理游戏逻辑分摊到两个服务器上处理，连接服务器做的事情可以非常简单，只是把多个连接上的数据汇集到一起。假设同时连接总数不超过 65536 个，我们只需要把每个连接上的数据包加上一个两字节的数据头就可以表识出来。这个连接服务器再通过单个连接和逻辑服务器通讯就够了。当逻辑服务器需要把处理结果返回客户端，那么也需要通过连接服务器，这时就需要加上标识告诉连接服务器，数据返回到那个或那些客户端了（全部用户、部分用户、一个用户）。其结构可见图3-4。那么连接服务器尽可以用最高效的方式处理数据，它的逻辑却很简单，代码量非常的小，必然处理效率能够大大提高，逻辑服务器也不用直接暴露在客户端的前面了。图3-4改进后的client/server结构3.2效率问题分析MMOG服务器运行的效率同样重要，尤其是用户数越来越多时，系统能否及时响应就变得至关重要了。对系统性能的影响有以下几大因素：3.2.1网络编程模型的选择一个好的网络编程模型将极大的提高并发访问数量，同时也将影响日后服务器的可扩展性。因此选择一个好的编程模型是开发出一个好的通信中间件的基础。下面我们将对现在各种网络编程模型进行分析、比较，以找到最好、最适合MMOG的编程模型。总的来说，网络编程模型有两大类：阻塞模型和非阻塞模型。在阻塞式模型中，函数对Send和Recv的调用将阻塞，直到Send或Recv的数据全部处理完成（接收完毕或发送完毕）调用才会返回。在非阻塞式模型中，Socket函数的调用将立即返回而不需要等待完成。1、 阻塞模型在绝大多数的socket程序中，应用都遵循生产者消费者模型，在这种模型中，程序接受一定数量的数据，然后对数据进行计算，之后将结果返回客户端。下面的简单例子说明了这一过程：While(!down)nBytes = recv(s, buf, 100);if(nBytes = -1). /接收错误Return;DoSomeCompute(buf, nBytes);在阻塞模型中，通常都遵循“停止等待”这种最简单的协议，这种协议非常简单而且可以保证客户端与服务器之间状态的同步。阻塞通信模型的问题在于：当调用recv函数之后，这个通信线程将被阻塞，直到recv接受到数据之后。使用这种模型为了处理来自多个客户端的并发访问就不得不使用多线程的方式，使不同的Scoket运行于各自的线程之中。这种办法对于少数客户端来说还是行之有效的，然而对于并发量超高的网络游戏来说却是远远不够的，因为线程作为一种计算资源，系统对其维护是需要系统时间和资源的，一条进程中包含上千甚至是几千条线程，其效率的低下是无法想象的，因此，多线程方案无法解决网络游戏高并发量的需求。2、 非阻塞模型与阻塞模型相对，非阻塞对于socket函数的调用不会阻塞，也就是说对例如connect，send，recv等函数的调用将立即返回而无需等待，数据的发送或接受将交由系统自身去完成。比起阻塞模型来，非阻塞模型的开发难度更大，但是由于函数的调用不会阻塞，因此可以用一条线程为若干客户端提供服务。由于避免了多线程的使用，所以，非阻塞模型能够提供更加优异的性能，也更适合用于网络游戏。非阻塞模型又细分为很多种。1）Select模型Select模型是一种应用非常广泛的模型，其在各种平台上都有对应实现，用这种模型实现网络通信程序具有较好的移植性，例如著名的跨平台Web服务器Aparch的核心就是使用Select模型开发的。该模型之所以叫做Select模型是因为使用了Select函数来管理网络I/O操作。Select函数用于决定在一个Socket上是否有数据可以读写。使用Select模型的函数块大致如下所示：SOCKET s;Fd_set fdread;Int ret;While(true)FD_ZERO(&fdread);FD_SET(&fdread);If(ret = select(0, &fdread, NULL, NULL, NULL)/ErrorIf(ret 0)If(FD_ISSET(s, &fdread)/A read event has occurred on socket s使用Select的方式的缺点是，当Select所监视的连接数目在千的数量级时，性能会打折扣。这是因为操作系统内核需要在内部对这些Socket进行轮询，以检查其可读写性。另一个问题是：应用必须在处理完所有的可读写socket的IO请求之后，才能再次调用Select,进行下一轮的检查，否则会有潜在的问题。这样，造成的结果是，对一些请求的处理会出现饥饿的现象。第二章中提及的游戏平台正式使用了Select模型，当并发量不大时，该模型还是能很好的处理来自各个连接的请求的，随着并发量的不断升高服务器的性能严重下降，这是Select模型本身带来的问题，通过升级硬件性能无法得到较大提升。2）Overlapped（重叠）模型Overlapped I/O 模型是Windows环境下的一种异步I/O模型，重叠模型的基本设计原理便是让应用程序使用一个重叠的数据结构，一次投递一个或多个Winsock I/O请求，这些请求将由操作系统来处理完成，当请求完成之后操作系统将通过回调函数的方式通知应用。这一过程将在系统内核完成，因此其执行效率将高于用户态，同时也避免了大量的从内核态到用户态的切换。Overlapped I/O 模型对于有大量I/0操作的应用来说将极大的提高应用程序性能7。然而Overlapped I/O 模型，并没有能很好的应用多线程来提高系统性能，对于单CPU的计算机来说这不是问题，然而对于多CPU的计算机来说就无法发挥计算机的全部性能了，这同时也就决定了使用该模型无法通过改善机器硬件的性能而带来等价的程序运行效率的提升。对于大型的MMOG来说，多CPU服务器是必然，因此该模型也无法满足MMOG的需求。3）Completion Port（完成端口）模型完成端口是一种windows环境下的异步I/O开发模型，他通常与Overlapped模型配合使用，由Overlapped完成I/O读写，完成端口本身对工作者线程进行管理，并进行完成通知。因此完成端口具有Overlapped模型高吞吐量的优点7。服务器的实现通过引入IOCP会大大减少Thread切换带来的额外开销。我们都知道，对于服务器性能的一个重要的评估指标就是：SystemContext Switches，即单位时间内线程的切换次数。如果在每秒内，线程的切换次数在千的数量级上，这就意味着你的服务器性能值得商榷。Context Switches/s应该越小越好。说到这里，我们来完成端口如何管理线程，如图3-5。图3-5 完成端口线程管理模型完成端口的线程并发量可以在创建该完成端口时指定（即NumberOfConcurrentThreads参数）。该并发量限制了与该完成端口相关联的可 运行线程的数目,当与该完成端口相关联的可运行线程的总数目达到了该并发量，系统就会阻塞任何与该完成端口相关联的后续线程的执行，直到与该完成端口相关联的可运行线程数目下降到小于该并发量为止。最有效的假想是发生在有完成包在队列中等待，而没有等待被满足，因为此时完成端口达到了其并发量的极限。此时，一个正在运行中的线程调用GetQueuedCompletionStatus时，它就会立刻从队列中取走该完成包。这样就不存在着环境的切换，因为处于运行中的线程就会连续不断地从队列中取走完成包，而其他的线程就不能运行了。完成端口的线程并发量的建议值就是你系统CPU的数目。在这里，要区分清楚的是，完成端口的线程并发量与你为完成端口创建的工作者线程数是没有任何关系的，工作者线程数的数目，完全取决于你的整个应用的设计，当然这个不宜过大，否则失去了IOCP的本意。在完成端口模型中，工作者线程的管理是在内核层完成的，因此其线程管理效率将远高于用户层。同时，完成端口通常与Overlapped模型配合使用，使其同样具有高效的I/O处理效率。4)epoll模型Epoll是由Linux2.6提供的一种高性能的异步I/O模型，与IOCP不同，IOCP是在IO操作完成之后，才通过get函数返回这个完成通知的；而epoll则不是在IO操作完成之后才通知你，它的工作原理是，你如果想进行IO操作时，先向epoll查询是否可读或可写，如果处于可读或可写状态后，epoll会通过epoll_wait函数通知你，此时你再进行进一步的recv或send操作。我们可以看到，epoll仅仅是一个异步事件的通知机制，其本身并不作任何的IO读写操作和线程管理功能，它只负责告诉你是不是可以读或可以写了，而具体的读写操作，还要应用层自己来作；但IOCP的封装就要多一些，它不仅会有完成之后的事件通知，更重要的是，它同时封装了一部分的IO控制逻辑和线程管理功能。5）小结通过以上分析，我们知道完成端口模型具有极高的线程管理效率及高效的I/O处理效率，同时其性能将随着系统CPU数量的增加而线性增长，具有处理大量并发数连接的能力，因此该模型特别适合用于windows平台下用于大型MMOG的服务端编程模型。综上所述，原系统由于在网络体系结构，服务器配置及关键技术的选择上存在各种问题，因此无法为玩家提供稳定快速的服务。通过分析比较，我们最终确定了本文中设计的服务端通用运行支撑平台的主要技术及相关服务。其中主要技术包括：IOCP（完成端口模型），内存池，对象池。主要服务包括：基本通信服务，内存管理服务，游戏状态备份及恢复服务，连接管理服务，心跳服务，全局监控管理服务。下面章节我们将详细讨论各个技术的实现要点，并对各个服务的实现方法进行详细描述。第四章 服务端通用运行支持平台设计4.1总体设计通过第三章的讨论，我们最终决定服务端通用运行支持平台由以下几大服务构成：1、 网络通信服务该服务是平台的基础，提供了基本通信功能，由：I/O完成事件消息循环模块、全局关键字发生器、线程池管理器、网络数据包管理器、完成键管理器几个模块组成2、 内存管理服务内存管理在本系统中是基础的基础，所有模块对内存的访问都通过该模块进行，同时还为系统外部的客户程序提供访问接口。3、 状态备份及恢复服务该模块使用后向恢复技术，以网络消息为检查点对消息进行备份。主要由消息备份模块、消息恢复模块组成。4、 连接管理服务该服务管理着所有客户端的连接，客户端与游戏服务逻辑的通信均由该服务转发，由于客户端不再与游戏逻辑服务连接，因此极大的减轻了并发访问逻辑。5、 全局监控管理服务器该服务监视所有服务器的活动情况，当发现有服务器没有响应后自动重启相应服务。6、 心跳服务集成在基本通信服务内部，负责定时发送心跳数据包，当发现心跳无响应后将通知客户程序。图4-1通用运行支撑平台体系结构4.2网络通信服务在本系统中，网络通信服务的核心是如何实现一个高效率、高稳定性的基于完成端口网络通信库。在下面的章节中我们将首先讨论完成端口开发难点、要点及相关处理算法，然后给出网络通信服务的基本架构，最后给出函数接口说明和关键数据结构说明。4.2.1 IOCP开发难点及要点及相关处理算法完成端口模型对于开发高并发量及大吞吐量的服务器来说具有先天的优势，然而使用完成端口开发的问题在于它的复杂性，其复杂性体现在以下两点：4.2.1.1 IOCP完成键管理问题要说明这个问题我们首先需要对完成端口开发的一个基本过程有所了解。完成端口是一个windows内核对象，通过一定数量的线程，对重叠I/O请求进行管理，以便为已经完成的重叠I/O请求提供服务器。其核心是通知机制加多线程管理。1、 完成端口模型编程简介完成端口编程的基本步骤如下：1） 创建一个完成端口内核对象。2） 判断系统内安装了多少个CPU。3） 根据步骤2得到的CPU数量创建一定数量的工作者线程，为已完成的I/O请求提供服务。4） 准备一个将要与完成端口关联的套接字。5） 创建一个完成键对象，该对象中将包含管理这条连接的所有重要信息，如套接字句柄。6） 将套接字与完成端口关联，接受完成端口的管理。7） 工作者线程等待完成端口的完成通知。收到通知后进行相应处理。8） 重复4-7步直到服务器终止。完成端口的详细应用已经超出了本文的范围，在这里我们只简单介绍几个关键的API及数据结构，和一些重要概念。1） CreateIoCompletionPort函数函数原型如下：HANDLE CreateIoCompletionPort(HANDLE FileHandle,HANDLE ExistingCompletionPort,DWORD CompletionKey,DWORD NumberOfCurrentThread);FileHandle：需要与完成端口关联的Socket句柄。ExistingCompletionPort：Socket句柄与那个完成端口关联。CompletionKey：完成键，该值将与Socket句柄绑定，当在该Socket获得完成通知时，该值也将同时被返回。NunmberOfCUrrentThread：完成端口允许同时运行的工作者线程数目。该函数有两个功能，1）用于创建完成端口内核对象，2）将完成端口与套接字关联。使用功能1）时这四个参数没有意义，填入空(NULL)即可。2） GetQueuedCompletionStatus函数该函数使工作者线程在完成端口上等待，当有Socket句柄上I/O操作完成后，如WSASend函数数据发送完毕，或WSARecv数据接收完毕后该函数将返回。其函数原型如下：BOOL GetQueuedCompletionStatus(HANDLE CompletionPort,LPDWORD lpNumberOfBytesTransferred,LPDWORD lpCompletionKey,LPOVERLAPPED * lpOverlapped,DWORD dwMilliSeconds);CompletionPort：在那个完成端口上等待完成通知。lpNumberOfBytesTransferred：本次I/O实际操作字节数。lpCompletion