最近闲着没事把云风的《》看了个遍，希望能从大牛的开发轨迹中得到一些启发。但可能是因为本人level太低，一遍看下来还是云里雾里，不甚明白。没办法只好再看一遍，希望能对他们的服务器端架构有个简单的认识，这里同时做些笔记。
PS：本文是我个人对云风的开发笔记的读后感，可能会有很多错误，慎入！
----------------------------------------华丽丽的分割线-------------------------------
一、服务器划分原则  
    在现有的网络游戏服务器端架构中，多是以功能和场景来划分服务器结构的。负载均衡和集群暂且不在本文中讨论（bigworld、atlas）。服务器划分可以基于以下原则：
分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器。
以多线程或多进程的编程方式适应多核处理器。
在同一个服务器架构下，应尽可能的复用某些服务器（进程级别的复用，比如场景服务器）。
运行时玩家数据的保存、修改及数据流向应该是设计的焦点，它同时也决定了服务器应该如何划分。
服务器的划分应该适度，在保证清晰的数据流向的前提下，根据游戏的类型和规模尽量减少服务器或服务器进程的个数，以减少服务器之间过多的复制数据、锁冲突（使用共享内存进行通讯时）。
主要按照场景划分进程，若需按功能划分，必须保持整个逻辑足够简单，并满足以上1、3两点[1]。
    接下来我们来看看云风的服务器架构是如何处理好以上几点的。
图1 服务器架构（此图为本人猜测，可能有误）
二、运行时的玩家数据
    网络游戏服务器程序一项重要的工作就是根据client发过来的数据包，在服务器端模拟玩家的行为操作并把这些行为广播出去。那么服务器程序在运行时就需要一些实体来保存玩家的数据，这些实体可以是一个类，也可以是一个线程，设计思想不同采用的实体差别也会很大。这里涉及服务器端设计的一个核心问题：运行时玩家数据的保存、修改及数据流向。
    云风通过抽象实体agent来处理单个client的服务请求，agent和client是1:1的关系（见图1）。agent是在gate程序后端，负责翻译、转发以及回应客户端发过来的请求。agent的主要工作内容见云风的《》。值得补充的是设计agent的主要优势是：
把对单个 client 服务的代码集中写在 agent 服务中。由 agent 再和内部其它服务沟通。数据加载使用共享内存的方案，由 agent 向持久化模块发出信号，做加载或纯盘处理，通过共享内存得到结构化数据块。[2]
    agent相当于client在服务器上对应的实体，玩家的属性和数据只能由agent来修改，别的服务只有读权限。通过attach操作获得数据（attach可能是通过服务器通讯框架skynet，也有可能直接mmap到共享内存sharedb上以获得数据）。
    agent的设计使得整个系统对玩家数据的修改只有一个输入点，数据流十分的明确，易于维护。虽然这种设计可能会照成数据的多次复制，但是带来的代码维护和查错上的便利是十分可观的。
    如果把所有的agent放在同一个进程里，在编程该程序时还应该考虑到容错问题，比如说（1）使用C++编写这个程序，agent以类的形式存在，使用thread pool来处理收到的数据包，实际操作时thread的数量是会远远小于agent的数量的，数据包到达后会在队列里等待thread调用agent的逻辑来处理。这是一种比较常见的设计方法，但要注意的是由于agent都放在一个进程里，程序的健壮性要求很高，一个进程core则会导致全服玩家掉线。而使用C++编写也增加了宕进程的可能性……..你懂的。（2）使用java编写，对于这种“中心节点”式架构来说可能是更好的选择，起码不是因为一个玩家的误操作(可能使用外挂)导致全服玩家掉线。（3）云风似乎是使用lua coroutine来实现agent的相互隔离和协同工作的，这样可以减少单一agent失败对其他agent的影响（动态语言的好处）。
    sharedb在系统中的地位看上去像是database前端的cache，但就本人的理解sharedb的作用远不止是一个数据缓存。
    和天龙八部的ShareMemory类似，sharedb也采用了定长的结构化数据（见《》），通过共享内存来实现进程间的数据共享。sharedb的存在使得游戏逻辑处理和数据保存逻辑得到很好的隔离，游戏逻辑不用关心后端的数据是如何保存的，只要sharedb挂上定期存盘的服务，在接口定义明确的情况下，后端到底采用什么样的数据库变得不是那么重要，从而降低了系统的耦合度。
