游戏服务器与普通服务器有何区别 - 产经要闻 - 科技讯
游戏服务器与普通服务器有何区别
游戏服务器是玩家玩游戏的主要场所,它里面装载着所有用户的登录、等级、装备等数据信息 根据天运科技有限公司服务器开发经验而言:与普通的服务器性比较,游戏服务器比一般的服务器要保存更多的状态,且每一个用户都是独立存在的 具体区别如下:
& & & & 游戏服务器是玩家玩游戏的主要场所,它里面装载着所有用户的登录、等级、装备等数据信息.根据天运有限公司服务器开发经验而言:与普通的服务器性比较,服务器比一般的服务器要保存更多的状态,且每一个用户都是独立存在的.具体区别如下:
　　首先,游戏服务器与普通服务器相比较来说,游戏服务器能保存更多的用户的状态.用户的等级等属性必用说,一般的IM服务也会有,还有一些马上就会变化的数据,比如某个玩家的生命值,发技能前后的法力值等等,这些值区别于一般的属性值如名字,ID这些的差异在于,会经常性的变化,还会参与到逻辑的计算中,比如你一个多少等级的玩家吃了什么东西之后战力值变化为多少,打在一个多少属性的玩家身上会不会被他闪避,会不会产生暴击...诸如此类的信息,在游戏服务器中皆会一一保存.
　　其次,游戏服务器中每一个用户都是独立存在的,每一个用户的数据、请求等都是独立的,用户彼此间的数据并没有任何交互.这也是游戏服务器与普通服务器之间最大的区别.至于客户端之间会有交互这一点,举最简单的例子,一个人在一个场景里面说了一句话,那么同一个屏幕的玩家也需要能够看到他说的这句话.此时游戏服务器就需要判断,多远的距离以内的玩家,会认定为是&同屏幕&的玩家,需要向这些玩家广播这个玩家说的这句话.
　　这个广播就比较麻烦了.首先,计算哪些玩家在&同屏幕&,就是我们在第一点提到的玩家身上某些经常变化的属性需要做的运算,在这里需要根据玩家的坐标,找出来跟在同屏幕的玩家,用到的是AOI的概念.另外,找到了这些需要接收这个消息的玩家之后,将消息转发给它们又是一个IO密集的操作,假如场景中有10个人,那么一句话就需要同时广播给另外9个人,假如有100人,1000人呢,量就更大了.所以同样的一个硬件配置的服务器,可能跑Nginx可以同时处理上万的链接,但是对于一个游戏服务器就只有1,2千了,就是因为游戏服务器是一个CPU密集而且IO密集的服务器类型.
　　此外,游戏服务器需要更好的数据承载能力和处理能力.而普通服务器则在各个方面都比较均衡.在寻找游戏服务器租用商的时候,一定要选择那种cpu性能非常出色的.普通服务器的则不需要那么强的能力.
　　以上信息转自天运科技官网，更多的问题请您联系我们的客服.
换一换
& 科技讯版权所有根据情况不同，客户端做的事情都有不同。服务器至少要做验证。相对于网络游戏来说，数据传输量在一定程度上可以忽略，而更注重数据来回时间。在一般情况下，比如说WOW里面，200MS延迟就开始变黄。也就是说在一般对时间要求不是很极端的，比如KOF97转到MMO，200可以默认为一个普通MMO的标准线。具体来说，理想上的网游，个人倾向于所有逻辑处理全放服务器端，而客户端就像个媒体播放器。这是因为如同某本书讲得，客户端是掌握在对手手中，如果你让服务器只起到数据交换作用，那么外挂就可以彻底糟蹋你的游戏。在理想基础上，客户端要做的事就是表演，根据服务器和用户的输入处理，进行各种场景、动作与特效的播放。包括绘制角色（动态物件）、绘制场景（相对静态物件）、绘制光照、物件、光照排序、动态物件动画的播放。当然这是基于理想基础之上的，实际上的制作会有很多变化。比如休闲游戏，因为它要求响应比较迅速（比如泡泡堂，加速后的角色跑起来的速度飞快，你怎么保证其他客户端能够实时看到对方所在位置。不然就炸不到了），所以在这种需求之下，客户端开始承接更多的活计，比如客户端不单是播放功能，还加上了判断，先执行了客户端的判断去追求表演的流畅性。当然，为了安全，最后数据一样要通过服务器端验证，验证不通过就纠正回来。又因为纠正很粗暴，所以现在还开始增加一些纠正机制，让纠正的过程看上去柔和些，比如WOW里面，有时候你会看到其他怪物或角色拖着速度线飞快的移动到其他地方，那就是柔和纠正机制。用具体事例来说，举个例子：聊天。一个游戏如此设定，一个玩家当使用&当前频道&时，只能让周围50米的玩家收到。于是。玩家A输入了一堆话，这个时候客户端接收，并立即发送到服务器端。服务器端固定周期处理一次所有聊天信息，比如200毫秒，客户端送到的时候，正好上一个200毫秒过去了，于是排在下一个200毫秒的队列里。这个时候任何客户端是没办法看到聊天信息的，包括A端（假定是这么设定的，这个就是有的时候你网络卡的时候，明明按了回车，对话框却不冒出任何聊天信息的原因）。时间在流逝，服务器开始跑队列，并跑到这个地方了，于是它开始运算，第一是判断这句聊天对话是当前频道、世界频道还是其他，判定结果是当前，于是执行当前频道的处理：读取这个玩家所在位置，搜索这个位置方圆50米的其他玩家，向这些玩家包括A端广播聊天信息（假如还有黑名单功能，还要剔除黑名单玩家；假如付费用户字体还有特殊颜色，还要传播这个对话的风格）。所有客户端收到信息，然后再聊天频道里播放这条信息。于是大家都看到了。而基本上这整个过程，包括玩家位置信息，包括玩家聊天内容，大小不可能超过1KB，就算是加密后。也就是这种数据量在正常情况下是可以忽略的。这个也是一般网络游戏的传输数据量标准。更重要的是两个参数，第一玩家信息包传送到服务器并由服务器返回的时间；第二服务器处理事件的周期。而除了UI位置这些琐碎无关于角色的信息，其他信息都应该保存在服务器端。保存在客户端的应该是资源，包括角色模型、动画、场景、特效等，部分游戏也将大量文本保存在客户端，比如任务对话。而重要信息，特别是任何将对自己或其他玩家有影响有改动的信息都应该放在服务器端。比如角色的经验、甚至比如你接到的任务（如果你保存在客户端，你换台机，以前接到的任务就都没了）。至于客户端向服务器端什么时候发送消息，多少频率，那一般是个长连接，只要信息量没超过KB，影响都不太大。实际上，只要你登录以后，服务器端和客户端就一直在相互通信。哪怕你不动，服务器都会因为你有可能接受到聊天信息而不停的给你塞消息。所以这个还是让程序去头疼，他们是专业。事情大体上就是这样。
阅读(...) 评论()后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
游戏服务器和一般服务器对比，有何特别？
文/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-游戏行
关注手游动态微信公众号
楼主总结得很详细！
只是一般互联网业务服务器与游戏服务器应用场景完全不同。
R2Games联合福建网龙签下传奇巨星李小龙IP滴滴式代练火了,日流水超千万,为你揭秘游戏腾讯辟谣王者荣耀年终奖100个月工资 难道是《肮脏的中餐馆》开发商就辱华事件道歉《率土之滨》基本分析及问题改进建议一个普通玩家的成长之路：我为什么总是忍不
微信扫一扫关注我们→MMO只是一个泛指，现在很多游戏表现形式不是MMO实际上都是MMO。除了梦幻大话剑侠情缘这种的一看就是MMO的之外，像COK这种的实际上也都是MMO。
弱交互游戏同样是一个泛指，在几年前的时候特指异步交互的卡牌游戏，现在可以用来指一切交互有限的手游，比如所有围绕推图做的arpg/动作卡牌，以及社交游戏。
那这两大类游戏的游戏服务端在哪些方面区别呢？
简单地说就是逻辑的复杂度。
我们对游戏服务端的最简单的认知就是将其看作一个状态机。
就状态机的复杂度（状态的数量级）而言，MMO游戏（特别是端游MMO）的场景服务器的逻辑复杂度是弱交互游戏（包括社交页游和一切服务端不维护场景状态的手游）无法比拟的。
列举几个具体的：
移动同步相关的逻辑是许多MMO端游程序员的优越感之一，君不见各种媒体上发声的业内大佬们特别喜欢说MMO手游具有技术门槛，没技术的团队做不了。其实他们如果真的不是指场景制作流程上的难度，那就是在说移动同步小团队做不了。
实际上，移动同步除了各种自以为是的猥琐得不能再猥琐的（猥琐部分的代码量相当大）特殊的优化表现的技巧之外，再无技术可言。
场景状态同步
MMO游戏与其他游戏服务端的一个显著不同就是大部分场景状态是在服务端维护的，因此会有一个时间驱动的主逻辑在这里。场景状态包括各种怪的逻辑，玩家的定时器等等。而且由于MMO的一个场景中会有复数个玩家，场景的状态需要同步给玩家，但是不能每帧都全同步。于是就有了MMO特定的一些优化技巧，比如AOI。
这部分要说有技术含量吧，确实也有。但是原理简单，需要的人天也少。因此大多数MMO程序员是接触不到的。
MMO游戏最典型的一种需求是玩家从一个地方移动到另一个地方，这两个地方假设在服务端属于不同的场景，那就需要服务端处理一下将玩家的上下文从一个场景迁移到另一个场景的逻辑。这部分逻辑算是比较复杂的了，也会涉及一些包序列、包过期的问题，虽然大概想想不是特别难，但是具体实现上坑比较多。也是MMO的一个特点了。
然后我们再回头来看弱交互游戏，处理循环基本可以简化为：一个request上来，经过一定节点路由，路由到一个逻辑节点，逻辑节点从一个地方（可以是进程内，可以是从缓存）取一下玩家数据，处理一下，存回玩家数据。
这就是两者大概的区别了。
但是，相信各位跟小说君一样，在很多jd中看到指明需要大型端游开发经验，这样一想，做弱交互游戏的服务端程序想转型去做MMO游戏的服务端程序岂不是非常艰难？
实际上，写出这种jd是一方面，还是要具体看招聘方对候选者的需求是什么。
MMO游戏的战斗逻辑是非常复杂的。比如技能逻辑、怪逻辑、结算逻辑，策划面向程序的需求迭代最频繁的部分基本都是围绕这些点展开的，而这些点说实话还是比较业务逻辑狗的，通常有经验有追求的干一段时间这个就不想维护了，要么想走人找更好的岗位要么想培养接盘侠，所以社招的时候肯定需求有过相关经验的程序。但是这一块经验往往需要做过MMO游戏，所以如果想招做战斗模块的服务端这样写并没太大问题。
但是对于另一种招聘需求，就是做服务端的性能优化相关的，或者说维护一些比较独立的全局系统，其实跟做什么游戏类型是没太大关系的。要求无非就是操作系统网络什么的老几样。当然最重要的是定位问题、解决问题的能力。
而且MMO游戏的服务端由于重点关注的是逻辑复杂度，其实分布式这个方向上发展的不如弱交互游戏，后者的服务端转过来理论上讲应该不会特别适应。当然两边都是写逻辑的话，转来转去没什么本质区别。
个人订阅号：gamedev101「说给开发游戏的你」，聊聊服务端，聊聊游戏开发。
本文已收录于以下专栏：
相关文章推荐
只做学习使用，勿做他用
设计思想/框架 网络通讯 
本帖最后由 小...
ServerSocket类，此类实现服务端的套接字，Socket类，此类实现客户端的套接字，而套接字就是两台机器间通信的端点，所以就用ServerSocket类和Socket类实现客户端与服务端的交互...
本文主要包括以下内容
android与struts2服务器实现登陆
android从struts2服务器获取list数据
android上传数据到struts2服务器
服务器端代码packa...
有如下需求：使用httpclient向服务端发送xml文件，然后服务端收到信息后会做些判断，然后返回给客户端一些信息。
实现思路：利用httpclient post方法向服务端发送流文件，然后通...
他的最新文章
讲师：王哲涵
讲师：韦玮
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)