经典游戏服务器端架构概述 (二) - 简书
经典游戏服务器端架构概述 (二)
全服分线模型
一. 模型描述
由于多进程服务器模型的发展，游戏开发者们首先发现，由于游戏业务的特点，那些需要持久化的数据，一般都是玩家的存档，以及一些游戏本身需要用的，在运行期只读的数据。这对于存储进程的分布，提供了非常有利的条件。于是玩家数据可以存放于同一个集群中，可以不再和游戏服务器绑定在一起，因为登录的时候便可根据玩家的ID去存储集群中定位想要存取的存储进程。
[图-全区分线模型]
二. 存储的挑战
需求：扩容和容灾在全区分线模型下，游戏玩家可以随便选择任何一个服务器登录，自己的帐号数据都可以提取出来玩。这种显然比每个服务器重新“练”一个号要省事的多。而且这样也可以和朋友们约定去一个负载较低的服务器一起玩，而不用苦苦等待某一个特定的服务器变得空闲。然而，这些好处所需要付出的代价，是在存储层的分布式设计。这种设计有一个最需要解决的问题，就是游戏服务器系统的扩容和容灾。
从模型上说，扩容是加入新的服务器，容灾是减掉失效的服务器。这两个操作在无状态的服务器进程上操作，都只是更新一下连接配置表，然后重启一下即可。但是，由于游戏存在大量的状态，包括运行时内存中的状态，以及持久化的存储状态，这就让扩容和容灾需要更多的处理才能成功。
最普通的情况下，在扩容和容灾的时候，首先需要通知所有玩家下线，把内存中的状态数据写入持久化数据进程；然后根据需要的配置，把持久化数据重新“搬迁”到新的变化后的服务器上。——如果一个游戏有几千万用户，这样的数据搬迁将会耗时非常长，玩家也被迫等待很长的时间才能重新登录游戏。所以在这种模型下，对于数据存储的设计是最关键的地方。
分区分服的关系型我们常常会使用这种关系型数据库来存放游戏数据。由于SQL能够表述非常复杂的数据操作，这对于游戏数据的一些后期处理有非常好的支持：如客服需要发奖励，需要撤销某些错误的运营数据，需要封停某些特征的玩家……但是，分布式数据库也是最难做分布的。一般来说我们都需要通过某一主键字段做分库和分表；而另外一些如唯一关键字等数据，就需要一些技巧来处理。
[图-分表分库]
以玩家ID作为分表分库是一个非常自然的选择，但是这种方案，往往需要在逻辑代码中，对玩家数据按照自定义的规则，做存储进程的选择。但是如果发现这个分表分库的（原则）不符合需求，就需要把大量的数据做搬迁。如上图是按玩家ID做奇偶规则分布到两个表中，一旦需要增加第三台服务器，数据存储的目的服务器编号就变成了id%3，这样就需要把好多数据需要从原来的第一、二台数据库中拷贝出来，非常麻烦。
有的开发者会预先建立几十个表（如120个表=2x3x4x5），一开始是全部都放在一个服务器上，然后在增加数据库服务器的时候，把对应的整个表搬迁出来。这样能减轻在搬迁数据的时候造成的复杂度，但还是需要搬迁数据的。最后如果与建立的表还是放不下了，依然还是需要很复杂和耗时的重新拷贝数据。
NoSQL在很多开发者绞尽脑汁折腾的时候，NoSQL横空出世了。实际上在很早，目录型存储进程就在DNS等特定领域默默工作了。NoSQL系统最大的好处正是关系型数据库最大的弱点——分布。
由于主键只有一个，因此内置的分布功能使用起来非常简便。而且游戏玩家数据，绝大多数的操作都是根据主键来读写的。“自古以来”游戏就有“SL大法”之称，其本质就是对存档数据的简单读、写。在网游的早期版本MUD游戏时代，玩家存档只是简单的放在硬盘的文件上，文件名就是玩家的ID。这些，都说明了游戏中的玩家数据，其读写都是有明显约束的——玩家ID。这和NoSQL简直是天作之合。
[图-NoSQL]
NoSQL的确是非常适合用来存储游戏数据。特别是有些服务器如还带有丰富的字段值类型。但是，NoSQL本身往往不带很复杂的容灾热备机制，这是需要额外注意的。而且NoSQL的访问延迟虽然比关系型数据库快很多，但是毕竟要经过一层网络。这对于那些发展了很多年的ORM库来说，缺乏了一个本地缓存的功能。这就导致了NoSQL还不能简单的取代掉所有服务器上的“状态”。而这些正是分布式缓存所希望达成的目标。
分布式缓存在业界用的比较多的缓存系统有memcached，开发者有时候也会使用诸如这样的ROM库提供的cache功能。但是这些缓存系统在使用上往往会有一些限制，最主要的限制是“无法分布式使用”，也就是说缓存系统本身成为性能瓶颈后，就没有办法扩容了。或者在容灾的情景下，缓存系统往往容易变成致命的单点。
Orcale公司有一款叫Coherence的产品，就是一种能很好解决以上问题的“能分布式使用”的产品。他利用局域网的组播功能来做节点间的状态同步，同时采用节点互相备份的方案来分布数据。这款产品还使用Map接口来提供功能。这让整个缓存系统既使用简单又功能强大。更重要的是，它能让用户对于数据的存取特性做配置，从而提供用户可接受的数据风险下的更高性能——本地缓存。
由于游戏的数据，真正变化频繁的，往往不是“关键”的需要安全保障数据，如玩家的位置、玩家在某次战斗中的HP、子弹怪物的位置等等。而那些非常重要的数据，如等级、装备，又变化的不频繁。这就给了开发者针对数据特性做优化以很大的空间。而且，大部分数据的读、写频率都有典型的不平衡状态。普遍游戏数据都是读多写少。少量的日志、上报数据是写多、几乎不读。
对于缓存系统来说，有三个重要的因数决定了在游戏开发中的地位。首先是其使用的便利性，因为游戏的变化非常频繁，如果要很繁琐的配置数据结构，则不会适合游戏开发；其次是要能提供近似本地内存的性能，由于游戏服务器逻辑基本上都是在频繁的读写某一特定数据块，如玩家位置、经验、HP等等，而且游戏对于处理延迟也有较高的需求（WEB应用在2秒以内都可以忍受，游戏则要求最好能在20ms以内完成）。要能同时满足这两点，是不太容易的。
[图-分布式缓存]
集成缓存的NoSQL根据上面的描述，读者应该也会想到，如果数据库系统，或者叫持久化系统，自带了缓存，是否更好呢？这样确实是会更好的，而且特别是对于NOSQL系统来说，能以一些内部的算法策略，来降低前端逻辑开发的复杂程度。一般来说，我们需要对集成缓存的NOSQL系统有以下几方面的需求：首先是冷热数据自动交换，就是对于常用数据有算法来判别其冷热，然后换入到内存以提高存取性；其次是分布式扩容和容灾功能，由于NOSQL是可以知道数据的主关键字的，所以自然就可以自动的去划分数据所在的分段，从而可以自动化的寻找到目标存储位置来做操作；最后是数据导出功能，由于NOSQL支持的查询索引只能是主键，对于很多后台游戏操作来说是不够的，所以一定要能够到处到传统的SQL服务器上去。
在这方面，有很多产品都做过一定的尝试，比如在或者MangoDB上做插件修改，或者以ORM系统封装MySQL以试图构造这种系统等等。
[图-集成缓存的NOSQL]
三. 跳线和开房间
开房间型游戏模型在全区分线服务器模型中，最早出现在开房间类型的游戏中。因为海量玩家需要临时聚合到一个个小的在线服务单元上互动。比如一起下棋、打牌等。这类游戏玩法和MMORPG有很大的不同，在于其在线广播单元的不确定性和广播数量很小。
这一类游戏最重要的是其“游戏大厅”的承载量，每个“游戏房间”受逻辑所限，需要维持和广播的玩家数据是有限的，但是“游戏大厅”需要维持相当高的在线用户数，所以一般来说，这种游戏还是需要做“分服”的。典型的游戏就是《英雄联盟》《穿越火线》这一类游戏了。而“游戏大厅”里面最有挑战性的任务，就是“自动匹配”玩家进入一个“游戏房间”，这需要对所有在线玩家做搜索和过滤。
[图-开房间型游戏]
这类游戏服务器，玩家先登录“大厅服务器”，然后选择组队游戏的功能，服务器会通知参与的所有游戏客户端，新开一条连接到房间服务器上，这样所有参与的用户就能在房间服务器里进行游戏交互了。
由于“大厅服务器”只负责“组队”，所以其承载力会比具体的房间服务器更高一些，但这里仍然会是性能瓶颈。所以一般我们需要尽量减少大厅服务器的功能，比如把登录功能单独列出来、把玩家的购买物品商城功能也单独出来等等。最后，我们也可以直接想办法把“组队”功能也按组队逻辑做一定划分，比如不同的组队玩法、副本类型、组队用户等级等等。
虽然这种模型已经可以对很多游戏做很好的承载了，但是在大厅服务器这里依然无法做到平行扩展，原因是玩家的在线数据比较难分布到不同的服务进程上去，而且还带有大量复杂的数据查询逻辑。
专用聊天服务器不管是MMORPG还是开房间类游戏，聊天一直都是网络游戏中一个重要的功能。而这个功能在“在线人数”很多，“聊天频道”很多的情况下，会给性能带来非常大的挑战。在很多类型的页游和少部分手机游戏里面，在线聊天甚至是唯一的“带公共状态”的服务。
聊天服务处理点对点的聊天，还有群聊。用户可能会添加好友、建立好友群组等各种功能。这些功能，都是和一般的游戏逻辑有一定差别的功能。这些功能往往并不是非常容易实现。很多游戏都期望建立类似腾讯QQ的游戏聊天功能，但是QQ是一整个公司在做开发，要用仅仅一个游戏团队做成这么完整的功能，是有一定困难的。
因此游戏开发者们常常会专门的针对聊天功能来开发一系列的服务进程，以便能让游戏的聊天功能独立出来，做到负载分流和代码重用的逻辑。很多网游系统，其聊天系统从客户端来说就是和主游戏进程分开的。
聊天服务器的本质是对客户端数据做广播，从而让玩家可以交互，所以有很多游戏开发者也直接拿聊天服务器来做棋牌游戏的房间服务器，或者反过来用。由于在游戏“分服”里面单独部署了聊天服务器，这类服务器也往往被用来承担做“跨服玩法”的进程。比如跨服团队战、跨服副本等等。不管这些服务器最终叫什么名字，实际上他们承担的主要功能还是广播，而且是运行玩家“二次登录”的广播服务器。以至于后来，有部分游戏直接全部都用聊天服务器来代替原始的“游戏服务器”，这样还能实现一个叫“跳线”的功能，也就是玩家从一个“在线环境”跳到另外一个“在线环境”去。——这些都是对于“广播”功能的灵活运用。
[图-专用聊天服务器]
全服全线模型
尽管分服的游戏模型已经运营了很多年，但是有一些游戏运营商还是希望能让尽量多的玩家一起玩。因为网游的人气越活跃，产生的交互越多，游戏的乐趣也可能越多。这一点最突出表现在棋牌类网游上。如联众、QQ游戏这类产品，无不是希望更多玩家能同时在线接入一个“大”服务器，从而找到可以一起玩的伙伴。在手游时代，由于手机本身在线时间不稳定，所以想要和朋友一起玩本来就比较困难，如果再以“服务器”划分区域，交互的乐趣就更少了，所以同样也呼唤这一个“大”服务器，能容纳下所有此款游戏的玩家。因此，开发者们在以前积累的分服模型和分线模型基础上，开发出满足海量在线互动需求的一系列游戏服务器模型——全服全线模型。
[图-全服全线模型]
一. 服务进程的组织
静态配置全服全线模型的本质是一个各种不同功能进程组成的分布式系统，因此这些进程间的关系是在运维部署期间必须关注的信息。最简单的处理方法，就是预先规划出具体的进程数量、以及进程部署的物理位置，然后通过一套配置文件来描述这个规划的内容。对于每个进程，需要配置列明每个进程的pid文件位置；内部通讯用的地址，如IP+端口或者消息队列ID；启动和停止脚本路径；日志路径等等……由于有了一套这样的配置文件，我们还可以编写工具对所有的这些进程进行监控和操作批量启停。
[图-静态配置]
虽然我们可以以静态配置为基础做很丰富的管理工具，但是这种做法还是有可以改进的空间：每次扩容、更换故障服务器或者搬迁服务器（这在运营中很常见），我们都必须手工修改静态配置数据，由于是人工操作，就总会产生很多错误，根据个人经验，游戏运营事故中的70%以上，是跟运维操作有关；由于整个分布式系统被切分成大量的进程，对于新进入此项目的程序员来说，要完整的理解这个系统，需要在思想上跨越层层阻隔：每个进程的功能、它们部署的关联、每个进程间的协议报的含义、每个业务流程具体的跨进程过程……这要花费很多时间才能搞明白的。而且大部分游戏的这种并不统一，每个游戏都可能需要重新理解一次，知识无法重用；在开发上，由于分布式系统的复杂性，要多搭几个开发、测试环境也是很费时间的，以至于这项工作甚至要安排专人来负责，这对于小型游戏开发团队来说几乎是不可承担的成本。因此我们还需要一些更加自动化，更加容易理解的全服全线游戏服务器模型。
基于中心点的动态组织SOA架构模式是业界一个比较经典的分布式软件架构模式，这个架构的特点是能动态的组织一个非常复杂的分布式服务系统。这个系统可以包含提供各种各样供的服务程序，而这些服务程序都以同一个标准接口来使用，并且服务自己会注册自己到集群中，以便请求方能找到自己。这种架构使用Web Serivce来作为服务接口标准，通过发布WSDL来提供接口API，这极大的降低了开发者对这些服务的使用成本。在游戏领域，服务器端提供的功能程序，实际上也是非常多样的，如果要构建一个分布式的系统，在这个方面是非常适合SOA架构的思想的；然而，游戏却很少使用HTTP协议及其之上的Web Service做通讯层，因为这个协议性能太低。不过，类似SOA的，基于中心节点的动态组织的服务管理思路，却依然适用。
[图-基于中心点的动态组织]
一般来说我们会使用一组目录服务器来充当“中心点”，代表整个集群。开源产品中最好的产品就是ZooKeeper了。当然也有一些开发者自己编写这样的目录服务器。由于每个服务进程会自己上报负载和状态，所以每个进程只需要配置自己提供的服务即可：服务名字、服务接口。对于请求方来说，一般都可以预先编写目标服务接口的类库，用来编程，有些项目还使用RPC功能，使用IDL语言配置直接生成这些接口类库。当需要请求的时候，执行“名字查找”-“路由选择”-“发起请求”就可以完成整个过程。由于有“查找”-“路由”的过程，所以如果目标服务故障、或者新增了服务提供者，请求方就能自动获得这些信息，从而达到自动动态扩容或容灾的效果，这些都是无需专门去做配置的。
服务化与云尽管动态组织的架构有如此多优点，但是开发者还是需要自己部署和维护中心节点。对于一些常用的服务，如网络代理服务、数据存储服务，用户还是要自己去安装，以及想办法接入到这套体系中去。这对于开发、测试还是有一定的运维工作压力的。于是一些开发团队就把这类工作集中起来，预先部署一套大的集群中心系统，所有开发者都直接使用，而不是自己去安装部署，这就成为了服务化，或者云服务。
[图-服务化、云]
使用专人维护的服务化集群确实是一个轻松愉快的过程。但是游戏开发和运营过程中，往往需要多套环境，如各个不同版本的测试环境、给不同运营平台搭建的环境、海外运营的环境等等……这些环境会大大增加维护服务化集群的工作量，对于解决这个问题，建立高度自动化运维的私有云，成为一个需要解决的问题放上了桌面。提高集群的运维效率，降低工作复杂程度，需要一些特别的技术，而虚拟化技术正式解决这些问题的最新突破。
二. 提高开发效率所用的结构
使用RPC提高网络接口编写效率在分布式系统中，如果所有的接口都需要自己定义数据协议报来做交互，这个网络编程的工作量将会非常的大，因为对于一个普通的通信接口来说，至少包括了：一个请求包结构、一个响应包结构、四段代码，包括请求响应包的编码和解码、一个接收数据做分发的代码分支、一个发送回应的调用。由于分布式的游戏服务器进程非常多，一个类似登录这样的操作，可能需要历经三、四个进程的合作处理，这就导致了接近十个数据结构的定义和无数段类似的代码。而这些代码，如果在单进程的环境下，仅仅只是三、四个函数定义而已。
因此很多开发者投入很大精力，让网络通信的编写过程，尽量简化成类似函数的编写一样。这就是前文所述的远程调用的方法。在全区全线的游戏中，如果是比较重度的游戏，采用RPC方式做开发，会大大降低开发的复杂程度。当然也有一些比较轻度的游戏，还是采用传统的协议包编解码、分发逻辑调用的做法。
简化数据处理在分布式系统中，对于避免单点、容灾、扩容中最复杂的问题，就是在内存中的数据。由于内存中有游戏业务的数据，所以一般我们不敢随便停止进程，也难以把一个进程的服务替换为另外一个进程。然而，游戏数据对比其他业务，还是非常有特点的：
写入越不频繁的数据，价值越高。比如过关、升级、获得重要装备。
大量数据都是读非常频繁，而写非常不频繁的，如玩家的等级、经验。
大量写入频繁的数据，实际上是不太重要，可以有一定损失，比如玩家位置，在某个关卡内的HP/MP等……
因此，只要我们能按数据的特性，对游戏中需要处理的数据做一定分类，就能很好的解决分布式中的这些问题。
首先我们要对数据的分布做规划，一般来说采用按玩家ID做分布，这样能让服务进程中内存的数据缓存高度命中。常用的手法有用一致性哈希来选择路由，调用相关的服务进程。
其次对于读频繁而写不频繁的数据，我们采用读缓存而写不缓存的策略。每个服务进程都保留其读缓存数据，如果需要扩容和容灾，仅仅需要修改服务访问的路由即可。
再次对于读不频繁而写频繁的数据，我们采用写缓存和读不缓存的策略。由于这些数据丢失掉一些是不要紧的，所以容灾处理就直接忽略即可，对于扩容，只需要对所有服务进程都做一次回写即可。
最后，有一些数据是读和写都频繁的数据，比如玩家位置，HP/MP这类，我们采用读写都缓存，由于数据重要性不高，只要我们多分几个服务进程即可降低故障时影响的范围；在扩容的时候调用全节点清理读缓存和回写脏数据即可。
在和持久化设备打交道的时候，传统的ORM类库往往能帮我们把数据存入关系型数据库，然而，使用一个自带数据热备的NOSQL也是很好的选择。因为这样能节省大量的分库分表逻辑代码。
自动化部署集群环境最新的虚拟化技术给分布式系统提供能更好的部署手段，以为标志的虚拟化平台，可以很好的提高服务化集群的管理。我们可以把每个服务进程打包成一个映像文件，放入虚拟机中运行，也可以把一组互相关联的服务进程打包运行。这些环境问题都由Docker处理了。但是，我们同时需要注意的是，如果我们的进程的资源是静态分配的（前文提到），在Docker的虚拟机中可能因为内存不足等原因直接无法启动。这就需要我们把完全静态分配资源的程序，修改为有资源限制，但是动态分配的程序。这样我们才能在任何可以部署Docker的机器上部署我们的游戏服务器。
三. 分布式难点：状态同步
分布式接入层一般来说，我们全线服务器系统碰到的第一个问题，就是大量并发的网络请求。特别是大量玩家都在一起交互，产生了大量由于状态同步而需要广播的数据包。这些网络请求的处理，显然应该独立出来成为单独的进程。同时这些网络接入进程，还应该是一个集群中的成员。这就诞生了分布式接入服务层。
这些网路接入进程的第一个功能，就是把并发的连接，代理成为后端一个串行的连接，这可以让后端服务进程的处理逻辑更简单，而且网络处理消耗变得更小。
其次，网络接入进程需要支持广播功能。如果只是普通的广播实现，很多人会需要拷贝很多次需要广播的内容，然后挨个对Socket做发送。这其实是一个消耗很高的操作。而单独的网络接入进程，可以善用“零拷贝”等技术，大大降低广播的性能开销。而且还可以通过多个进程一起做广播操作，以达到更大的在线同步区域。
最后，网络接入进程需要支持一些额外的有用功能，包括通讯的加密、压缩、流量控制、过载保护等等。有些团队还把用户的登录鉴权也加入网络接入功能中。
[图-分布式接入层]
使用P2P网络状态同步产生的广播请求中，绝大多数都是客户端之间的网络状态，因此我们在可以使用P2P的客户端之间，直接建立P2P的UDP数据连接，会比通过服务器转发降低非常多的负载。在一些如赛车、音乐、武打类型的著名游戏中，都有使用P2P技术。而接入进程天然的就是一个P2P撮合服务器。
有些游戏为了进一步降低延迟，还对所有的玩家状态，只同步输入动作，以及死亡、技能等重要状态，让怪物和一般状态通过计算获得，这样就更能节省玩家的带宽，提高及时性。加上一些动作预测技术，在客户端上能表现的非常流畅。
一. 可重用的游戏业务模版
游戏服务端的各种架构中，以前往往比较关注那些非功能性的需求：容灾性、扩容、承载量，延迟。而在现在手游时代，开发效率越来越重要，有些团队甚至不设专门的服务器端程序员。因此游戏服务端架构应该更多的关注业务开发的效率。
现代游戏中，只要是带RPG元素的，角色系统、物品系统、技能系统、任务系统就都会具备，而且都有一批比较稳定的核心逻辑。只要是能在线交互的，就有好友系统、邮件系统、聊天系统、公会系统等。另外商城系统、活动系统、公告系统更是每个游戏都似乎要重复发明的轮子。
游戏的后端应用也有很多可重用的部分，比如客服系统、数据统计平台、官网数据接口等等。这些在游戏服务端框架中往往是最后再添加进去的。
如果把以上的问题都统一考虑起来，我们实际上是可以在一个稳定的底层架构上，构造出一整套常用的游戏业务逻辑模板，用来减少游戏领域的业务代码开发。所以这样一套可以运行各种业务逻辑模版的底层架构，正是游戏服务端架构发展的方向。
二. 动态资源调度的PaaS云
现在有的团队已经在搭建自己的Docker云，这可以让游戏服务器在虚拟云上动态的生长，从而达到真正的动态扩容和动态容灾。加上如果游戏服务器不再是一个个服务进程，而是真正意义上的一个个服务，可以动态的加入或者离开云环境，那么这就是一个游戏领域的PaaS系统。我热切的希望能看到，可以用一套SDK，开发或重用那些成型的业务模版，然后动态注册到服务云中就能运行，这样一种游戏服务器架构。
Don't reinvent the wheel.
在服务器端程序开发领域，性能问题一直是备受关注的重点。业界有大量的框架、组件、类库都是以性能为卖点而广为人知。然而，服务器端程序在性能问题上应该有何种基本思路，这个却很少被这些项目的文档提及。本文正式希望介绍服务器端解决性能问题的基本策略和经典实践，并分为几个部分来说明： ...
在服务器端程序开发领域，性能问题一直是备受关注的重点。业界有大量的框架、组件、类库都是以性能为卖点而广为人知。然而，服务器端程序在性能问题上应该有何种基本思路，这个却很少被这些项目的文档提及。本文正式希望介绍服务器端解决性能问题的基本策略和经典实践，并分为几个部分来说明： ...
姓名：纪雅丽 转载自：http://www.codeceo.com/article/high-performance-server-artch.html，有删节。 【嵌牛导读】：在服务器端程序开发领域，性能问题一直是备受关注的重点。业界有大量的框架、组...
架构的分析模型一. 讨论的背景现代电子游戏，基本上都会使用一定的网络功能。从验证正版，到多人交互等等，都需要架设一些专用的服务器，以及编写在服务器上的程序。因此，游戏服务器端软件的架构，本质上也是游戏服务器这个特定领域的软件架构。软件架构的分析，可以通过不同的层面入手。比较...
本文转载自http://geek.csdn.net/news/detail/112672 WeTest导读 我们常常会听说，某个互联网应用的服务器端系统多么牛逼，比如QQ、微信、淘宝。那么，一个互联网应用的服务器端系统，到底牛逼在什么地方？为什么海量的用户访问，会让一个服务...
初读《边城》，这部小说描写细腻，语言平淡，情节算是平凡，但细读之下，又会被小镇的悠闲适意，爷爷的朴讷，翠翠的可爱以及字里行间的自然、优美、诗意所吸引。读着读着，似乎自己也融入了这个很多年前的故事中。 这则故事开头向我们展现了那片宁静的自然风光，寥寥几笔勾勒出翠翠和爷爷简单的...
在我眼里 几十年如一日 它也就是个 妇女节 近年来听到了许多叫法 有女人节，女性节 和女生节 我觉得女性节好些 只要是女性 这个节日 就属于她们 昨天又听到一个 女神节 真心觉得不好 仿佛只有女神才配 过这个节 众多的女娃子，女同志，女老人们 只能 望而却步
外甥女又打电话叫我接她回家，这回的原因是肚子疼。我急匆匆的打了滴滴出租车来到学校，看到孩子正捂着肚子在学校大门口等着我呢。这所学校是本地最大的公立高中，而外甥女是这所学校高二普通班的学生。 我这个小姨，是幼儿园的老师，业余的时候做心理咨询师，接些有些心理需求的客户。这个孩子...
“爱过几个人，也被几个人好好爱过。可我觉得我现在好像都不太敢给对方展露爱了。”磊哥和我说：“我现在不会再对别人说：我很想你、我会永远爱你这样的话了，也不会说我什么都想为你做。更不会说，其实我很爱你的结果并不是一定要和你结婚不可，你不必紧张。可，后来想想，我何必什么都说呢？搞...
需求：搜索关键词变换情况下对view的更新 1.新建Observable 作用：通过更新supplier更新关键词 2.新建supplier 作用：提供关键词更新接口，提供result接口返回。 3.新建repositories 作用：联系数据提供者与被观察者 4.更新 作...随笔 - 183&
文章 - 10&
trackbacks - 0
29303112367810111213141516171819202122232426281234567891011
专注即时通讯及网游服务端编程
------------------------------------
本博收藏大部分文章为转载，并在文章开头给出了原文出处，如有再转，敬请保留相关信息，这是大家对原创作者劳动成果的自觉尊重！！如为您带来不便，请于本博下留言，谢谢配合。
Awesome中文聚合
Stable APIs for Golang
way to explore
积分与排名
阅读排行榜
转载请自觉标明原创出处原文链接：游戏开发& 游戏服务器开发技术小结1 概述本文从开发者的视角，浅析游戏服务器开发涉及到的几个技术层面，并说明这几个层面我们可以选择的解决方案。
一般地，会把游戏服务器的架构划分如下三层：网络接入层、游戏逻辑层、数据存储层，这样划分的主要目的是：
将底层通信与业务逻辑处理解耦合；将业务逻辑处理与数据存储解耦合；有利于运营部署与扩展；游戏服务器开发框架整体视图，如下所示：
2 网络接入层网络接入层主要任务是解决来自客户端大量并发请求和负载均衡的处理，考量该层的主要性能指标是：高吞吐、低延迟、均负载，即既能同一时刻处理大批量的客户端请求（每秒至少1万个请求以上），又能快速响应，并且均负载的分布处理这些请求。
本层的基本技术要点如下图所示：
2.1 高并发处理2.1.1 http接入（1）优点
低成本：有成熟的开源webserver；快速开发的效率：一请求一应答的协议通讯，使用游戏逻辑处理相当简单；低门槛：基于web的应用，玩家无需下载客户端，也不用担心防火墙等问题；（2）不足
难以处理服务器广播事件；文本协议会占用较大流量；2.1.2 socket接入（1）优点
功能强大：能灵活处理服务器广播事件；高效通信：二进制协议较文本协议能大幅度节省带宽，并且通信包可做组播等处理，以有效降低流量；（2）不足
实现成本较高，开发难度较大；可能会遭遇部分办公室玩家的机器通讯端口被屏蔽，无法穿透防火墙等问题；2.2 IP路由与负载均衡这块跟服务器集群和IDC部署密切相关，主要是为了让整个服务器集群能最大化其处理能力，尤其是在业务高峰时期，整个服务器集群能均衡平滑的应对客户端请求，不至于出现某个单点服务器出现很高负载时，其它同层服务器较空闲的情况。
目前，这块公司和开源界都有很成熟的解决方案，故在此不多赘述。
2.3 应用场景目前市面上绝大多数的Social Game和SLG类的WebGame均采用http通讯；RPG类的WebGame和有源客户端网游均采用socket通讯；3游戏逻辑层游戏逻辑层主要是处理游戏的具体业务逻辑，根据游戏类型和部署的不同，它会由一个或多个进程组成。其主要组成可由下图说明
3.1 基础系统基础系统包含的内容基本上为各个游戏业务逻辑所公有的东西。
游戏对象内存管理：这是业务系统中最基本也是最重要的系统之一，目前，我们采用基于共享内存的预分配机制，来管理游戏中各个对象所需内存的分配与回收。这样的好处是，当游戏服务器进程Crash时，配合运营的实时监测机制，系统自动拉取Crash进程后，在线玩家的状态数据可以无损恢复，并且在线玩家不会感觉到服务器宕机；消息分发管理：集中处理CS消息和SS消息，设计时重点考虑程序的可扩展性；系统与运营日志管理：分别用来监控服务器状态和玩家的各种行为；游戏商城管理：对付费物品的上架、扣除、计费等处理；玩家登录管理：玩家登录游戏时的流程统一处理；3.2 业务系统业务系统主要是说明游戏的主体内容是由哪些子模块组成，这跟具体的游戏类型关系较大，这里抽取出大部分游戏应用的业务模块。
地图与副本管理：游戏各公共场景和玩家独自的副本地图的处理，包括Npc与怪物分布、传送点分布、地图阻挡数据等的解析，以及地图实例和副本实例的抽象等；移动管理：主要是实现游戏对象（玩家角色、怪物等）的地图寻路、障碍物检测，以及动态碰撞处理等功能。装备与道具管理：主要包括装备的合成、拆分、打造、镶嵌、升星等，以及道具的获取、交易、使用等功能；任务与事件管理：主要包括任务的领取、任务节点的更新、任务的完成和失败处理等，以及系统随机事件的产生等内容；游戏世界状态管理：可将整个游戏世界各游戏对象的状态分成几大类与几小类，如：玩家角色的状态、技能Buff的状态等，然后对各状态之间关系进行统一管理；战斗与技能管理：处理PVE、PVE战斗流程、伤害计算，以及各个技能、Buff、Debuff的业务规则处理；Npc与怪物AI管理：包括Npc在场景中的分布规则和本身的功能处理，以及怪物的分布、刷新、各类AI行为的处理；视野管理：包括玩家的视野、Npc和怪物的视野等，设计时需要特别注意考虑各个不同场景中玩家的视野大小和视野搜索网格大小这两个重要参数，因为，它们对服务器的性能（CPU和流量）影响很大；宠物与坐骑管理：包括宠物和坐骑的养成、交易、附带技能和装备等功能；社会关系管理：包括玩家组队、玩家好友、玩家交易、家族、公会、阵营、国家等社会关系功能的处理；邮件管理：通过邮件可实现发送系统消息、发放系统道具，玩家道具交易等功能；聊天管理：包括玩家点对点聊天、群聊等功能；&
4 数据存储层数据存储层是整个服务器的关键基础系统之一，因为游戏服务器的核心功能之一就是存取玩家数据。游戏类型不同，对数据的存取需求也不一样，对于传统客户端MMORPG而言，一般采用Mysql作数据持久化，然后在Mysql与GameSvr中间实现一个ORM的服务提供数据的代理或缓存即可。而新兴的Social Game和强交互的WebGame，则选择用NoSql来替代Mysql，以满足其超大规模IO并发的需求。如下图所示：
4.1 ORMORM即为对象关系映射，可以这样来简单的理解：我们平时操作关系型数据库，需要业务自己编写许多数据访问的代码，这样会把许多SQL语句直接暴露在业务代码里，十分不利于维护。利用ORM技术，可以避免这个问题，即业务逻辑不会直接对DB进行操作，而改由ORM来完成，业务逻辑与ORM服务之间约定相关协议和API接口，来完成对数据的增、删、改、查等功能。
4.2 NoSqlNoSql，指的是非关系型的数据库，它可以满足对数据库的高并发读写、对海量数据的高效率存储和访问，以及对数据库的高可扩展性和高可用性等需求，它是随着SNS和Web2.0的兴起而产生的新兴存储技术。对于游戏而言，目前它主要应用于Social Game和强交互的WebGame中。
5 通用组件库通用组件库是指那些与具体业务无关的，能应用于所有服务器开发的组件库。目前，我们所积累的可归纳如下图所示：
5.1 后台服务应用框架后台服务应用框架规范了进程的起停方式、信号处理、命令行参数等操作，框架本身实现了一个daemon服务所必备的消息主循环、reload机制，以及定时器处理等功能。
5.2 日志组件日志是服务器调试和定位Bug的主要手段之一，日志组件一般需要实现日志分级、异步写磁盘、以及按日期时间分类等功能。
5.3 进程间通讯组件进程间的通讯也是服务器的核心基础功能之一，高效的进程间通讯是服务器性能的基本保障，进程间通讯组件需要实现同机器与跨机器的进程高效通讯。
5.4 消息打包组件在许多通信程序中，需要定义一套网络协议，并需要根据网络协议对协议数据单元（PDU）进行Pack/Unpack，以实现可移植性和网络传输的可靠性及效率。但是对协议数据单元进行Pack/Unpack是一个重复性很强的操作，繁琐而且容易出错（Pack和Unpack容易不匹配）。而消息打包组件则简化了网络协议的制定，使得业务应用不用关心协议的Pack/Unpack操作，并且支持良好的数据扩展和协议版本兼容。
发布于 手游游戏服务器逻辑框架1 背景首先，要回答一个问题：
我们为什么要专门为手机游戏专门定制设计一个游戏服务器逻辑框架？
坦白地说，公司自研游戏做了这么多年，事实上互娱已经沉淀了一批相当成熟的组件，如：解决底层网络通信的Tconnd、解决进程间通信Tbus、解决协议加解包的Tdr等等，但我们发现，这些组件绝大多数都是与业务无关的基础组件、服务和库。而与游戏业务紧密相关的逻辑框架，可能每个项目组都有自己的一套，这一方面源于，不同游戏业务，的确需求本身有较大的差别，很难用一套可复用性很强的逻辑框架包打天下；另一方面，也可能受限于项目本身的开发进度压力，端游有相对充裕的开发时间，但由于游戏系统繁多，平摊下来，每个系统的开发时间也不多，而页游和手游的开发进度就更紧一些，逻辑框架这块也没太多时间来作整理了。
2 现状以stan经历过的工作室里三款游戏为例：微连、微胖和微塔。
三款游戏在业务逻辑处理上，均各自使用不同的一套框架，风格迥异。如果要说相同点，则是均使用C/C++来作业务逻辑的实现。微连和微胖均以tapp作基础来搭建框架，而微塔则是完全自行做的一套后台框架。
考虑到手游开发周期短，迭代速度快，发布频率高等特点，如果延用目前的逻辑框架，无论是上述三款游戏的哪一种，均难以解决如下几个问题：
（1）开发复杂度较高
这里的复杂度包括语言本身的复杂度、开发效率、代码可读/可维护性等。
（2）运维部署代价较高
从代码编译到上线部署，整个周期都比较长，虽然目前的逻辑框架基本上都采用了共享内存保存玩家核心数据，以便于进程重启后数据即时恢复的机制，用来实现“热更新”的效果，但这实际上是以牺牲开发复杂度来作代价的。
（3）系统可靠性
实事求是地说，要写出可靠性的代码，根本上还是取决于写代码的“人”。但由于C/C++本身是属于偏底层的语言，对开发者的要求客观上要更高一些。但即使经验丰富的开发者，也难免不犯内存越界、内存泄漏、堆栈溢出等诸多令人抓狂的错误。
有鉴于此，结合业内同行朋友成熟项目的经验，我们选择用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.4 Lua配置文件处理思路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.5 C++网络收发包处理思路目前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的机制；
4 写在后面的话目前用新的逻辑框架，重写了好友关系链Server和GameSvr账号登录验证模块，可以用微塔老客户端完成账号登录全流程。
虽然新设计的逻辑框架还有诸多可完善的地方，但初次尝试应用，我们已感受到它带来的变化，比如：重写的好友关系链Server代码量比原来缩减了近三分之一，代码量减少的很明显的好处就是：代码更简洁，可读性更高（客观说，微塔原来的代码也写得不错，可读性也比较好）。
在后续项目的开发实践过程中，我们还需不断优化、完善新设计的逻辑框架，让其可用性更高、可复用性更强，相信经历咱们新项目的洗礼，新的逻辑框架能成为咱们产品中心游戏服务器开发的一把利器。
发布于 手游对战设计方案1&&&&&& 术语1.1&&& 术语和定义术语 解释 硬直时间 客户端连续作移动消除时的累积时间 &&&
2&&&&&& 需求说明2.1&&& 实时对战下面论述以《女巫之战》为例进行。
系统从当前在线玩家中，匹配出合适对手来。当进入挑战场景时，对战两方玩家在同一屏显示，双方的每一次游戏操作带来的变化，如：消除效果，都能实时同步到屏幕上。
如下图：来自《女巫之战》截图，即游戏对战界面会显示两个棋盘，左边为玩家自己的，右上角为对手的，游戏过程中，会同步显示血条和棋盘的变化。
2.2&&& 离线对战离线对战模式，在SNS游戏中是比较常见的一种PVP玩法。玩家可以随时对自己的关系链好友发起挑战，即玩家A可以对好友玩家B发起的挑战，不关心其玩家B是否在线。挑战完成后，若玩家B在线，则即时通知其被挑战的信息，若玩家B离线，则待其上线时，再通知被挑战详细信息。
2.3&&& 半实时对战同实时对战类似，系统也是先从当前在线玩家中，匹配出合适对手来。但是当进入挑战场景时，屏幕只显示玩家自己，不显示对手游戏界面。待这局游戏结束后，在结算界面一起显示对战结果。
还有另一个版本是，对战双方都是带角色的，游戏过程中可以显示对手玩家的角色Icon，对战过程中发生的变化，如：分数等，是实时广播给双方的。
3&&&&&& 设计实现3.1&&& 实时对战实时对战的设计实现，总的来说，可分为两类，一类是服务器强同步，一类是服务器弱同步，下面详细描述之。
3.1.1&&&& 服务器强同步方案在这个方案中，游戏逻辑的判定均放在服务端进行，无论是棋盘的初始化操作，还是游戏过程中的消除、新棋子生成等逻辑均由服务器运算，即将消除的算法放在服务器端，客户端主要作相应消除效果的表现。
进一步分析，该方案分为两种情况：
阻塞同步阻塞同步的特征是：玩家每次移动棋子作消除操作时，需要等本次操作产生的效果全部完成后（如：播放消除特效、已有棋子下落，新棋子填充等），才能作下一次移动棋子的操作。基本流程如下图所示：
图1& 阻塞同步序列图
（0）客户端发起PVP匹配，服务器根据相关规则，在同一台gamesvr上匹配出对手玩家，并向两者广播一致的初始化棋盘信息；
客户端A和B分别发起棋子移动请求，在收到服务器的响应包之前，客户端阻塞不允许移动；服务器分别判定两者的移动是否合法，若非法，客户端收到移动失败响应包后，让棋子置位；若合法，先响应客户端移动成功消息。然后，服务器进一步计算本次移动影响的待下落棋子和新生成待填充的棋子，以及新生成棋子中可能引发的combo棋子，计算完毕后，则一起打包分别向客户端A与B广播棋子下落消息，同时处理业务对应的逻辑，如：扣对手玩家的HP、累加自己的分数等；客户端收到服务器的响应移动结果包后，若检查通过，则处理棋子移动，并播放棋子消除特效等，若不通过，则重置棋子归位；客户端收到服务器的棋子下落和新棋子填充广播包后，分别处理A和B两个棋盘的棋子下落效果；进入下一轮棋子请求处理；&
帧同步帧同步允许玩家在一定时间内（硬直时间），即时移动消除，即时反馈移动消除结果。当硬直时间到达时，客户端A和客户端B分别提交其在硬直时间内累积的所有移动请求，同时锁定棋盘，并等待服务器的处理结果。这种情况下，客户端和服务器都需要作消除逻辑的计算，并且两者的算法要保持一致。基本流程图如下所示：
图2& 帧同步序列图
（0）客户端发起PVP匹配，服务器根据相关规则，在同一台gamesvr上匹配出对手玩家，并向两者广播一致的初始化棋盘信息；
在硬直时间内，客户端A和B各自处理玩家的移动消除操作，此时只处理移动效果和消除爆炸效果，而棋子下落和新棋子填充不处理。硬直时间到达时，分别向服务器提前期间所有的请求移动信息；服务器分别判定两者的移动是否合法，若非法，客户端收到移动失败响应包后，让棋子置位；若合法，先响应客户端移动成功消息。然后，服务器进一步计算本次移动影响的待下落棋子和新生成待填充的棋子，以及新生成棋子中可能引发的combo棋子，计算完毕后，则一起打包分别向客户端A与B广播棋子下落消息，同时处理业务对应的逻辑，如：扣对手玩家的HP、累加自己的分数等；客户端收到服务器的棋子下落和新棋子填充广播包后，分别处理A和B两个棋盘的棋子下落效果；进入下一轮处理；&
3.1.2&&&& 服务器弱同步方案在该方案中，游戏消除逻辑主要放在客户端进行，即棋盘初始生成算法、消除检查算法、棋子下落与新棋子生成算法等均由客户端来控制，而服务器主要作消息转发与一些简单的判定，如：对局结束的条件等，基本流程图如下所示：
图3& 弱同步序列图
（0）客户端发起PVP匹配，服务器根据相关规则，在同一台gamesvr上匹配出对手玩家，并向两者广播约定的对局开始时间，如：播放开场动画（3s）后开始；
客户端各自判定玩家的移动棋子操作，判定能过，则表现相应的消除效果、棋子下落与新棋子填充过程，同时将本次消除信息打包发至服务器；服务器收到客户端的消除信息后，分别转发至其对应的玩家，同时处理业务对应的逻辑，如：扣对手玩家的HP、累加自己的分数等；客户端收到对手玩家转发来的消除信息后，在其对手棋盘上表现相应的消除过程与效果；如此循环往复，直至对局条件达到，如：某一方玩家HP&=0，或游戏对局时间到等；3.1.3&&&& 小结对比以上两类实时对战的实现方案，可以得出如下结论：
强同步方案一般适用于需要服务器作严格检查判定的场合，即游戏业务上，需要严防玩家作弊的情形。其中，阻塞同步方案在MMORPG中应用较多，如：战斗技能系统等；帧同步方案在ACT中经常使用，如：双人格斗游戏中的动作同步等；与强同步方案有所不同，弱同步方案所应用的游戏，往往更关心玩家的单机体验手感，而不是数值本身，因此，对于数据校验的要求也会低一些，如：Puzzle类休闲游戏；强同步方案的实现成本一般要高于弱同步方案，并且，由于强同步方案往往需要服务器实现比较复杂的逻辑运算，因此，其服务器的性能开销要较弱同步方案的大一些，相应地，服务器的承载能力就会较弱同步方案的低；3.2&&& 离线对战离线对战在实现层面需要关注点是多点数据的修改问题。即同一时刻，某个玩家可能会被他的多个好友同时发起挑战，而在挑战过程中，可能会同时修改对战双方的玩家数据。
多点数据的修改问题，目前都有比较成熟的解决方案，具体方案需要根据业务需求实际来选择：
全局逻辑锁方案实现要点是用一个单独的locksvr来保持数据修改时的同步。即玩家A发起对玩家B挑战，gamesvr在get玩家A和玩家B数据的同时，会lock这两者的数据。此时，若还有其他玩家需要get这两个玩家数据时，就会get失败，即锁冲突。这样就保证了，每次修改只会有一个玩家在操作。
该方案的优点：
好处在于单独的locksvr可以设计得比较通用，多个项目可以复用，一定程度上可以提高开发效率；locksvr逻辑上比较清晰，部署也比较方便。目前微连等项目就是采用的架构组提供的locksvr组件；不足的地方：
当交互比较频繁时，locksvr的机制可能会导致比较多的冲突，从而会影响玩家的游戏体验。这个问题在webgame中，玩家可能不会太敏感，这跟玩家的操作习惯有关，当冲突发生时，玩家一般刷新一下页面操作即可恢复正常。而在手机游戏中，需要根据具体游戏业务来评估；&
增量修改方案实现要点是gamesvr修改玩家数据时，只提交修改的相对值，各个gamesvr的修改数据请求汇总至一台中心服务器（热点服务器）进行，因为只有一个地方修改，故修改数据自然会保持队列同步。
该方案的优点：
最大的好处是不会产生修改引发的冲突问题；Gamesvr为无状态服务器，逻辑会比较简单；不足的地方：
要求修改的数据结构比较简单且单一，否则会导致中心服务器的逻辑处理复杂度成倍增加；由于所有数据的修改均在中心服务器进行，故其有单点风险；&
（三）Compare And Swap
实现要点保证每次提交的操作，只有一个是成功的。即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，只是客户端在表现手法上，与实时对战有所区别。以《女巫之战》为例，若换成半实时对战，则对战开始后，对战界面只显示玩家自己一个人的棋盘，对手玩家只显示一个Avatar Icon和血条。
半实时对战的实现方案可参考实时对战中的弱同步方案。
4&&&&&& 我们的选择上面讨论了三类对战需求，在实现层面上，可供选择的设计方案。并且分析了每种设计方案的优缺点和适用场合。咱们微项目具体选择哪种实现方案，需要根据特定的业务需求来决定。选择原则是：方案满足需求，实现代价最小。
发布于 WebGame游戏开发现状浅析（一）产品设计
&&& 1）新手设计无脑化、傻瓜化&&&&&&& 1. UI操作简单、直观、便捷；&&&&&&& 2. 短时间使玩家角色获得快速成长；&&& 2）针对付费的设计&&&&&&& 1. 第一时间让玩家产生付费的冲动；&&&&&&& 2. 付费点遍及游戏各个系统；&&& 3）内挂设计，减少外挂影响&&&&&&& 1. 自动寻路、自动拾取物品、自动战斗、自动补充HP/MP等；&&&&&&& 2. 自动换装（或者提示玩家换更强的装备）；&&& 4）提供玩家最大的满足感和爽快感&&&&&&& 1. 更好的游戏代入：游戏题材的选择，游戏世界观的设计等&&&&&&& 2. 深挖数值，但又不能使游戏系统过于复杂，即玩家能快速理解游戏玩法内容；（二）技术研发
&&& 1）提供跨服PK的功能，即不同大区的玩家能够同场竞技；&&&&&&& 技术关注点：不同大区的服务器是否部署在同一IDC？存储服务器数据分区部署 or 全Cluster共享？&&& 2）支持一机多服部署&&&&&&& 即同一台物理机器部署多个游戏世界&&& 3）形成一套核心研发机制和稳定的开发框架、基础库，保障核心功能快速复制（三）运营推广
&&& 1）快速开服，满足玩家“滚服”需求：《龙将》和《神仙道》做到了1天1服或1天2服，所谓“滚服”，即玩家会在不同服务器体验，目的是争取在新的服务器更高的排名和更大的满足感；&&& 2）开服第一周的收入是该服最主要的收入，也决定了运营商是否加大推广的力度；&&& 3）流量就是金钱，一般运营商的成本是每个人1-2元每人的流量成本；&&& 4）运营商可以提供机器，也可能让开发者自己租用机器和带宽，它只提供一个域名；（四）其它
&&& 1）核心玩家群特征：低粘性、高ARP值，即纯粹互联网用户，游戏只是其网络生活的一种典型应用；&&& 2）3–6个月完成一款RPG类webgame的全部开发，即正式付款公测；发布于 WebGame游戏服务器技术要点（一）服务器技术实现方案选择的问题？（1）选择标准WebServer+CGI开发（偏轻）【优点】&&& 1）快速开发：WebServer都是现成的，如：Nginx和Apache；CGI程序能也快速编程；&&& 2）灵活开发：整个后台服务可由多个CGI程序组成，一个CGI程序可以对应一项或多项业务功能，增加新功能时则增加新的CGI程序即可；&&& 3）不停机更新：部署新的CGI程序，不影响已运行的CGI程序；&&& 4）可适合处理SNS类玩家异步（离线）交互数据的情形；【不足】&&& 1）CGI程序如果过多，可能会加大维护的难度；&&& 2）业务需求如果要涉及到多个CGI程序之间的通信，即有状态的关联依赖，可能会有较复杂的逻辑和可能的性能瓶；（2）选择自定义通信服务器+GameSvr开发（偏重）【优点】&&& 1）可应对复杂业务逻辑的处理，如：业务需求之间的关联依赖较深等；&&& 2）可轻松处理玩家之间同步数据的需求；【不足】&&& 1）开发复杂度较大，需要较多的开发资源；（二）游戏服务器Cache设计方案【背景】&&& 1）游戏服务器cache数据可大大缓解数据存取时压力；&&& 2）多台分布式游戏服务器作Cache，可有效利用硬件资源；【实现方案】&&& 1）基于共享内存的对象池设计；【注意事项】&&& 1）数据一致性：对于SNS强交互类游戏，需要作多玩家修改同一数据的设计；&&& 2）数据同步的时机：根据业务数据的重要程度，分级设计同步时间，越重要的数据，同步时间越短；（三）游戏服务器数据分类设计方案【基本思想】&&& 把业务数据按重要程度进行分类，每类数据采用不同的存储和逻辑处理策略；&【应用说明】&&& SNS类游戏需要重点考虑（四）游戏服务器全局锁的设计【背景】&&& 1）同一玩家数据会被多玩家修改；&&& 2）某一Cache数据会被多个应用修改；【方案一】：热点数据分布在各个游戏服务器的Cache中&&& 1）数据被修改点（热点数据）设置一个全局Seq，如：玩家数据修改，则在玩家身上设置一个Seq；&&& 2）当Client读热点数据时，则直接返回数据给Client，并将Seq一齐带上；&&& 3）当Client写热点数据时，会在写数据请求里带上上次请求获得的该热点数据的Seq，热点数据的处理逻辑先比较写数据请求的Seq，是否与当前热点数据的Seq一致，若不一致（该请求来之前已被其它Client修改过），则有如下两种异步处理方案：&&&&&&& 1. 直接报错给请求Client，此时Client可能需要提示玩家重新刷新浏览器；&&&&&&& 2. 返回当前最新热点数据给请求Client，Client需要重新处理一遍之前的业务逻辑，再提交写数据请求；&&& 4）每次写热点数据成功后，热点数据本身的Seq加1；&&& 5）数据修改的逻辑统一在热点数据所在的游戏服务器处理；【方案二】：热点数据集中在一个全局公共服务器的Cache中&&& 实现方法与【方案一】类似【两个方案的比较】&&& 1）【方案一】：Cache分布在每台游戏服务器中，可以有效利用硬件资源，但SS交互逻辑复杂一些；&&& 2）【方案二】：可以减少一些SS协议的交互，但需要单独的全局Cache服务器；【注意事项】&&& 1）需要分别考虑玩家在线和离线数据的修改；&（五）如何有效利用机器的多核CPU1）多个通信服务器+1个游戏服务器；
&&& 2）多个通信服务器+多个游戏服务器；&（六）如何评估网络I/O的瓶颈&&& 1）网卡（1000M bit/100M bit）本身的极限处理能力：理论处理包的数量：网卡带宽[1000M bit]/（最小包大小[64Byte] * 8）；&&& 2）游戏业务对包的数量较包的大小更敏感，因为每个网络包在CPU处理时，会产生IO中断，因此，常用的策略是，合并多个请求包为一个包，提高带个包的信息量；&（七）深入了解MySQL的存储性能&&& 1）Mysql5.5+InnoDB1.1；&&& 2）Mysql的Cache解决方案；【声明：若有摘录，请注明来自】发布于 动作类网游技术难点分析1 背景动作类游戏（ACT）在百度百科上的定义是：由玩家所控制的人物根据周围环境的变化，利用键盘或者手柄、鼠标的按键做出一定的动作，如移动、跳跃、攻击、躲避、防守等，来达到游戏要求的相应目标。单机代表作有：《波斯王子》、《鬼泣》、《真三国无双》、《战神》等，而网游代表作有：《DNF》、《龙之谷》、《怪物猎人OL》等。
从技术层面来说，与传统MMORPG不同的是，动作类网游对于操作响应的网络时延要求极高，要保证较好的体验效果的话，一般要求时延小于150ms。如果网络时延较大的话，会带来对战双方（或多方）数据不一致的问题，即所谓的数据同步问题。因此，数据同步问题是动作类网游的首要问题，也是最大的问题。
下面将先描述数据同步问题的具体表现，再尝试分析目前业界常用的解决办法，最后简要讲述公司两个自研项目的实施方案。
2 问题聚焦下面列举的这些同步问题，也是大部分网络游戏共有的一些典型问题，如果处理不好，又会在动作类网游中进一步放大，从而极大的影响玩家体验。
2.1 位置不同步比如在T1时间，第三世界的玩家B看第一世界的玩家A在射程内并发起攻击，但此时玩家A正在跑出射程，当服务器收到玩家B的攻击请求，会判断玩家A已经在射程外了，如果服务器拒绝B的攻击，则会让B觉得很困惑，为什么明明在攻击范围内，却攻击不到呢？
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呢?
2.3 技能事件考虑冰冻情形，在T1时间，玩家A对玩家B施放冰冻，在T2时间，服务器收到报文，并下发冰冻确认，玩家B在T3时刻才收到自己被冰冻的消息，
如果在T3时间前，B没有收到被冰冻消息，进行移动，而移动报文又在T2时刻到达服务器，如果按照逻辑，服务器拒绝处理B的移动请求，那么就会产生B在第一视角的位置和服务器的位置不一致的现象，就会产生拖拽，如何避免拖拽呢？
其他诸如击晕，减速，恐惧，死亡等等，都类似冰冻情形，不再赘述
3解决方案3.1 帧同步原理玩家在发起战斗后，每隔一定时间在玩家的战斗动作序列中设置一个逻辑关键帧，在关键帧这个点，本机必须收到来自所有参与者反馈后才可继续执行其余的动作序列，否则，就进行锁帧、等待。这样就通过频繁对时（即在每一个关键帧节点上对齐），便可以像编写串行单机指令一样来进行多个客户端的事件指令同步了。
如下图所示：
优点简单易实现，不会出现任何的不一致性。在延迟小(& 100ms)且稳定的环境下非常合适。此外，在实时性要求不高的玩法(比如回合制玩法)中也非常合适。
缺点游戏节奏受最慢的那个玩家客户端影响巨大。一人卡机，所有人受影响。恶意玩家可以用伪造大延迟的方式来获得好处，从而破坏游戏公平性。
3.2 客户端承担消耗运算原理游戏比较消耗CPU的运算均放在玩家本地客户端执行，如：角色移动物理判定、战斗物理判定、AI逻辑判定等等。服务器只对影响玩家利益的关键信息作验证。
优点保证了游戏操作手感，避免了本机操作延时。
缺点运算逻辑存放在客户端，会带来较大的外挂风险。
3.3 游戏策划上的优化原理在游戏设计层面，来隐藏玩家的延迟感。比如：延长出招/收招动作时间、降低动作判定精度、给技能加公共CD、避免战斗受击时发生位移等等。
优点无任何技术风险，绿色、环保、安全，代价最小。
缺点可能会影响战斗的爽快感。
4 公司内项目的一些做法《QQ堂》和《炫斗之王》都是公司自研的动作休闲类游戏，在与其相关负责同事作了一些简要交流后，将他们的做法小结如下：
客户端之间采用P2P通信这对于在同一局域网内（如：网吧）的玩家，网络延迟很小。只有当两个Peer连结不同时，消息包才通过服务器中转；
客户端先表现，服务器后检验玩家角色在移动、战斗出招等操作时，客户端在发出请求包的同时，先自行在本机表现，继续后面的游戏逻辑，而无需等到服务器验证通过后才开始。
客户端的校验逻辑同时在服务器再运行一遍这也是惯用做法，即所谓的服务器强校验。
做好客户端反外挂由于采用P2P通信，有些逻辑难免会放在客户端，这与上述的一些解决方案的做法也是类似的。附上QQ堂对于反外挂处理的一个分享文档
5 小结综上所述，动作类网游在技术实施层面上，较传统MMORPG主要是在数据同步（多个Peer间、C/S间）上要求更加苛刻，当然，这目前在客户端平台上，也已经有了较为成熟的技术解决方案。但具体到页游平台，虽然从Flash10和Adobe AIR1.5开始，已经支持P2P通信，Adobe也在官方提供相应 的P2P服务，即代号为Cirrus，但目前尚未看到其在商业运营的页游项目里有成熟的应用。因此，在页游平台的P2P应用，还需要更进一步的探索和挖掘。
发布于 Social Game与MMORPG在服务器架构上的差异最近在作公司的一个Social Game的项目服务器架构设计，与之前做过的MMORPG（简称RPG）相比，差别还是较为明显的，现总结一二，以供分享！
（一）协议通信
1）Socail Game为了快速开发，在通信协议的选择上均会选择http作为底层通信协议，这样选择的好处大致有：
1、方便客户端编程：http为一应一答的同步模型；
2、可以选择成熟的开源http服务器，如：apache、nginx；
2）RPG选择的是基于socket的TCP通信，这是由游戏本身的特点所决定的，如：聊天、多人视野、服务器主动通知事件等需求
（二）游戏逻辑服务器的承受能力
1）RPG的游戏逻辑服务器（地图服务器）所能承载的最高在线（PCU）是在不等；
2）Social Game由于没有RPG复杂的移动、战斗、视野管理等需求，逻辑服务器承受的在线一般都是比较高的，如：不等
（三）游戏逻辑服务器的Cache和回写机制
1）RPG的游戏逻辑服务器一般都需要Cache玩家数据，并且采取定时回写的策略，如根据数据重要程度分别作5min-15min不等的定时回写；
2）Social Game的游戏逻辑服务器一般都无需Cache玩家数据，玩家的每次请求都是即时读即时写（这样会涉及到另外一个问题，即DB读写的性能问题，见下一条）；
（四）DB存储模型的选择
1）RPG存储服务器常用的还是MySQL+innodb，中间还由业务自己写一个Cache代理服务器，以Cache热点数据；
2）Social Game则会选用TC、MemCached等所谓Key-Value全内存数据存储，有实力的公司会自己实现一个类似这种机制的存储系统，它可以无源，也可以是有源，并且还可以选择用MySQL作数据落地，毕竟MySQL作为互联网业务DB的成熟解决方案，已毋庸置疑；
（注：我们公司是选择自己开发基于key-value机制的全内存DB，现网测试的数据是平均1KB的数据可以分别达到5w左右的读/写，还是很牛X的了）
（五）交互数据的一致性
1）在SNS Game中，会经常出现同一个玩家在某一个时刻同时被多个好友访问和修改数据的情况，这时就需要保证，每次数据的更新都是正常有序进行的，而不能被写脏数据。一般地，都会使用一个类似全局锁服务的设计来解决这个问题；
2）RPG不会存在这样的问题，类似的需求是：玩家可能会跨地图服务器，即所谓的跳线或跨服，这个问题的通常解决方案是服务器重新作一次下线、重登录的处理，当然，玩家是感觉不到的；
（六）IDC部署
1）RPG一般是分区分服部署；
2）Social Game则是全区全服部署；
呵，先写这些多，后面再慢慢补充，也欢迎同行朋友拍砖！：）
发布于 关于游戏服务器性能问题的几点思考（2）工作中对项目压力测试的一些心得，先自我作一个小结吧！
（一）宏观与微观相结合& （1）宏观层面&&&&&& 即系统的一些关键性能指标，如：各进程所占CPU的百分比、内存消耗、网络包量、磁盘IO等等，详细指标列举如下：名称 描述 参考值 CPU useage CPU 的使用时间百分比。 平均值小于70% Process virtual memery size 进程使用的内存空间总量，包括物理内存和swap内存 进程长时间运行后该值不能大幅度的改变，否则是内存泄露 Disk rate 磁盘传输速率 一般少于2M/s, 日志级别太低时硬盘io会是瓶颈。 Bytes trans rate 网络发送速率 少于200Mbps Bytes receive rate 网络接收速率 少于200Mbps Pages swap in 每秒钟读入到物理内存中的页数 长期大于0表示物理内存不足 Pages swap out 每秒钟写入页面文件页数 参考上面 Context switches rate 每秒钟在进程或线程之间的切换率。 少于5000*cpu个数 Interrupt rate 每秒内的设备中断数。该指标代表了本地向CPU引起的本地中断，例如IO端口引起中断，系统时钟引起中断。 一个巨大的中断值，同时伴随着缓慢的系统性能表现，指示存在硬件问题。 &&
&&& 测试工具：nmon& （2）微观层面&&&&&& 这里是指具体到Server程序的逻辑功能模块，包括函数消耗CPU周期、函数调用次数等资源占用情况，以及系统内核哪一部分最忙等。&&&&&& 测试工具：oprofile、gprof&（二）黑盒与白盒相结合& （1）黑盒测试&&&&&& 我们目前的压力测试程序，其实是归于黑盒测试范畴的，它模拟玩家的一些行为，应用具体项目的实际协议与被测游戏Server通讯，通过同时产生大规模机器人，来模拟与实际运营中相似的场景。这里编写的测试用例，其功能就是要尽可能真实地模拟client的功能，并能方便的配置化和部署client行为；& （2）白盒测试&&&&&& 我理解的白盒测试包括两部分，一是单元测试，它能有效地解决BUG回归测试的问题，二是代码覆盖率检查，它能有效检查到每个函数分支的执行情况。前者可借助业界成熟的自动化测试框架，如：cppunit、gtest；后者也有许多第三方工具，比较方便的有GNU自带的gcov，只要在编译程序时，加入-fprofile-arcs -ftest-coverage编译选项即可。&& 如果要用一句话来概括两者的话，那就是：& 白盒测试能极大的保障程序逻辑功能层面的正确性（正常与异常流程均能检测到），而黑盒测试则能有效保障程序运行的稳定性。发布于 MMORPG游戏在技能战斗中的位置同步问题这里列举在技能战斗系统开发中，碰到的两个与位置同步相关的问题
在MMORPG游戏中，对于那些同时拥有近攻和远程系等多种职业的游戏，策划一般都会对近攻类的职业，加上冲锋类的技能，以便平衡远程类职业在攻击距离上的优势。在client看到的效果，是玩家边播放冲锋动作，然后快速接近目标，并对目标一个伤害，而对server而言，该技能与其它技能在处理的不同之处在于，施法玩家在施法的同时，也作一个位置的变更。一般server的处理流程是，先检查冲锋直线路径是否合法（有无阻挡）和其它施法条件，若通过，则告诉client可以施法，并同时设置当前玩家坐标为冲锋后的坐标（该坐标由client带上来）。
由于server移动系统在对client发过来的移动数据作检验时，需要检查本次移动的起步点，是否为上次移动的结束点，即作线段端点合法检查，而冲锋到达的目标点并未在上次移动的路径栈信息中，所以，server技能系统在设置冲锋位置时，需要先清除原路径栈信息（如调用MoveStop接口），以便确认本次冲锋为一次全新的移动。
两个玩家同时使用冲锋技能时（目前client在做技能时，采用先表现的方式），出现一个玩家（冲锋目标client）停在冲锋途中的现象，原因为server广播技能施法时，没有带目标主动位移的信息（client在处理冲锋位置时，对于使用冲锋技能的client，因为它知道冲锋到达的位置，所以它的处理没有问题，而另一个冲锋目标client，由于它不知道对方要冲到哪里，则client处理时就是选择冲锋路径上的一点，这样就会看到停在冲锋途中了）所致。解决办法是，要么在协议中下发目标位移信息，要么在策划规则上，只允许同一时刻一个玩家冲锋，如：冲锋加晕眩debug等；
发布于 MMORPG中技能战斗系统的技术分享今天下午参加了公司兄弟项目组的一个技术分享会，主题是关于MMORPG游戏中的技能系统设计的，有几点体会和思考，先记录下来了！
（1）技能施法时，client只有一个上行的请求施法包，后续施法的过程全由server来驱动下发施法各阶段的结果信息，如吟唱、效果伤害、命中信息等等；
（2）弹道类技能是由server计算飞行时间，并不考虑飞行后的轨迹，若此时目标有移动，则client会做目标跟随的处理；
（3）技能学习：由秘籍来获得技能，一本秘籍包含多个技能，被动技能不影响主动技能的属性；
（4）Buff系统与技能系统是相互独立的，相互之间有接口各自的进行访问；
（5）玩家施法作群攻目标选定时，也是由server来完成，这时是从玩家自己的视野里搜索，而无需再搜一次动态区域（格子32*32）；
（6）技能效果由一个主效果+N个Buff效果组成；
（7）Buff对象区分玩家和怪物，其存储结构独立出来放在内存池中，在施法者需要时再根据目标类型来添加；
（8）特别小心：在作技能效果计算时，尽量避免有轮循的处理，因为，这个这个很耗CPU；
思考题：关于技能引发的位置同步问题
（1）对于改变目标（玩家）移动速度的技能，可能会带来位置不同步的问题，即server下发速度改变的包时，目标玩家可能正在移动，从而导致server和client的位置不一致？
答：对于这个问题，一般是通过移动系统自身的位置同步策略来解决的，即移动系统发现client和server位置不一致时，通过一定的策略来补偿速度慢的一方，从而在目标玩家在接来的一定时间内达到位置平衡。
（2）类似性质的问题还有给目标加冰冻、定身等Buff，也可能带来位置不同步的问题？
答：这个问题暂也还没有好的解决方案，目前的做法是当目标中定身Buff时，client立即表现定身，即定在原地，并将此时的位置信息带给server，server检验合法后设置这个位置，解冻后client为继续玩家移动（若玩家是移动中被定身住的话）。
阅读(1821)}