三、服务器底层框架skynet
    skynet的设计思想见《》：
    我希望我们的游戏服务器（但 skynet 不仅限于用于游戏服务器）能够充分利用多核优势，将不同的业务放在独立的执行环境中处理，协同工作。这个执行环境，最早的时候，我期望是利用 OS 的进程，后来发现，如果我们必定采用嵌入式语言，比如 Lua 的话，独立 OS 进程的意义不太大。Lua State 已经提供了良好的沙盒，隔离不同执行环境。而多线程模式，可以使得状态共享、数据交换更加高效。而多线程模型的诸多弊端，比如复杂的线程锁、线程调度问题等，都可以通过减小底层的规模，精简设计，最终把危害限制在很小的范围内。这一点，Skynet 最终花了不到 3000 行 C 代码来实现核心层的代码，一个稍有经验的 C 程序员，都可以在短时间理解，做维护工作。
    做为核心功能，Skynet 仅解决一个问题：
    把一个符合规范的 C 模块，从动态库（so 文件）中启动起来，绑定一个永不重复（即使模块退出）的数字 id 做为其 handle 。模块被称为服务（Service），服务间可以自由发送消息。每个模块可以向 Skynet 框架注册一个 callback 函数，用来接收发给它的消息。每个服务都是被一个个消息包驱动，当没有包到来的时候，它们就会处于挂起状态，对 CPU 资源零消耗。如果需要自主逻辑，则可以利用 Skynet 系统提供的 timeout 消息，定期触发。
    Skynet 提供了名字服务，还可以给特定的服务起一个易读的名字，而不是用 id 来指代它。id 和运行时态相关，无法保证每次启动服务，都有一致的 id ，但名字可以。
    本人感觉skynet像一个发布订阅的消息中间件（还没看源码，可能有误），这种基于服务的即插即用式的框架给服务器端带来很大的可扩展性，同时也使得各模块之间独立清晰，具有良好的可维护性。但是这里有个疑问，服务都以so的形式挂在skynet上，那么这些服务从哪里获取玩家、怪物、NPC等object的数据？是从skynet中获得还是直接从sharedb中获得，出于性能的考虑是不是要把skynet和sharedb部署在同一台物理主机上？这样一来就会增加设计和具体逻辑的耦合度。看了《》，感觉skynet上的服务是要通过skynet来获得玩家的数据，这样操作会不会导致数据被复制很多次，不知道最终的效率是否受到影响？
    满足服务器划分原则里的第一点：分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器。
    gate的主要工作可以参见本系列blog的第二篇《》
五、场景管理器
    主要用于管理静态场景和动态副本，比如agent登录时查询自己所在场景对应的服务器地址。
六、场景服务器
    场景服务器的内容我没有从《开发笔记》中得到太多的信息（可能level太低），更多的是以功能模块的形式写，比如AOI。不过其中有一点比较新颖的是云风认为player的位置、动作状态，战斗数值状态等都是场景的一部份，应该保存在场景中而不是agent中。本节有所更正见（八）补充。
    据我的猜测，场景服务器应该会负责：
怪物行走控制，player移动更新及位置同步
怪物AI策略
区域性广播，场景广播
AOI服务（Area Of Interest ）
    需要注意的是场景服务器修改的一些数据应该以什么样的频率通知agent呢？比如player的位置信息，该信息是完全保存在场景数据里还是说agent里也有一份？
    本文是一篇云风《开发笔记》系列blog的读后感，所述内容均是本人的猜测，虽恐贻笑大方，但也希望能抛砖引玉。收笔忐忑ing！
八、补充：
  (1) 云风在微薄上的回复是：“我们最终采用的是单进程多线程, 每线程上一个 lua state 的结构. sharedb 是用来线程间数据交换的. gate 和 sharedb 以及 loader 和 agent map 一样, 都是 skynet 下的独立服务, 以 so 挂接进去的. 后来的商品交易, 掉落品分配也是 skynet 下的服务. ”
  (2) 关于场景服务器，云风已经给出完整的说明，见《》
    场景服务分成两个部分，一是副本管理器，二是地图服务。在角色数据上，记录有角色应该属于的地图。agent 向地图所属的副本管理器查询，得到他所属的地图服务地址。便可以把自己注册到具体地图上。
    地图服务管理了所有其中的角色 id ，以及若干 npc 。他的义务在于把让这些 id 对应的 agent 相互了解。但具体逻辑则放在每个 agent 服务上。每个 agent 自己所属进程 attach 其它 id ，可以获取其他对象的状态。
  .........
  (3) 风哥在《》中已经提到最终使用单进程多线程的模式。看来简单设计是有共识的:-)
