一般地，会把游戏服务器的架构划分如下三层：网络接入层、游戏逻辑层、数据存储层，这样划分的主要目的是：
将底层通信与业务逻辑处理解耦合；将业务逻辑处理与数据存储解耦合；有利于运营部署与扩展；游戏服务器开发框架整体视图，如下所示：
2网络接入层网络接入层主要任务是解决来自客户端大量并发请求和负载均衡的处理，考量该层的主要性能指标是：高吞吐、低延迟、均负载，即既能同一时刻处理大批量的客户端请求（每秒至少1万个请求以上），又能快速响应，并且均负载的分布处理这些请求。
本层的基本技术要点如下图所示：
低成本：有成熟的开源webserver；快速开发的效率：一请求一应答的协议通讯，使用游戏逻辑处理相当简单；低门槛：基于web的应用，玩家无需下载客户端，也不用担心防火墙等问题；（2）不足
难以处理服务器广播事件；文本协议会占用较大流量；2.1.2socket接入（1）优点
功能强大：能灵活处理服务器广播事件；高效通信：二进制协议较文本协议能大幅度节省带宽，并且通信包可做组播等处理，以有效降低流量；（2）不足
目前，这块公司和开源界都有很成熟的解决方案，故在此不多赘述。
3.1基础系统基础系统包含的内容基本上为各个游戏业务逻辑所公有的东西。
4数据存储层数据存储层是整个服务器的关键基础系统之一，因为游戏服务器的核心功能之一就是存取玩家数据。游戏类型不同，对数据的存取需求也不一样，对于传统客户端MMORPG而言，一般采用Mysql作数据持久化，然后在Mysql与GameSvr中间实现一个ORM的服务提供数据的代理或缓存即可。而新兴的SocialGame和强交互的WebGame，则选择用NoSql来替代Mysql，以满足其超大规模IO并发的需求。如下图所示：
4.2NoSqlNoSql，指的是非关系型的数据库，它可以满足对数据库的高并发读写、对海量数据的高效率存储和访问，以及对数据库的高可扩展性和高可用性等需求，它是随着SNS和Web2.0的兴起而产生的新兴存储技术。对于游戏而言，目前它主要应用于SocialGame和强交互的WebGame中。
5通用组件库通用组件库是指那些与具体业务无关的，能应用于所有服务器开发的组件库。目前，我们所积累的可归纳如下图所示：
5.1后台服务应用框架后台服务应用框架规范了进程的起停方式、信号处理、命令行参数等操作，框架本身实现了一个daemon服务所必备的消息主循环、reload机制，以及定时器处理等功能。
5.3进程间通讯组件进程间的通讯也是服务器的核心基础功能之一，高效的进程间通讯是服务器性能的基本保障，进程间通讯组件需要实现同机器与跨机器的进程高效通讯。
5.4消息打包组件在许多通信程序中，需要定义一套网络协议，并需要根据网络协议对协议数据单元（PDU）进行Pack/Unpack，以实现可移植性和网络传输的可靠性及效率。但是对协议数据单元进行Pack/Unpack是一个重复性很强的操作，繁琐而且容易出错（Pack和Unpack容易不匹配）。而消息打包组件则简化了网络协议的制定，使得业务应用不用关心协议的Pack/Unpack操作，并且支持良好的数据扩展和协议版本兼容。
发布于手游游戏服务器逻辑框架1背景首先，要回答一个问题：
我们为什么要专门为手机游戏专门定制设计一个游戏服务器逻辑框架？
2现状以stan经历过的工作室里三款游戏为例：微连、微胖和微塔。
三款游戏在业务逻辑处理上，均各自使用不同的一套框架，风格迥异。如果要说相同点，则是均使用C/C++来作业务逻辑的实现。微连和微胖均以tapp作基础来搭建框架，而微塔则是完全自行做的一套后台框架。
考虑到手游开发周期短，迭代速度快，发布频率高等特点，如果延用目前的逻辑框架，无论是上述三款游戏的哪一种，均难以解决如下几个问题：
（1）开发复杂度较高
这里的复杂度包括语言本身的复杂度、开发效率、代码可读/可维护性等。
（2）运维部署代价较高
（3）系统可靠性
有鉴于此，结合业内同行朋友成熟项目的经验，我们选择用Lua与C/C++混合编程的方式来实现游戏业务逻辑。
3新的解决方案新改进的逻辑框架基本可以解决上述提到的三个问题，至于为什么选择用Lua，这个业内基本上已有了一些共识，可以看这里，互娱魔方工作室也有项目已经在应用，看这里。故这个问题在此不再赘述。
接下来，我们探讨一下解决方案的具体实现方法。
3.1边界混合编程面临的一个问题是：如何界定不同语言之间的处理边界。对于我们来说就是，Lua能干什么，该干什么？C/C++需要做什么？
为此，我们在实现需要遵行的一些原则有:
网络消息的收发、加解包、DB读写、日志读写、玩家对象池管理等涉及到有一定CPU开销或底层处理的操作均由C/C++来承担；有复杂交互流程的逻辑，由Lua来实现，如：一个业务协议流程涉及到多个SS交互；有单一重复逻辑的需求，由Lua来实现，如：任务、关卡、副本等；系统配置文件由Lua来实现；其它比较模糊的业务系统，我们会根据如下几个因素来综合权衡：开发效率、性能、两种语言的交互调用频率等；3.2框架外貌（1）GAMESVR加载Lua配置文件进行进程参数以及业务逻辑参数配置；
（2）GAMESVR加载Lua逻辑脚本，根据CS请求，运行不同的逻辑脚本；
（3）GAMESVR可以通过修改Lua逻辑脚本进行热更新；
3.3框架处理流程
3.4Lua配置文件处理思路Lua的一种重要用途是作为配置语言
XML层次分明，写起来太复杂；ini配置不够灵活；其他配置需要自己开发
Lua作为配置文件编写起来简单，解析也方便，更重要的是在Lua协程框架中，很多情况是Lua协程读取配置文件，而不需要其他接口便可直接读取，天然的结合，使用起来非常方便。
遇到的问题：
（1）一份配置文件，C++中需要调用并且Lua业务逻辑脚本中也需要调用如何处理？
在GAMESVR中，建立一个ConfModule，ConfModule加载Lua配置文件到本模块中的Lua虚拟机，并把配置文件需要的字段解析到本模块的成员变量中，对外提供GET接口进行访问，对于LuaTaskMgrModule也同样加载该lua配置文件，方便Lua业务逻辑脚本中的调用。
（2）lua配置文件便捷的解析方式
采用lua_dostring方式，将需要的参数按lua语句方式复制给一个变量，然后通过lua_tostring、lua_tointeger、lua_tonumber将其解析出来，lua_dostring方式速度较慢，但该模块只是在GAMESVR初始化时候解析一次，并将解析出来的数据存入模块的成员变量中，后续数据访问通过提供的GET接口，解析完后关闭lua虚拟机，我们认为该方式在解析速度上可接收。
3.5C++网络收发包处理思路目前GAMESVR中存在三个异步回调点：
TBUSTCAPLUSLIBCURLlua协程框架需要将task_id存入异步交互数据中，并且需要在响应包中能够原封不动的带回该task_id；TBUS可以将task_id放入包头的seq_id字段；TCAPLUS可以通过TcaplusService::TcaplusServiceRequest中的SetAsyncID将task_id存入，并在响应包时，通过TcaplusService::TcaplusServiceResponse的GetAsynID获取task_idLIBCURL需要封装，使得CurlClient支持缓存task_id的机制；
虽然新设计的逻辑框架还有诸多可完善的地方，但初次尝试应用，我们已感受到它带来的变化，比如：重写的好友关系链Server代码量比原来缩减了近三分之一，代码量减少的很明显的好处就是：代码更简洁，可读性更高（客观说，微塔原来的代码也写得不错，可读性也比较好）。
在后续项目的开发实践过程中，我们还需不断优化、完善新设计的逻辑框架，让其可用性更高、可复用性更强，相信经历咱们新项目的洗礼，新的逻辑框架能成为咱们产品中心游戏服务器开发的一把利器。
2需求说明2.1实时对战下面论述以《女巫之战》为例进行。
系统从当前在线玩家中，匹配出合适对手来。当进入挑战场景时，对战两方玩家在同一屏显示，双方的每一次游戏操作带来的变化，如：消除效果，都能实时同步到屏幕上。
如下图：来自《女巫之战》截图，即游戏对战界面会显示两个棋盘，左边为玩家自己的，右上角为对手的，游戏过程中，会同步显示血条和棋盘的变化。
2.2离线对战离线对战模式，在SNS游戏中是比较常见的一种PVP玩法。玩家可以随时对自己的关系链好友发起挑战，即玩家A可以对好友玩家B发起的挑战，不关心其玩家B是否在线。挑战完成后，若玩家B在线，则即时通知其被挑战的信息，若玩家B离线，则待其上线时，再通知被挑战详细信息。
2.3半实时对战同实时对战类似，系统也是先从当前在线玩家中，匹配出合适对手来。但是当进入挑战场景时，屏幕只显示玩家自己，不显示对手游戏界面。待这局游戏结束后，在结算界面一起显示对战结果。
还有另一个版本是，对战双方都是带角色的，游戏过程中可以显示对手玩家的角色Icon，对战过程中发生的变化，如：分数等，是实时广播给双方的。
3设计实现3.1实时对战实时对战的设计实现，总的来说，可分为两类，一类是服务器强同步，一类是服务器弱同步，下面详细描述之。
3.1.1服务器强同步方案在这个方案中，游戏逻辑的判定均放在服务端进行，无论是棋盘的初始化操作，还是游戏过程中的消除、新棋子生成等逻辑均由服务器运算，即将消除的算法放在服务器端，客户端主要作相应消除效果的表现。
进一步分析，该方案分为两种情况：
阻塞同步阻塞同步的特征是：玩家每次移动棋子作消除操作时，需要等本次操作产生的效果全部完成后（如：播放消除特效、已有棋子下落，新棋子填充等），才能作下一次移动棋子的操作。基本流程如下图所示：
图1阻塞同步序列图
客户端A和B分别发起棋子移动请求，在收到服务器的响应包之前，客户端阻塞不允许移动；服务器分别判定两者的移动是否合法，若非法，客户端收到移动失败响应包后，让棋子置位；若合法，先响应客户端移动成功消息。然后，服务器进一步计算本次移动影响的待下落棋子和新生成待填充的棋子，以及新生成棋子中可能引发的combo棋子，计算完毕后，则一起打包分别向客户端A与B广播棋子下落消息，同时处理业务对应的逻辑，如：扣对手玩家的HP、累加自己的分数等；客户端收到服务器的响应移动结果包后，若检查通过，则处理棋子移动，并播放棋子消除特效等，若不通过，则重置棋子归位；客户端收到服务器的棋子下落和新棋子填充广播包后，分别处理A和B两个棋盘的棋子下落效果；进入下一轮棋子请求处理；
图2帧同步序列图
3.1.2服务器弱同步方案在该方案中，游戏消除逻辑主要放在客户端进行，即棋盘初始生成算法、消除检查算法、棋子下落与新棋子生成算法等均由客户端来控制，而服务器主要作消息转发与一些简单的判定，如：对局结束的条件等，基本流程图如下所示：
图3弱同步序列图
多点数据的修改问题，目前都有比较成熟的解决方案，具体方案需要根据业务需求实际来选择：
全局逻辑锁方案实现要点是用一个单独的locksvr来保持数据修改时的同步。即玩家A发起对玩家B挑战，gamesvr在get玩家A和玩家B数据的同时，会lock这两者的数据。此时，若还有其他玩家需要get这两个玩家数据时，就会get失败，即锁冲突。这样就保证了，每次修改只会有一个玩家在操作。
该方案的优点：
好处在于单独的locksvr可以设计得比较通用，多个项目可以复用，一定程度上可以提高开发效率；locksvr逻辑上比较清晰，部署也比较方便。目前微连等项目就是采用的架构组提供的locksvr组件；不足的地方：
当交互比较频繁时，locksvr的机制可能会导致比较多的冲突，从而会影响玩家的游戏体验。这个问题在webgame中，玩家可能不会太敏感，这跟玩家的操作习惯有关，当冲突发生时，玩家一般刷新一下页面操作即可恢复正常。而在手机游戏中，需要根据具体游戏业务来评估；
增量修改方案实现要点是gamesvr修改玩家数据时，只提交修改的相对值，各个gamesvr的修改数据请求汇总至一台中心服务器（热点服务器）进行，因为只有一个地方修改，故修改数据自然会保持队列同步。
最大的好处是不会产生修改引发的冲突问题；Gamesvr为无状态服务器，逻辑会比较简单；不足的地方：
要求修改的数据结构比较简单且单一，否则会导致中心服务器的逻辑处理复杂度成倍增加；由于所有数据的修改均在中心服务器进行，故其有单点风险；
（三）CompareAndSwap
实现要点保证每次提交的操作，只有一个是成功的。即gamesvr修改玩家数据前，先获取该玩家的cas值，并在修改数据时把cas值带上。数据到达DBSvr时，会检查cas值的合法性，检查通过，则允许修改数据，同时将当前cas值加1。此时，若有其它gamesvr提交同一玩家的修改请求时，会发现cas值与当前的不匹配，则拒绝此次修改，同时，返回一个错误给这个gamesvr的请求。
它其实是前两种方案的一个折衷方案，相对于全局锁的强锁定（get数据就会锁定），它只会在set数据时判定数据是否冲突，即有玩家A修改玩家B数据时，玩家C依然可以get玩家B或玩家A的数据，不会引发冲突问题；该方案同样可以做到通用；不足的地方：
依然有强交互时，可能有比较多的冲突问题；需要有DBsvr支持该CAS机制；注：目前公司的CMem组件支持CAS机制；
3.3半实时对战半实时对战本质上还是在线玩家之间的PK，只是客户端在表现手法上，与实时对战有所区别。以《女巫之战》为例，若换成半实时对战，则对战开始后，对战界面只显示玩家自己一个人的棋盘，对手玩家只显示一个AvatarIcon和血条。
半实时对战的实现方案可参考实时对战中的弱同步方案。
4我们的选择上面讨论了三类对战需求，在实现层面上，可供选择的设计方案。并且分析了每种设计方案的优缺点和适用场合。咱们微项目具体选择哪种实现方案，需要根据特定的业务需求来决定。选择原则是：方案满足需求，实现代价最小。
发布于WebGame游戏开发现状浅析（一）产品设计
从技术层面来说，与传统MMORPG不同的是，动作类网游对于操作响应的网络时延要求极高，要保证较好的体验效果的话，一般要求时延小于150ms。如果网络时延较大的话，会带来对战双方（或多方）数据不一致的问题，即所谓的数据同步问题。因此，数据同步问题是动作类网游的首要问题，也是最大的问题。
下面将先描述数据同步问题的具体表现，再尝试分析目前业界常用的解决办法，最后简要讲述公司两个自研项目的实施方案。
2问题聚焦下面列举的这些同步问题，也是大部分网络游戏共有的一些典型问题，如果处理不好，又会在动作类网游中进一步放大，从而极大的影响玩家体验。
2.2动态阻挡所谓动态阻挡是指角色、怪物和建筑这些实体不可重叠。动态阻挡让玩家感觉更具有真实性，并且在多人PK中，可以利用动态阻挡进行卡位，制造人墙，丰富游戏的玩法。
动态阻挡本身就会有很多碰撞问题，再加上网络延迟，会有各种各样的问题产生。
碰撞情形1：玩家A在P1点请求要去P2点时，玩家B也有可能在P3点请求要到P2点，但最终只能有一个人到P2的位置，如何避免拉扯呢。
碰撞情形2：玩家A在P1点请求要去P2点，玩家B在P3点请求要去P4点，路径有交叉，要让他们碰还是不碰呢？
碰撞情形3：玩家A在P1点请求要去P2点，玩家B在P3点要去P4点，这种情形也会有碰撞发生。
碰撞情形4：玩家A要通过一个只能容纳一个人的关隘，玩家B要阻止玩家A通过，但是由于网络延迟，当A通过时，并没有发现B已经在卡住关隘，服务器是相信A，允许通过呢，还是相信服务器自己，要拖拽A呢？
碰撞情形5:玩家A要通过城门，但是由于网络延迟，当A通过时，并没有发现城门已经关闭了，服务器是相信A，允许通过呢，还是要拖拽A呢
其他诸如击晕，减速，恐惧，死亡等等，都类似冰冻情形，不再赘述
如下图所示：
优点简单易实现，不会出现任何的不一致性。在延迟小(<100ms)且稳定的环境下非常合适。此外，在实时性要求不高的玩法(比如回合制玩法)中也非常合适。
缺点游戏节奏受最慢的那个玩家客户端影响巨大。一人卡机，所有人受影响。恶意玩家可以用伪造大延迟的方式来获得好处，从而破坏游戏公平性。
3.2客户端承担消耗运算原理游戏比较消耗CPU的运算均放在玩家本地客户端执行，如：角色移动物理判定、战斗物理判定、AI逻辑判定等等。服务器只对影响玩家利益的关键信息作验证。
优点保证了游戏操作手感，避免了本机操作延时。
缺点运算逻辑存放在客户端，会带来较大的外挂风险。
优点无任何技术风险，绿色、环保、安全，代价最小。
缺点可能会影响战斗的爽快感。
客户端之间采用P2P通信这对于在同一局域网内（如：网吧）的玩家，网络延迟很小。只有当两个Peer连结不同时，消息包才通过服务器中转；
客户端先表现，服务器后检验玩家角色在移动、战斗出招等操作时，客户端在发出请求包的同时，先自行在本机表现，继续后面的游戏逻辑，而无需等到服务器验证通过后才开始。
客户端的校验逻辑同时在服务器再运行一遍这也是惯用做法，即所谓的服务器强校验。
5小结综上所述，动作类网游在技术实施层面上，较传统MMORPG主要是在数据同步（多个Peer间、C/S间）上要求更加苛刻，当然，这目前在客户端平台上，也已经有了较为成熟的技术解决方案。但具体到页游平台，虽然从Flash10和AdobeAIR1.5开始，已经支持P2P通信，Adobe也在官方提供相应的P2P服务，即代号为Cirrus，但目前尚未看到其在商业运营的页游项目里有成熟的应用。因此，在页游平台的P2P应用，还需要更进一步的探索和挖掘。
（一）协议通信
2）RPG选择的是基于socket的TCP通信，这是由游戏本身的特点所决定的，如：聊天、多人视野、服务器主动通知事件等需求
（二）游戏逻辑服务器的承受能力
1）RPG的游戏逻辑服务器（地图服务器）所能承载的最高在线（PCU）是在3000-5000不等；
2）SocialGame由于没有RPG复杂的移动、战斗、视野管理等需求，逻辑服务器承受的在线一般都是比较高的，如：10000-30000不等
（三）游戏逻辑服务器的Cache和回写机制
1）RPG的游戏逻辑服务器一般都需要Cache玩家数据，并且采取定时回写的策略，如根据数据重要程度分别作5min-15min不等的定时回写；
2）SocialGame的游戏逻辑服务器一般都无需Cache玩家数据，玩家的每次请求都是即时读即时写（这样会涉及到另外一个问题，即DB读写的性能问题，见下一条）；
（四）DB存储模型的选择
1）RPG存储服务器常用的还是MySQL+innodb，中间还由业务自己写一个Cache代理服务器，以Cache热点数据；
2）SocialGame则会选用TC、MemCached等所谓Key-Value全内存数据存储，有实力的公司会自己实现一个类似这种机制的存储系统，它可以无源，也可以是有源，并且还可以选择用MySQL作数据落地，毕竟MySQL作为互联网业务DB的成熟解决方案，已毋庸置疑；
（注：我们公司是选择自己开发基于key-value机制的全内存DB，现网测试的数据是平均1KB的数据可以分别达到5w左右的读/写，还是很牛X的了）
（五）交互数据的一致性
1）在SNSGame中，会经常出现同一个玩家在某一个时刻同时被多个好友访问和修改数据的情况，这时就需要保证，每次数据的更新都是正常有序进行的，而不能被写脏数据。一般地，都会使用一个类似全局锁服务的设计来解决这个问题；
（六）IDC部署
1）RPG一般是分区分服部署；
2）SocialGame则是全区全服部署；
呵，先写这些多，后面再慢慢补充，也欢迎同行朋友拍砖！：）
发布于关于游戏服务器性能问题的几点思考（2）工作中对项目压力测试的一些心得，先自我作一个小结吧！
（一）
在MMORPG游戏中，对于那些同时拥有近攻和远程系等多种职业的游戏，策划一般都会对近攻类的职业，加上冲锋类的技能，以便平衡远程类职业在攻击距离上的优势。在client看到的效果，是玩家边播放冲锋动作，然后快速接近目标，并对目标一个伤害，而对server而言，该技能与其它技能在处理的不同之处在于，施法玩家在施法的同时，也作一个位置的变更。一般server的处理流程是，先检查冲锋直线路径是否合法（有无阻挡）和其它施法条件，若通过，则告诉client可以施法，并同时设置当前玩家坐标为冲锋后的坐标（该坐标由client带上来）。
由于server移动系统在对client发过来的移动数据作检验时，需要检查本次移动的起步点，是否为上次移动的结束点，即作线段端点合法检查，而冲锋到达的目标点并未在上次移动的路径栈信息中，所以，server技能系统在设置冲锋位置时，需要先清除原路径栈信息（如调用MoveStop接口），以便确认本次冲锋为一次全新的移动。
（二）
两个玩家同时使用冲锋技能时（目前client在做技能时，采用先表现的方式），出现一个玩家（冲锋目标client）停在冲锋途中的现象，原因为server广播技能施法时，没有带目标主动位移的信息（client在处理冲锋位置时，对于使用冲锋技能的client，因为它知道冲锋到达的位置，所以它的处理没有问题，而另一个冲锋目标client，由于它不知道对方要冲到哪里，则client处理时就是选择冲锋路径上的一点，这样就会看到停在冲锋途中了）所致。解决办法是，要么在协议中下发目标位移信息，要么在策划规则上，只允许同一时刻一个玩家冲锋，如：冲锋加晕眩debug等；
（1）技能施法时，client只有一个上行的请求施法包，后续施法的过程全由server来驱动下发施法各阶段的结果信息，如吟唱、效果伤害、命中信息等等；
（3）技能学习：由秘籍来获得技能，一本秘籍包含多个技能，被动技能不影响主动技能的属性；
（4）Buff系统与技能系统是相互独立的，相互之间有接口各自的进行访问；
（5）玩家施法作群攻目标选定时，也是由server来完成，这时是从玩家自己的视野里搜索，而无需再搜一次动态区域（格子32*32）；
（6）技能效果由一个主效果+N个Buff效果组成；
（7）Buff对象区分玩家和怪物，其存储结构独立出来放在内存池中，在施法者需要时再根据目标类型来添加；
（8）特别小心：在作技能效果计算时，尽量避免有轮循的处理，因为，这个这个很耗CPU；
思考题：关于技能引发的位置同步问题
（1）对于改变目标（玩家）移动速度的技能，可能会带来位置不同步的问题，即server下发速度改变的包时，目标玩家可能正在移动，从而导致server和client的位置不一致？
（2）类似性质的问题还有给目标加冰冻、定身等Buff，也可能带来位置不同步的问题？
答：这个问题暂也还没有好的解决方案，目前的做法是当目标中定身Buff时，client立即表现定身，即定在原地，并将此时的位置信息带给server，server检验合法后设置这个位置，解冻后client为继续玩家移动（若玩家是移动中被定身住的话）。