游戏服务器:游戏服务器和web服务器的区别
【小编提示】本文部分内容摘自网络,仅供参考!如需了解服务器租用\托管相关问题,请咨询YINGSOO专业客服,享受1V1贴心服务!免费热线400-630-3752
【选购帮助】国外vps网站加速
用go语言写游戏服务器也有一个多月了,也能够明显的感受到两者的区别。这篇文章就是想具体的聊聊其中的区别。当然,在了解区别之间,我们先简单的了解一下go语言本身。
go语言的特点
go语言跟其他的语言例如Java比起来,算得上一门很年轻的语言。go语言是由Robert griesemer、Rob pike和Ken thompson于2007年在google开发。并于2009年正式发布。
go语言的设计理念围绕着简洁这两个字,认为少即是多。如果你熟悉Java,用Java那一套语法命名跟go做对比,可以很明显的体会到这种感觉。
go的特点可以简单的概括成以下几个点。
静态类型和编译型
首先go是静态类型,静态类型就是编译时就知道每一个变量的类型,得益于此,在编译的阶段就能够发现很多问题。而如果是动态语言,例如Javascript,有些问题直到运行时才能发现。
go是编译型语言,看到编译型大家脑子里可能会想到另外一个词解释型。两者的区别从字面上来理解其实已经可以看出来,我用一个简单的例子来类比一下。
编译型 去餐馆吃饭,点了菜之后,饭店会等所有的菜做好了再上
解释型 去餐馆吃饭,点了菜之后,陆陆续续的边吃边上
跨平台
顾名思义,你写的go源码在所有的系统都能够运行。
这点其实很好理解,例如Java的口号是”write once, run anywhere”。我们都知道Java是编译型的语言,但是Java在编译的时候生成的是字节码,这个字节码与当前的操作系统无关,与cpU也无关。
这种字节码必须依赖Java虚拟机才能运行,而虚拟机会将操作系统和cpU之间的差异与用户屏蔽。对于编程的人来说这个过程其实无感知的。而对Java来说,语言本身的跨平台并不能代表代码可以跨平台。
go的跨平台从某种方面来说,与Java类型,我们需要安装与当前操作系统相对应版本的go。编译出来的可执行文件会根据操作系统的不同而有所不同。
自动垃圾回收
与JVm一样,go在运行时的内存管理(gc)由go语言本身来管理,不需要程序员的参与,但是我们可以干预。
原生的并发编程
何为原生?我们都知道,在Java中如果要实现并发, 需要外部的类库支持(thread),而go不需要从外部再引入任何依赖。支持使用关键字go即可。而且Java中是通过共享内存进行通信的,熟悉go的应该都看过一句话“不要通过共享内存来通信,而应该通过通信来共享内存”
完善的构建工具
从获取、编译、测试、安装、运行和分析等一系列流程都有自己的内置工具。例如获取可以使用go get命令来下载更新指定的代码包,并且对它们进行编译和安装,可以使用go build 对源码[日本vps]进行编译,用go run命令来运行go的程序,用go fmt来快速格式化代码,统一代码风格。
多范式编程
目前主流的编程范式有命令式编程、函数式编程和我们最熟悉的面向对象编程。在编写go的代码的时候,我们可以选择使用面向对象的方法,也可以使用函数式编程的思想,相互结合,相辅相成。
例如,在go里面也可以用接口来描述行为,也可以使用纯函数来避免出现副作用。因此,多范式编程就是指这个语言支持多种编程范式的。
代码风格强统一
使用go的内置工具go fmt即可快速的将代码格式化成官方统一的标准,以此来达到代码风格统一的目的。甚至可以用golangci-lint来检测你的语法跟内置的标准语法是否有冲突,完全可以将这个检测工具挂在git的钩子上,以此来达到强制的代码风格统一的目的。
活跃的社区
还有一个很重要的特点是,国内的go的社区十分的活跃,这对于go在国内的普及起到了很大的作用。
用go的优势
先说一下我对go语言的看法,我认为go在服务器这块是非常有优势的。以后如果有高并发的应用场景,那么大概率这个服务就是用go写的。不知道大家有没有发现,摩尔定律正在失效。近十年内,硬件的原始处理能力都没有太大的提升。显然,一味的增加晶体管的数量已经不是解决问题最好的方法。
nAsA前不久发布到官网然后又迅速删掉的文章透露了,google可能已经实现了量子霸权,通俗一点说就是拥有超越所有传统计算机的计算能力。而放置更多的晶体管的代价也越来越高,所以现在厂商都在向处理器中添加更多的内核来提升性能。
就像大家熟悉的Java,虽然Java本身支持多线程,但是在Java上使用多线程编程代码算是比较昂贵的。在Java中创建一个新的线程就会消耗接近1m左右的内存。假如你真的需要支持运行上千个线程,那么服务很可能运行着就oom了。除了内存消耗外,还会存在由于支持多线程带来的并发和死锁等问题。
而go中,使用协程来代替线程。而且一个协程所消耗的内存比线程少了很多倍。同样的物理设备限制,你可能只能启动最多几千个线程,而协程能够启动上百万个。而且不同的goroutine可以通过信channel进行安全的通信。
游戏服务器和web服务器的区别
有些对游戏服务器的介绍可能会说,游戏服务器是一个需要长期运行的程序,然后怎么怎么样。我个人认为web服务器一样的需要长期运行,也需要响应不定点不定时来自用户的请求。两者从宏观上来看其实没有本质的区别。同时web服务器也会对于稳定性和性能有要求,游戏服一般分为大小服,我们这里都按照小服举例子。
状态
首先要提到的就是状态。可能你会听说过一个概念,游戏服务器是有状态的,而web服务器是无状态的。什么意思呢?web服务器的数据流大多直接会到数据库中。而游戏服务器的数据流首先会到内存中,然后定期的写入数据库(落地)。
换句话说,游戏服务器本身的数据与数据库中的数据在运行期间会存在一个数据不一致的窗口。如果此时游戏服务器宕机了,那么就会造成数据首先到的内存数据与数据库存的数据不一致。
而web服务器则不会有这样的问题,web所有的数据状态都会落地,而且可以针对操作加上事务,不用担心因为操作失败而引入脏数据。正因为有了状态的约束,游戏服务器就会很慎重的使用内存、cpU。以求在资源有限的情况下,最大化的提高的承载量,并且降低服务延迟。当然,web服务器会为了降低某个接口的响应时间而去做对应的优化。
扩容
在web服务器中,如果你不能评估一个服务所面临的压力,又不想因为瞬时的热点访问导致服务直接不可用的话,完全可以设置成自动扩容,因为每个服务只是单纯的接收请求,然后处理请求、返回结果,不会将数据保存在服务器的内存中。要有数据存到内存,那也是在Redis中。而Redis数据丢失对数据的一致性基本没有影响。
但是在游戏服务器这边很难做到像web那样灵活。首先,数据的流向不是数据库,而是内存。
举个很简单的例子,玩家的主城被攻打着火了,如果有了自动扩容,很有可能在落地的窗口内,玩家再请求一次,请求到了另一个实例。主城又没有着火了。因为数据都会先存在内存中。
再举一个例子,玩家氪金买了一个礼包。然后退出游戏,落地窗口内再次上线没了。这就不是单纯的数据问题了,玩家这是花了真金白银买的道具,突然就没了,一两个还好处理,如果多个玩家都出现这样的问题,那这就属于严重的线上事故了。修复数据的工作量十分的大。
所以,对于一个游戏服务器,所能使用的内存和cpU的资源是非常有限的,不像web服务器可以不用花很大的代价做到横向扩展。这也就是为什么游戏服务器会十分十分的注重代码的性能以及稳定性。
稳定
就像上面说的例子,如果游戏服务器运行中出了bUg,导致服务直接不可用,或者说通过这个bUg刷到了大量的道具,将是一个非常严重的线上事故。
而对于web服务器来说,如果是管理系统之类的,有可能会有脏数据值得一提的是,脏数据对于web来说,排查起来也是一件很头疼的事情。如果没有脏数据,只是服务暂且不可用,而且如果用的是微服务架构,重启服务的代价是相对来说比较小的,只有正在重启的服务的业务是不可用的,其余的部分则可以正常的访问。
而对于游戏服务器来说,服务器重启影响的是全服的玩家。玩家在停服期间,甚至连游戏都进不了,特别的影响玩家体验。而且,如果停服之前服务器的数据落地出现了问题,服务重启之后会将数据从数据库load到内存中,此时同样会造成数据不一致的问题。
性能
从我的经验来看,在做web服务器的时候,没有为了减少gc的压力,为了少占用内存去做过多的优化。当然这是因为项目本身的体量不大,如果Qps很高的话,web服务器同样很需要注重性能,只不过游戏服务器需要一直特别注意这个方面。
不过在web,如果访问量很大的话导致单个服务不能扛住压力,大部分人首先想到的解决方案应该就是搞多个实例,毕竟可以做到很轻松的横向扩展。
在游戏服务器里,会把服务器的资源看的相当的宝贵。例如,能不落地的字段就绝对不要落地,某个字段的值可以通过已知的条件算出来的,就尽量不要定义在代码里。不过这也要看具体情况权衡运算量和调用的频率。因为上线之后,如果遇到了数据不一致,维护的数据越少,修复数据的难度就越小。
严谨
这[美国主机租用]一点上来说,我认为是两者都很关注的一个重点。只不过,在游戏服务器的某些情况中,如果服务器抛出异常或者panic。其造成的后果会被游戏特殊的环境放大。
例如,召回你的在外部队失败了,那么部队就会一直在外面且不可用。这跟在浏览器中点一个按钮没有反应比起来,影响相对较小。而且使用微服务架构,在修复问题之后可以以很低的成本来重启对应的服务,而游戏服务器中还要修复一次数据。
再举一个很极端的例子,点击商店,玩家要准备氪金了。但是却发现进不了商店,也可能不能获取商品列表。这些会直接影响到游戏的体验,甚至收入。
而对于web来说,服务器的稳定性同样很重要。不然根据业务的不同,造成后果的严重性也有可能不同。影响了用户体验,就会直接影响到产品的口碑。
数据传输格式
熟悉web的都知道,数据传输格式是Json。而在游戏服务器中是protobuf,是由google开发的数据传输格式,与Json类似。protobuf是二进制的,二进制数据量会比Json更小一点。而且,如果传输的字段是空值,就不会被传输。而Json如果是空值,一样的也会被传输。
无论是在什么样的环境中,举个例子,node.js和Java中,protobuf的性能表现都比Json好。在Java中,protobuf甚至要比Json快了接近80%。如果Java的服务之间通信有了性能瓶颈, 可以考虑服务之间使用Rpc来通信。
但是凡事都具有两面性。protobuf的缺点仍然存在:
文档较少
社区与Json的对比起来
可读性没有Json好
总结
以上就是这两个月以来,总结的两者的区别。只是从大体上做了一个对比,并没有具体深入细节。细节的话有可能会在以后单独的来介绍。(来源:sH的全栈笔记)
本公司专业提供最安全的海外游戏解决方案、游戏数据安全解决方案、游戏服务器配置安全、游戏服务器架设方案。详询本公司客服电话400-630-3752。
香港独立服务器租用的安全性表现在哪个
香港独[vps网站根目录]立服务器更受站长青睐的原因,不外乎是因为独立服务器拥有更多的自主性、更强的安全性和卓越的性能等原因。小Y相信大家对于香港独立服务器拥有更好的自主[托管服务器]性和性能都是可以理解的,但是安全性这一方面还是存在疑问,因为不知道香港独立服务器更强的安全性是怎么样的?表现是如何?
一、服务器隔离
使用香港独立服务器托管业务,是需要服务器完全控制的企业首选。通过定制化的业务托管方案,您将拥有一个完整的物理服务器,您可以随意添加和删除资源。无论您是建立网站、托管海量玩家在线的游戏还是开发设计应用程序,您都可以利用整台服务器大量资源来有效地完成项目和业务相关任务。您不必再担心过度负载或者难以充分利用您所支付的磁盘空间、带宽和CPU。无论何时需要添加或删除资源,您都可以方便地进行。
二、顶级安全
当涉及到安全性时,没有比独立服务器更好的托管解决方案。除了无限的资源,无与伦比的安全性也是企业选择香港独立服务器的主要原因之一。值得信赖的香港服务器供应商通常会采取措施从数据中心角度保障服务器本身的安全,同时,您可以利用最高管理权限部署最新的安全软件、升级和修补程序漏洞,以及其他所有安全保护措施,而不必担心资源瓶颈。无论您的安全和隐私要求如何,香港独立服务器都能成为您实现关键任务数据保护的理想选择。
三、无与伦比的性能表现
高性能和极低甚至无停机时间是众多企业选择香港独立服务器的重要出发点。独享服务器的优质资源可以消除来自共享环境下多用户或多业务数据和资源的问题风险。如果使用共享主机,您的使用体验可能受到其他租户滥用资源等行为的影响,最终很容易使您的业务拓展陷入僵局。香港独立服务器,可允许用户独占整台物理服务器资源,确保只有受限制的用户组可以访问该资源。这样一来,您的业务运行不会受到过度拥挤或失去潜在客户的风险影响。
YINGSOO免费热线:4006_303_752
热门文章:【香港远程控制服务器是如何使用的】【攻击打不垮】【香港服务器2香港服务器200元永久能信吗】【国外服务器ip大全】【华为云香港服务器】【企业应该怎样进行云迁移】【影响浙江服务器托管价格因素】【浙江服务器租用】【永久免费香港虚拟主机】【dns服务器未响应】【流媒体怎么选服务器】【香港机房价格】【国内云主机评测该怎么做呢】【泰州BGP】【裸金属服务器和云主机服务器】【德国服务器该如何选择】【什么情况下电子商务网站会选择俄罗斯云主机】【低延迟直播服务器】【YINGSOO香港服务器托管需要注意什么】【香港ecs】
YINGSOO日本主机服务商_低至148元/月_注册领代金券
稳定,性价比超高,按需配置购买,满足不同需求,日本主机服务商免备案,高级DDOS防护,专业数据灾备方案,24小时贴心服务日本主机服务商.
https://www.yingsoo.com/products/cloud-jp.html
Yingsoo香港悍铭主机采用CN2电信直连香港,速度延迟低至10ms,快速,安全,稳定,免备案9年运营经验, 服务超过1200家企业客户,连续9年香港悍铭主机销量持续增长
https://www.yingsoo.com/products/cloud-hk.html
版权声明:本站文章来源标注为YINGSOO的内容版权均为本站所有,欢迎引用、转载,请保持原文完整并注明来源及原文链接。禁止复制或仿造本网站,禁止在非www.yingsoo.com所属的服务器上建立镜像,否则将依法追究法律责任。本站部分内容来源于网友推荐、互联网收集整理而来,仅供学习参考,不代表本站立场,如有内容涉嫌侵权,请联系alex-e#qq.com处理。