References：
[1]《游戏服务器的架构设计》：
[2] 云风，《开发笔记(9)》:
阅读(...) 评论()游戏产品经理一般看哪些数据？
看道具使用情况、看月消费、充值、在线，具体该如何作出判断和分析？请适当讲讲。另外对游戏内数值设定应了解多少？Excel应掌握到什么程度？
按投票排序
好问题首先，最最最最重要的：如果你只是个数据分析师，你只需要学会怎么处理数据与从中看出问题如果你是产品经理（运营、策划）你要学会的是怎么解决这些问题！还有，永远不要迷信数据。游戏是艺术和科技的结合，总有她感性的一面。因为自己不是专业数据分析师，只是看的多了，所以理解数据的深度肯定不比专业分析师，求轻喷，下面开始正文，3Q~~~======= 非常同意
的意见，游戏大部分只关心两个数据，留存和付费，之后，不同的策划或者或针对不同的游戏着重关注的点会不同。’比如说，收费策划（也就是收费运营）会比较侧重关注付费，而研发主策则会比较关系留存，当然，两者是相辅相成的。下面大致列下要关注的数据，如若不齐望见谅（所有曲线都是自己画的，不代表任何游戏~）：1.登陆活跃：最基本的数据，说白了就是每天有多少人登陆了游戏，这条曲线一般在周末及节假日出现高峰好吧，我画图确实不怎么样，波峰一般是周五、六、日，低谷是周中，节假日会有大波峰，如果发现这条线长期走低了，那恭喜你，你的游戏在走下坡路了，如果偶尔有一两个不正常的起伏可能是bug或者当天有运营活动所致。总而言之，不管在任何项目，登陆活跃是除了付费总额之外最最需要关注的数据（个人意见）如果登陆曲线出现问题，那游戏肯定处于不健康状态，然后再去各个细的数据项找原因，这也就是为什么我觉得这个数据最值得关注了。2.新增：即每日新增的账号，这里有很多定义，有的项目喜欢统计新增角色数，有的喜欢统计新增账号数，这完全视游戏形式而定，新增的曲线一般起伏和登陆差不多，但有时候会出现诡异的高峰，这种时候不是做拉新手活动了就是市场部发力了，总之是好事吧。另外需要非常注意的是，在不同阶段的游戏新增数据的数量级差距是非常非常大的，主要还是市场起作用，要靠游戏内拉动这根曲线是比较困难的，主要有拉新手送XXX这种活动形式，但是个人还是觉得这条线用市场力量改变的更加明显。另外需要非常注意的是，在不同阶段的游戏新增数据的数量级差距是非常非常大的，主要还是市场起作用，要靠游戏内拉动这根曲线是比较困难的，主要有拉新手送XXX这种活动形式，但是个人还是觉得这条线用市场力量改变的更加明显。3.各种留存：现在大多数市场机构最看重的一个数据，其实际效果暂且不说，但在大环境下，关注这个数据还是很有必要的！留存一般分为
活跃留存 与 新手留存每种又按天分到：次日留存、三日留存、七日留存、十四日留存、三十日留存……当然如若有需求可以无穷无尽的列下去，但是一般看到三十日也就够了。举个例子，一个用户，今天登陆了明天还登陆，那就算活跃次日留存，后天还登陆了，就算三日留存一个新手，今天登陆了明天还登陆，那就算新手留存，后天还登陆了，就算三日留存……以此类推，然后算个百分比留存我就不画图了，每个游戏差的太多，贴一张前段时间网传很火的图：来源：从上图可以看到，活跃数据中，推广平台最看重的是 次日留存 与 七天留存 要注意的是，这两项所指的都是 新手留存(一般也叫注册留存率），也就是说，今天登陆游戏的玩家，必须有50%的用户在第二天也登陆了，才是S级，并且这些玩家中的30%要在一周后还持续登陆。这边列举的是手游数据，一般的页游新手留存会稍低一些关于那些传说新增次日留存能到98%的游戏，实在令人想不通怎么会有那么高的数据，所以也经常有人说，98%的次日留存就是在前一天23:59开服就好（笑）这里说句题外话，早些年自己呆过一家公司，游戏已经很成熟并且上了平台了，然后悲剧的是收费一直做不起来，后来老板就让我们做留存，然后他去忽悠投资人的钱……所以，留存是多么重要啊~所以如果你在一个创业小项目又急着要上平台或者上线，请密切关注留存数据！拉留存的方法比较多，上些游戏论坛随便一搜就能搜到，我简单说点：签到（3天、7天、30天）、到XX级送神装、任务卡进度、体力值……总之，一句我自己对留存的总结：要拉短期留存不难（次日~7天），做活动卡节点就可要拉长期留存，只能靠游戏品质！4.平均在线时长：即，今天登陆的所有玩家平均在线多少时间。这个数据的大区间是由游戏的类型决定的！简单的说你不能用愤怒的小鸟和魔兽世界比在线时长，这是毫无意义的！现在主流页游一般的平均在线时长是3500s合格，也就是1个多小时（好吧，这也是我自己觉得的，如果哪位大神有官方点的分级希望分享~）上图：总的来说一般平均在线时长的图也是周末峰值，但是不会非常明显，甚至有些游戏会基本看不出峰值。在线时长的主要作用：①游戏是否健康：比如一个当代mmorpg在线时长还不足3000s，如果没有特殊的玩法，这款游戏就基本已经宣告失败了。这个点要注意的是，特别注意满级（不只针对满级~）用户的平均在线时长，有条件的话分等级专门拉出来。满级以后的玩法设定是否合理很大程度上可以在这项数据上体现。②竞品竞争：对于玩家来说，每天玩游戏的时间相对是固定的，这款游戏的在线时长降了，肯定那款就升了，所以每当有明显的竞品出现时，在线时长数据总会波动的非常厉害，有时甚至需要紧急的出些活动把在线时长拉回来。拉在线时长也有比较简单的方法，现在最主流的“挂机”玩法就很大程度上拉升了在线时长，当然诸如“在线礼包”也是为了拉升在线时长而生的。继续更5.ACU和PCU即 平均同时在线玩家人数 和 最高同时在线玩家人数。ACU：一般是按天为单位的，也有按一天内的时段分（比如 上午、中午、晚上）。ACU比较着重反映游戏的平均在线状态，在端游中会更为看重这项数据，它能比登陆人数更精确的反映游戏的真实健康程度（登陆人数可能由于刷小号、大新增等原因发生波动，而ACU避免了这些问题）与大多数曲线一样，ACU也是在节假日偏高的，但是幅度不会抖的非常厉害PCU：可以按天看也可以按小时看按分钟看按秒看…………大家喜闻乐见的宣传口号：XX游戏在线突破XXXX百万！
说的就是PCU。PCU的峰值一般出现在晚上，也有些游戏会出现在中下午。除了能从PCU看出游戏的受欢迎程度之外，PCU还是活动运营很重要的一个风向标，往往游戏内强一点的活动会放在PCU最高的时段，而不偏重操作与交互的活动会放在PCU较弱的时段。在一般情况下，如果PCU的低值与高值相差太多的话也有可能说明游戏正处于不健康的状态（这个判断可以由ACU/PCU 的值来进行判断），但也有特殊情况（比如那一天游戏就是要冲在线）要冲PCU的方法也很多，比如 XX点上线送XXX
XX点开始世界BOSS活动等等，总之在做限时活动之前一定要摸清PCU特性再下手！注意下图是一天之内的PCU曲线！一般两个峰值是中午和晚上=========这条线下面就是大家喜闻乐见的收费部分了=====================1.付费总额：这个值不需要多解释了吧，就是游戏里一共消费了多少钱，一般有按天看、按周看、按月看甚至看年看。不夸张的说，这个数据是大家最喜闻乐见并且最关注的了。这里要提一下的是，付费总额一般有：充值付费总额 和 消费总额。这两项是完全不同的，每个游戏的着重点也有所不同，但许多游戏会把充值付费总额与消费总额打通，理论上讲，充值付费总额就是玩家把rmb充到了你的游戏里成为了虚拟货币，并且在非特殊情况下不会倒回成rmb。消费总额就是玩家已经把rmb充到你的游戏里并且已经消费掉了rmb转化为的虚拟货币，从而购买了游戏内的服务。而现在大多数付费总额的数据一般显示的是 充值付费总额（因为可以把虚拟货币也算作购买了游戏内的服务），只有当需要控制游戏内道具产出等情况时，才会单独的来看消费总额。上面这张图就是我大致画的付费总额在一个月内的走势，简单来说就是月初和月底会比较高一点，原因一般是每个月都有收费考核。。那时候如果收费没达标会做些比较猛的收费活动拉一拉（苦了收费运营策划了），而且很多游戏有包月制的概念，会让月初的高点更加明显。另外，在节假日/年底/双11 等促销性质比较浓郁的节点，付费总额也会非常高，特别年底，如果配合合适的运营活动，往往付费的上涨幅度会远远超过登陆人数的上涨幅度。2.ARPU：一个被经常提在嘴边的数据项，可能因为它洋气的发音或者不是那么吓人的数量级。中文全称：每用户平均收入。即，付费总额/登陆付费用户数ARPU显示的是玩家在游戏中的付费能力，作为一个比值的数值，他能很精确的反映游戏的收费品质。一般，越硬核、系统玩法越深的游戏ARPU会越高，现在主流页游ARPU在200+的都很正常。同时，ARPU也显示了游戏所在平台的用户付费能力。若游戏长时间出现ARPU持续减弱的情况，一般原因是游戏内的“坑”快被填满了，这时候可以考虑出新的有深度的系统。3.付费率：即，登陆用户/登陆付费用户数，付费率与ARPU值一起决定了付费总额。也就是说，如果想提高一个游戏的付费总额有两种方法：拉升ARPU或拉升付费率。对比与ARPU，越轻度、系统玩法越休闲的游戏付费率会越高，一般主流页游的付费率在10%左右。拉高付费率最简单的方法是做首充活动，这也是为什么现在几乎所有的游戏都有首充礼包。另外作为产品经理，还要特别关注的是新手玩家的付费率，这个值由游戏品质与平台质量一起决定，如何在新手玩家中合理的推送付费信息、安排在多少级出现第一个付费门槛都是需要在游戏初期就设定好，之后慢慢调整的。这里放个链接更直观的说明现在ARPU与付费率的平均水平：至此我觉得该讲的也差不多了，剩下零零散散的比如：新手流失率分析、道具销售统计等等都比较细致，有时间再更看看，下面主要讲一下自己偏爱的查看处理数据方式，可能会更切题干一些。============================================================楼主问到对游戏内的数值需要了解多少，这里举个小栗子游戏内付费道具定价问题：首先有一天，你从道具销售统计中看出某些道具的销量非常好/糟糕，然后想怎么会呢？之后追根溯源，以调整这些道具的定价或者进行促销来修正或优化这个道具的销量来达到最大营收。在这种情况下，作为产品经理就必须知道，这个道具的定价是如何定的，如果这个定价本身就是你定的，那么恭喜，你可以跳过这段了；如果不是，那惨了，希望你找到那个定价的策划，如果他不见了或者和你说他只是拍脑袋想的这个价格，那么你的悲剧就开始了。你需要重新对这个道具进行审视，是否需要对其重新定价以拉高它的销售额。关于如何给道具定价，已经牵涉到了许多游戏内的数值问题了，这里面有太多种方法，网上都能搜到，估计知乎里也会有，这边就不多说了，但肯定的是，你一定得了解游戏的数值体系才能准确的给道具定价。这只是个小栗子，总的来说，你要对游戏内的数值有一定了解，但是不需要精通到数值策划的深度，毕竟他是数值的作者，而你只要读懂数值就行了。Excel应掌握到什么程度：这个说实话还真的很难回答，公司和公司之间差太多太多，这样说吧，有的公司会有专业的数据分析师做好数据分析表格给你，你要做的就是泡杯咖啡打开outlook收附件就行，所有的数据处理甚至结论都会在里面。次一步的，会提供实时查看各数据曲线的平台，这也不需要你有多少的excel能力，因为都帮你处理好了。最差的，只是给你拉到每天的数据，要你自己做excel，也就是说你一个人兼任了产品经理与数据分析师的双重使命，那么excel对你来说就是非常重要的工具了。从我自己的经验来说，不需要非常精通（这个非常精通的定义等级是数值策划~）。主要还是看做给谁看，如果只是自己看，那要拉出所有的曲线是分分钟的事情。如果要给老板/同事/媒体/投资人
看，那美观和排版也尤为重要，这就要求比较高了。但不管怎样，一定要有自己的数据模板，这样能让你处理数据的效率事半功倍。具体模板每个人都不一样，楼主有兴趣可以单m我。关于看数据的节奏，我自己习惯的是每周专门腾出大半天来做分析，如果有哪项的上涨/下降比上周超过5%了就会寻找解决方案，同时每个月拿月整体数据和去年的和上月的做对比，更清楚游戏的大走势。最后还是想再强调一遍，游戏数据只能帮助发现游戏的问题，重要的是掌握怎么解决问题！
我来尝试回答一下楼主所提的问题吧。本人游戏策划，入行业一年有余，回答仅提供参考方向。
首先，一般来讲，游戏大部分只关心两个数据，留存和付费。在这两个点上，做一些深入的分析可能会有所收获。
对于游戏产品来讲，在游戏的前期，留存很重要，对于平台，一般看是次是留存和七日留存。有些会看月留存。次日在40%，七日在18%以上都还算留存做得不错的产品了。对于留存的分析，一般存在用用户的等级线来区分，举例来讲，如果一个游戏的一个服在开了10天左右了，经过数值计算，这时候玩家的等级一般都能达达30-40级了，再拉一下玩家等级表，1级的20个，2级的30个，3级的22个，4级的59......8级的时候200个，9级的110个....等等，然后算一个等级区域占比，就能知道每个等级的的流失比了，然后再来游戏里面看看， 这个等级区域玩家在做什么，为什么不继续玩了，感同身受一下，再看看其他游戏做些对比，结合玩家的一些反馈，改吧！
对于付费来讲的话，提供一些数据参考吧，付费率在5%、付费Arpu在150以上，人均ARPU在7块以上，应该算还不错的产品了。做付费的话，在首充上一定要给足够的诱惑和独一无二的付费感觉。然后对于长期的一个付费收信的话，很多游戏都是通过做活动来增加了，一句话，就是活动不能停，药不能停。隔三差五的做一波活动，逢年过节地大做活动，然后看一些同类活动，相较参考活动的花样，相信付费也会活起来。另外的话，我还是比较追崇一个好的游戏，并不要靠活动的去刺激的，活动只是兴奋剂，好的付费还是做在游戏的日常消耗上最好最省事。另外，对于付费做的好的游戏，一定是客户关系维护得好的游戏，要时常保持与付费用户的联系，问问他们的一些建议和掓，有新活动了，有新优惠了，定在提前通知他们，告诉他们好消息来了！每一波活动过后，要问问他们为什么不充值为什么充值的一些想法，便于下次做活动。这叫信息反馈收集。90%收入都是来自大R，其他的都是屌丝收入。一个没做好的游戏，一定是不了解自己客户群的游戏。
对于其他来说的话，比如在线，也就是DAU，一般通过世界Boss战，军团战，活动副本等等来作的，多说一点，对于好的游戏战斗一定是做得很炫的，战斗是有微操作的，战斗时间也是比较长的，这也是对于做在线提供的一个思路吧。
对于数值来讲的话，一般你需要什么你就去问就好了，没有什么你必须得知道的数值，有些东西只有在你遇到了才会知道需要，不去做是不知道 自己缺少什么的数值的。比如要做留存，你得知道玩家一天能升到多少级吧，三天能升到多少级吧等等，对于产品方面，我觉得你最好知道每个系统是干什么的产什么的就够了，数值什么的好像也不会用得到太多。
Excel什么的，能做一些图表，能算一些基本公式 ，能做表格，其他的，用到时，百度一下不就解决了吗？
最后，没想到自己能说这么多，有些不到之处，望 同行海涵。
另：本人做的是手机游戏行业，对于页游、端游的话，可能有些经验不太适用，自己看看就好，不必纠结太多。《七雄争霸》游戏服务器数据库的设计与实现_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
《七雄争霸》游戏服务器数据库的设计与实现
游​戏​服​务​器​数​据​库​的​设​计​与​实​现​ ​毕​业​设​计
阅读已结束，如果下载本文需要使用
想免费下载本文？
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢}