游戏服务端架构介绍
类型1：卡牌、跑酷等弱交互服务端
卡牌跑酷类因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：
登录时可以使用非对称(RSA, DH)，服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信，并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为，来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。
每局开始时，访问一下，请求一下关卡数据，玩完了又提交一下，验算一下是否合法，获得什么奖励，用单台 MySQL或者 MongoDB即可，后端的 Redis做缓存(可选)。如果要实现通知，那么让客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒;如果有消息，就缩短轮询时间到10秒，5秒，即便两人聊天，延迟也能自适应。
此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余，这类游戏因为逻辑简单，玩家之间交互不强，使用 HTTP来开发的话，开发速度快，调试只需要一个就可以把逻辑调试清楚了。
类型2：第一代游戏服务器 1978
1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》，在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家，甚至包括国外的玩家。《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本，至此MUD才在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS(1991)，成为众多网游的鼻祖：
MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互(聊天，交易，PK)，MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象(网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC)。
游戏世界采用房间的形式组织起来，每个房间有东南西北四个方向可以移动到下一个房间，由于欧美最早的网游都是地牢迷宫形式的，因此场景的基本单位被成为 &房间&。MUDOS使用一门称为LPC的脚本语言来描述整个世界(包括房间拓扑，配置，NPC，以及各种剧情)。游戏里面的高级玩家(巫师)，可以不断的通过修改脚本来为游戏添加房间以及增加剧情。早年 MUD1上线时只有17个房间，Roy Trubshaw毕业以后交给他的师弟 Richard Battle，在 Richard Battle手上，不断的添加各种玩法到一百多个房间，终于让 MUD发扬光大。
用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。比如 1995年国内第一款 MUD游戏《侠客行》，你敲入：&go east&，游戏就会提示你：&后花园 - 这里是归云庄的后花园，种满了花草，几个庄丁正在浇花。此地乃是含羞草生长之地。这里唯一的出口是 north。这里有：花待 阿牧(A mu)，还有二位庄丁(Zhuang Ding)&，然后你继续用文字操作，查看阿牧的信息：&look a mu&，提示：&花待 阿牧(A mu)他是陆乘风的弟子，受命在此看管含羞草。他看起来三十多岁，生得眉清目秀，端正大方，一表人才。他的武艺看上去【不是很高】，出手似乎【极轻】&。然后你可以选择击败他获得含羞草，但是你吃了含羞草却又可能会中毒死亡。在早期网上资源贫乏的时候，这样的游戏有很强的代入感。
用户数据保存在文件中，每个用户登录时，从文本文件里把用户的数据全部加载进来，操作全部在内存里面进行，无需马上刷回磁盘。用户退出了，或者每隔5分钟检查到数据改动了，都会保存会磁盘。这样的系统在当时每台服务器承载个4000人同时游戏，不是特别大的问题。从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，退出新版本，随着 Windows图形机能的增强。1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标，为每个房间增加了地图，并且为每个角色增加了动画，形成了第一代的图形网络游戏。
因为游戏内容基本可以通过 LPC脚本进行定制，所以MUDOS也成为名副其实的第一款服务端引擎，引擎一次性开发出来，然后制作不同游戏内容。后续国内的《万王之王》等游戏，很多都是跟《UO》一样，直接在 MUDOS上进行二次开发，加入房间的地图还有角色的坐标等要素，该架构一直为国内的第一代 MMORPG提供了稳固的支持，直到 2003年，还有游戏基于 MUDOS开发。
虽然后面图形化增加了很多东西，但是这些MMORPG后端的本质还是 MUDOS。随着游戏内容的越来越复杂，架构变得越来越吃不消了，各种负载问题慢慢浮上水面，于是有了我们的第二代游戏服务器。
类型3：第二代游戏服务器 2003
2000年后，网游已经脱离最初的文字MUD，进入全面图形化年代。最先承受不住的其实是很多小文件，用户上下线，频繁的读取写入用户数据，导致负载越来越大。随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。同时早期 EXT磁盘分区比较脆弱，稍微停电，容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去。
此时游戏服务端已经脱离陈旧的 MUDOS体系，各个公司在参考 MUDOS结构的情况下，开始自己用 C在重新开发自己的游戏服务端。并且脚本也抛弃了 LPC，采用扩展性更好的 或者 Lua来代替。由于主逻辑使用单线程模型，随着游戏内容的增加，传统单服务器的结构进一步成为瓶颈。于是有人开始拆分游戏世界，变为下面的模型：
游戏服务器压力拆分后得意缓解，但是两台游戏服务器同时访问数据库，大量重复访问，大量数据交换，使得数据库成为下一个瓶颈。于是形成了数据库前端代理(DB Proxy)，游戏服务器不直接访问数据库而是访问代理，再有代理访问数据库，同时提供内存级别的cache。早年 MySQL4之前没有提供存储过程，这个前端代理一般和 MySQL跑在同一台上，它转化游戏服务器发过来的高级数据操作指令，拆分成具体的数据库操作，一定程度上代替了存储过程：
但是这样的结构并没有持续太长时间，因为玩家切换场景经常要切换连接，中间的状态容易错乱。而且游戏服务器多了以后，相互之间数据交互又会变得比较麻烦，于是人们拆分了网络功能，独立出一个网关服务 Gate(有的地方叫 Session，有的地方叫 LinkSvr之类的，名字不同而已)：
把网络功能单独提取出来，让用户统一去连接一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。这样类型的服务器基本能稳定的为玩家提供游戏服务，一台网关服务1-2万人，后面的游戏服务器每台服务5k-1w，依游戏类型和复杂度不同而已，图中隐藏了很多不重要的服务器，如登录和管理。这是目前应用最广的一个模型，到今天任然很多新项目会才用这样的结构来搭建。
人都是有惯性的，按照先前的经验，似乎把 MUDOS拆分的越开性能越好。于是大家继续想，网关可以拆分呀，基础服务如聊天交易，可以拆分呀，还可以提供web接口，数据库可以拆分呀，于是有了下面的模型：
这样的模型好用么?确实有成功游戏使用类似这样的架构，并且发挥了它的性能优势，比如一些大型 MMORPG。但是有两个挑战：每增加一级服务器，状态机复杂度可能会翻倍，导致研发和找bug的成本上升;并且对开发组挑战比较大，一旦项目时间吃紧，开发人员经验不足，很容易弄挂。
比如我见过某上海一线游戏公司的一个 RPG上来就要上这样的架构，我看了下他们团队成员的经验，问了下他们的上线日期，劝他们用前面稍微简单一点的模型。人家自信得很，认为有成功项目是这么做的，他们也要这么做，自己很想实现一套。于是他们义无反顾的开始编码，项目做了一年多，然后，就没有然后了。
现今在游戏成功率不高的情况下，一开始上一套比较复杂的架构需要考虑投资回报率，比如你的游戏上线半年内 PCU会去到多少?如果一个 APRG游戏，每组服务器5千人都到不了的话，那么选择一套更为贴近实际情况的结构更为经济。即使后面你的项目真的超过5千人朝着1万人目标奔的话，相信那个时候你的项目已经挣大钱了 ，你数着钱加着班去逐步迭代，一次次拆分它，相信心里也是乐开花的。
上面这些类型基本都是从拆分 MUDOS开始，将 MUDOS中的各个部件从单机一步步拆成分布式。虽然今天任然很多新项目在用上面某一种类似的结构，或者自己又做了其他热点模块的拆分。因为他们本质上都是对 MUDOS的分解，故将他们归纳为第二代游戏服务器。
类型4：第三代游戏服务器 2007
从魔兽世界开始无缝世界地图已经深入人心，比较以往游戏玩家走个几步还需要切换场景，每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说，无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了：
每台 Node服务器用来管理一块地图区域，由 NodeMaster(NM)来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器，比如传统数据库前端，登录服务器，日志和监控等，统统用 ADMIN概括。在这样的结构下，玩家从一块区域走向另外一块区域需要简单处理一下：
玩家1完全由节点A控制，玩家3完全由节点B控制。而处在两个节点边缘的2号玩家，则同时由A和B提供服务。玩家2从A移动到B的过程中，会同时向A请求左边的情况，并向B请求右边的情况。但是此时玩家2还是属于A管理。直到玩家2彻底离开AB边界很远，才彻底交由B管理。按照这样的逻辑将世界地图分割为一块一块的区域，交由不同的 Node去管理。
对于一个 Node所负责的区域，地理上没必要连接在一起，比如大陆的四周边缘部分和高山部分的区块人比较少，可以统一交给一个Node去管理，而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块，可以根据游戏实时运行的负载情况，定时维护的时候进行更改 NodeMaster 上面的配置。
于是碰到第一个问题是很多 Node服务器需要和玩家进行通信，需要问管理服务器特定UID为多少的玩家到底在哪台 Gate上，以前按场景切割的服务器这个问题不大，问了一次以后就可以缓存起来了，但是现在服务器种类增加不少，玩家又会飘来飘去，按UID查找玩家比较麻烦;另外一方面 GATE需要动态根据坐标计算和哪些 Node通信，导致逻辑越来越厚，于是把：&用户对象&从负责连接管理的 GATE中切割出来势在必行于是有了下面的模型：
网关服务器再次退回到精简的网络转发功能，而用户逻辑则由按照 UID划分的 OBJ服务器来承担，GATE是按照网络接入时的负载来分布，而 OBJ则是按照资源的编号(UID)来分布，这样和一个用户通信直接根据 UID计算出 OBJ服务器编号发送数据即可。而新独立出来的 OBJ则提供了更多高层次的服务：
& 对象移动：管理具体玩家在不同的 Node所管辖的区域之间的移动，并同需要的 Node进行沟通。
& 数据广播：Node可以给每个用户设置若干 TAG，然后通知 Object Master 按照TAG广播。
& 对象消息：通用消息推送，给某个用户发送数据，直接告诉 OBJ，不需要直接和 GATE打交道。
& 好友聊天：角色之间聊天直接走 OBJ/OBJ MASTER。
整个服务器主体分为三层以后，NODE专注场景，OBJ专注玩家对象，GATE专注网络。这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移，负载问题也越来越明显，做个活动，远来不活跃的区域变得十分活跃，靠每周维护来调整还是比较笨重的，于是有了动态负载均衡。
动态负载均衡有两种方法，第一种是按照负载，由 Node Master 定时动态移动修改一下各个 Node的边界，而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上：
图11 动态负载均衡
这样 Node Master定时查找地图上的热点区域，计算新的场景切割方式，然后告诉其他服务器开始调整，具体处理方式还是和上面对象跨越边界移动的方法一样。
但是上面这种方式实现相对复杂一些，于是人们设计出了更为简单直接的一种新方法：
图12 基于网格的动态负载均衡
还是将地图按照标准尺寸均匀切割成静态的网格，每个格子由一个具体的Node负责，但是根据负载情况，能够实时的迁移到其他 Node上。在迁移分为三个阶段：准备，切换，完成。三个状态由Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据，完成后告诉NM;NM确认OK后同时通知新旧 Node完成切换。完成切换后，如果 Obj服务器还在和老的 Node进行通信，老的 Node将会对它进行纠正，得到纠正的 OBJ将修正自己的状态，和新的 Node进行通信。
很多无缝动态负载均衡的服务端宣称自己支持无限的人数，但不意味着 MMORPG游戏的人数上限真的可以无限扩充，因为这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最大广播上限，而客户端性能决定了同一个屏幕到底可以绘制多少个角色。
从无缝地图引入了分布式对象模型开始，已经完全脱离 MUDOS体系，成为一种新的服务端模型。又由于动态负载均衡的引入，让无缝服务器如虎添翼，容纳着超过上一代游戏服务器数倍的人数上限，并提供了更好的游戏体验，我们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端，RPG网游在相当长的时间里一度占据90%以上，使得基于 MMORPG的服务端架构得到了蓬勃的发展，然而随着玩家对RPG的疲惫，各种非MMORPG游戏如雨后春笋般的出现在人们眼前，受到市场的欢迎。
类型5：战网游戏服务器
经典战网服务端和 RPG游戏有两个区别：RPG是分区分服的，北京区的用户和广州区的用户老死不相往来。而战网，虽然每局游戏一般都是 8人以内，但全国只有一套服务器，所有的玩家都可以在一起游戏，而玩家和玩家之使用 P2P的方式连接在一起，组成一局游戏：
玩家通过 Match Making 服务器使用：创建、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一个人做 Host，其他人 P2P连接到做主的玩家上来。STUN是帮助玩家之间建立 P2P的牵引服务器，而由于 P2P联通情况大概只有 75%，实在联不通的玩家会通过 Forward进行转发。
大量的连接对战，体育竞技游戏采用类似的结构。P2P有网状模型(所有玩家互相连接)，和星状模型(所有玩家连接一个主玩家)。复杂的游戏状态在网状模型下难以形成一致，因此星状P2P模型经受住了历史的考验。除去游戏数据，支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上，通过混音去重再编码的方式返回给所有用户。
战网类游戏，以竞技、体育、动作等类型的游戏为主，较慢节奏的 RPG(包括ARPG)有本质上的区别，而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略，这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出，那在到处都是的今天，如何保证游戏结果的公正呢?
主要方法就是投票法，所有客户端都会独立计算，然后传递给服务器。如果结果相同就更新记录，如果结果不一致，会采取类似投票的方式确定最终结果。同时记录本剧游戏的所有输入，在可能的情况下，找另外闲散的游戏客户端验算整局游戏是否为该结果。并且记录经常有作弊嫌疑的用户，供运营人员封号时参考。
类型7：休闲游戏服务器
休闲游戏同战网服务器类似，都是全区架构，不同的是有房间服务器，还有具体的游戏服务器，游戏主体不再以玩家 P2P进行，而是连接到专门的游戏服务器处理：
和战网一样的全区架构，用户数据不能象分区的 RPG那样一次性load到内存，然后在内存里面直接修改。全区架构下，为了应对一个用户同时玩几个游戏，用户数据需要区分基本数据和不同的游戏数据，而游戏数据又需要区分积分数据、和文档数据。胜平负之类的积分可以直接提交增量修改，而更为普遍的文档类数据则需要提供读写令牌，写令牌只有一块，读令牌有很多块。同帐号同一个游戏同时在两台电脑上玩时，最先开始的那个游戏获得写令牌，可以操作任意的用户数据。而后开始的那个游戏除了可以提交胜平负积分的增量改变外，对用户数据采用只读的方式，保证游戏能运行下去，但是会提示用户，游戏数据锁定。
类型8：现代动作类网游
从早期的韩国动作游戏开始，传统的战网动作类游戏和 RPG游戏开始尝试融合。单纯的动作游戏玩家容易疲倦，留存也没有 RPG那么高;而单纯 RPG战斗却又慢节奏的乏味，无法满足很多玩家激烈对抗的期望，于是二者开始融合成为新一代的：动作 + 城镇 模式。玩家在城镇中聚集，然后以开副本的方式几个人出去以动作游戏的玩法来完成各种 RPG任务。本质就是一套 RPG服务端+副本服务端。由于每次副本时人物可以控制在8人以内，因此可以获得更为实时的游戏体验，让玩家玩的更加爽快。
说了那么多的游戏服务器类型，其实也差不多了，剩下的类型大家拼凑一下其实也就是这个样子而已。游戏服务端经历了那么多结构上的变迁，内部开发模式是否依然不变?究竟是继续延续传统的开发方式?还是有了更多突破性的方法?经历那么多次架构变迁，后面是否有共通的逻辑?未来的发展还会存在哪些困难?游戏服务端开发如何达到最终的彼岸?请看下节：技术的演进。
技术的演进
从目前流行的开源游戏服务端框架来分析：
网易pomelo 属于 第二代游戏服务端 五型的架构，即图7的架构。
skynet因为是一个服务端框架，官方只是提供了login server 和 gate server的参考实现，其他的需要自己来实现，的自由度变大了，架构完全取决于程序员自己的选择，程序员可以自己尝试去实现第二代的架构，也可以实现第三代的架构。注意: skynet仅仅是框架，其他属于完整解决方案。
Kbengine属于第三代服务端框架，可能类似于图10。(这个理解不确定)
Kbengine引擎应该是对图10中的Gate服务器和NODE和OBJ进行了细分。在功能上大体划分为与位置有关(在Kbengine中称为Cellapp)和与位置无关(在Kbengine中称为Baseapp)。类似于下面的示图架构。后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
游戏服务器和一般服务器对比，有何特别？
文/wadehan
image001.jpg (26.87 KB, 下载次数: 37)
11:16 上传
　　在中国的互联网诸多业务领域中，游戏一直是充当“现金牛”而存在的。但是，在游戏服务器端开发领域中的很多重要问题，并没有被明确的分辨出其特异性，从而得到专门的对待。我们不管是在业界开源领域，还是内部分享中，很少会有专门针对游戏业务特征进行专门设计的组件、类库或者框架。我们从游戏的客户端方面来看，一款专业的游戏客户端引擎，已经是游戏开发的标配，比如最早的Flash Builder，到后期的Cocos2d-X，Unity，Unreal；但是服务器端，我们几乎找不到同样重量级的产品。
　　在游戏服务器端开发所有要面对的问题中，有两个是最核心和最普遍的：一是和客户端的通讯；二是游戏登录用户的数据处理。对于和客户端通讯的这个问题，大量的游戏开发者会使用“通用”的开源组件，比如Protocol Buffer，Thrift，Jetty，Node.js等等通信或RPC框架。虽然针对游戏，还是要做大量的改造，但一般都有很多现成的代码可供修改。
　　在一般的互联网应用中，我们一般认为服务都是通过请求-响应的方式来完成的。而在游戏业务领域中，请求-响应可以看成是一种类型的通讯方式，但还有另外一种重要的通讯模型，就是“数据同步”方式：游戏中某个角色的HP、位置坐标改变了，需要在客户端和服务器之间、客户端和客户端之间同步。这造成了一般情况下通信协议的大量增加。
　　对于第二个问题，不管是memcache还是MySQL，或者是Redis，都不能完全满足游戏开发者的需求。很多团队尝试过各种组合和修改，试图创造出利用现有开源软件，建设既能迎合灵活的需求变化，又具备高延迟和高可用的数据处理系统，但最后这些努力基本上都很难圆满成功。因此我们在游戏服务器端代码中，还是充斥着大量的内存、缓存管理，数据同步、落地等等代码。而且每个游戏都要重新去写一遍这些类似的功能，不能不说一种浪费。
　　如果我们要想出一种能满足“游戏”这个业务领域的数据系统设计，那么就一定要搞清楚为什么在如此之多的开源项目和游戏团队中，没能实现完美契合的原因。
　　电子商务/一般互联网业务的C-S通讯流程
　　基于WebService类型的通讯模型，现在基本已经成为互联网开源组件的标准。由此而诞生的RESTful API，或者各种RPC模型，其实都是基于这样的客观事实：
image002.jpg (7.46 KB, 下载次数: 33)
11:16 上传
　　l&&用户主动请求，服务器产生回应。典型的就是网页的点击、表单的提交。
　　l&&主动通知的消息，仅仅是提示用户发起查询请求。比如在APP按钮上的小红点，消息页的数字提示等等，这些主动通知都是为了通知用户去刷新页面。
image003.jpg (7.36 KB, 下载次数: 33)
11:16 上传
　　游戏类业务的通信模型
　　游戏中的通信，一般和操作有关。这些操作一般分为两类：
　　l&&UI面板类操作
　　l&&战斗场景操作
　　这两者的最大区别，就是UI面板类操作一般无需让其他玩家看见。而战斗场景操作则需要广播给所有玩家看到。
image004.jpg (90.44 KB, 下载次数: 35)
11:16 上传
image005.jpg (44.42 KB, 下载次数: 36)
11:16 上传
　　在第二种情况下，一般就不是客户端主动发起，而是服务器端直接推送实际数据，然后客户端直接显示这些数据。这个模式和简单的“推送”还不一样，而应该更进一步，是一种从服务器端发起的，向客户端“同步”数据的请求。
　　因此，一个好的游戏服务器端框架，应该是能同时支持请求-响应模型和“推送同步”模型的。
　　电子商务/一般互联网类业务的数据处理流程
　　Memcache、Redis、MySQL在一般互联网业务中的应用非常广泛。而且基本上能很好的应对各种常见的应用场景，包括类似BBS的社区、新闻门户、电子商务类系统。在企业内部信息系统中（Intranet），这一类数据软件也能发挥非常好的功效。由于电子商务类是其中最复杂的系统，所以我在这里以此为例说明，一般数据处理的流程是如何的。
image006.jpg (63.8 KB, 下载次数: 35)
11:16 上传
　　假设我们浏览了一个网店，选中了一个商品，点击了下单这个流程，实际上需要的后台流程可能是下图所示：
image007.gif (9.55 KB, 下载次数: 36)
11:16 上传
　　从上面的分析大概可以总结出几个特点：
　　一、忍受延迟：每个操作的延迟要求较低，操作频率不会太高。一般我们页面在5秒内打开，都不会引起太多客户的抗议。所以，就算我们处理一个请求的时候，后台进行多次的进程间调用，产生的延迟和带宽消耗也是可以忍受的。
　　二、在线交互少：互联网业务大多数是基于浏览器的，所以在线用户之间很少实时交互。
　　三、数据分散：一般来说，互联网应用的数据可以在多个不同的业务系统中共用，但是需要专门的业务模块来做管理，以维持数据的一致性。
　　四、数据变更面广：系统需要持续处理很多数据变更，互联网业务有很大一部分数据是来源于普通用户、网络编辑、店主等等使用者，在使用的过程中，他们会大量的修改系统所存储的数据。
　　以上四个特点，导致了我们一般会把后台要处理的数据，分别用Cache系统和DB系统来处理。并且，我们一般会按业务功能划分模块，同时也划分业务系统。由于延迟和在线交互的需求较弱，所以使用大量进程来做模块隔离，依然是非常可行的，总体来说，就是一种比较“分散”的数据使用方式。
　　游戏类业务的数据处理流程
　　在各种游戏中，MMORPG是数据处理最为复杂的一类，也是最典型的一种“重服务器端”的游戏类型，因此可以作为游戏业务中通用性的参考标准。在MMORPG中，我们可以发现，数据的处理需求，和一般互联网业务大相径庭，它体现出的是一种明显的“集中”式的数据处理需求。我们可以从一般MMORPG的服务器架构中体现出来：
image008.gif (18.86 KB, 下载次数: 34)
11:16 上传
　　在游戏业务中，一般我们都会发现以下的特点：
　　一、延迟敏感：游戏中用户会产生大量操作，都要求“实时”进行反馈，所以一般都不能忍受1秒以上的延迟，在大量动作类型的游戏中，一般都会要求服务器的反馈时延在50ms左右。因此游戏开发者都习惯于尽量减少后台进程间的交互，尽管这对提高系统吞吐量很不利。所以大部分游戏服务器端都有一个所谓“GameServer”，里面运行了游戏70%以上的功能。
　　二、大量实时交互：在线游戏的特点，就是很多玩家可以通过服务器“看见”彼此，能实时的互动。因此我们必须要把用户的在线数据，集中到一起，才能提供互相操作的可能；而且A用户操作B用户的数据，是最常见的数据操作，所谓战斗玩法，就是互相修改对方的数据的过程。
　　三、数据集中：游戏是一个几乎完全虚拟的世界，在游戏中的数据，实际上很少能在其他系统中产生价值。而游戏逻辑也禁止通过游戏以外的方式，修改游戏的数据。所以游戏中的数据，一般都会集中存放在单独的数据库中。由于没有数据共用的需求，所以也不需要把GameServer里面集中的逻辑划分出很多单独的进程模块来。
　　四、数据变更少：实际上游戏的数据变更还是很快的，比如游戏中的每次中弹，都要减少HP的数值。但是游戏里的数据，一般都遵守这样一个规则：“变化越快的数据，重要性越低”。也就是说，游戏中是可以容忍一定程度的数据不一致和不完整的。而游戏中的数据，一般会分成两类：玩家存档和游戏设置。对于玩家存档来说，其单条数据量一般不大，但会有大量的记录数，因为每个玩家都会有一个存档。但是其读取、修改，一般很典型的和玩家的登录、登出、升级等业务逻辑密切关联，所以其缓存时机是比较容易根据业务逻辑来把握的。而对于游戏设置数据来说，几乎只有升级游戏版本的时候才会修改，大部分运行时是只读的，其缓存简单的读入内存就解决问题了。
　　一般的缓存系统的特点在游戏中的问题
　　根据以上的分析，我们可以看到，普通的缓存系统，如memcache和Redis，实际上其特点是不太适合游戏业务的：
　　l&&一般跨进程的缓存系统，无法解决游戏要求的低延迟问题。级别是同机房，每次数据存取都需要10-20ms的时间，对于游戏战斗中大量的数据读、写来说，是很难接受的。（但是一些回合制战斗、低频操作还是有用的）
　　l&&通用型的缓存系统或者数据库，一般都比较难集结多个进程，形成一个完整的数据存储网格。这让玩家间的互相交互产生了额外的难度，开发者必须先想办法确定玩家的数据在哪个后台进程上，然后才能去读写。一般的数据库或缓存系统，为了保证数据的一致性或者完整性，往往会需要牺牲一些分布式的能力。而这种牺牲在游戏业务中，其实是一种浪费，因为游戏的很多数据都无需这种能力。
　　l&&通用性数据系统一般不依赖于特定的语言，所以很少能直接把某种“对象”存入到数据系统中。在游戏开发中，需要存储的数据结构数量往往是非常大量的：一个普通的游戏，基本上都会超过100种数据结构。对于每个数据结构，都去建表或者编写序列化/反序列化配置，是一种非常累人的工作。--明明在代码中，已经用编程语言定义了他们的结构，还要重复的搞一次。
　　根据上面说的这些问题，我们实际上是需要另外一种完全不同设计思想的数据系统。
　　对于游戏业务来说，一个好用的数据系统，应该包括这样一些特点：
　　l&&可以利用GameServer进程内的内存进行自动化的缓存管理。由于GameServer进程往往集中了大部分的逻辑运算，所以大部分的数据缓存也应该在这个进程中，这样才能符合游戏所需的延迟要求。
　　l&&自动进行数据落地和容灾管理。由于游戏数据中有大量的“过程数据”，所以其一致性和完整性要求会稍微低于其他业务，所以应该利用这一点，让GameServer本身也可以是分布式的程序，从而提高系统整体的吞吐量。
　　l&&具备良好的编程易用性。最好是能直接存取编程中的对象，避免反复对数据结构的描述，节省大量的开发时间。
　　游戏服务器和普通互联网业务服务器端，最大的区别实际上就在于“状态”。游戏服务器的状态是实时快速变化的、可以容忍丢失的、需要大量广播同步的；普通互联网业务服务器的状态一般是持久化的、不容忍丢失的、只和特定客户端相关的。所以一个好的游戏服务器框架，在通讯和数据这两个基本层面，会和一般我们所接触的开源组件有很大的差异。这也是作为游戏服务器端开发者，需要去共同建设行业标准的地方。
关注我们官方微信公众号
下载我们官方APP-游戏行
关注手游动态微信公众号
楼主总结得很详细！
只是一般互联网业务服务器与游戏服务器应用场景完全不同。
请古天乐、张家辉等港台明星代言页游，真的周鸿祎：我的第一次创业失败你知道FC游戏为了节省容量用了多少怪招吗？A站要凉？经历凶险12小时：融资不畅员工抱艾瑞：战术竞技类手游市场洞察多人游戏关卡设计视觉化指南
微信扫一扫关注我们→