游戏服务器与Web服务器的不同？对于游戏服务器的一些介绍也许会说游戏服务器是一个需要长时间运行的程序，接下来该怎么办。对于Web服务器，我个人认为需要长时间运行，而且还需要对非定点、不定时的请求作出响应。二者在宏观层面实际上并无本质的不同。与此同时Web服务器还会对稳定性和性能有要求，游戏服一般分为大小服，我们这里按小服举例来说。
3.1国家。
第一个要提到的是状态。也许你听过这样一种观点，游戏服务器是有状态的，而Web服务器是无状态的。这意味着什么？Web服务器的数据流大部分直接到达数据库。并且游戏服务器的数据流先被存入内存，然后定期写入数据库(落地)。
换言之，在运行时，游戏服务器自身的数据和数据库中的数据将有一个不一致的窗口。这个时候，游戏服务器出现故障，将导致数据先到达的内存数据与数据库存数据不一致。
但是Web服务器并没有这个问题，Web上所有的数据状态都会出现，并且可以在操作中添加事务，不必担心由于操作失败而引入脏数据。由于存在状态限制，游戏服务器将非常谨慎地使用内存、CPU。在资源有限的条件下，为了最大化承载量，并减少服务延迟。自然，Web服务器需要进行相应的优化，以减少特定接口的响应时间。
3.2扩建。
对于Web服务器，如果您不能评估服务者所面临的压力，也不希望由于即时热点访问而直接导致服务不可用，则可以将其设置为自动扩展，因为每个服务仅仅是简单地接收请求，然后处理请求、返回结果，而不会将数据保存在服务器的内存中。为了将数据存储到内存，Redis中同样如此。而且Redis数据丢失对数据的一致性基本上没有影响。
但要实现游戏服务器的灵活性，就难以达到网络的灵活性。第一，数据流不是数据库，而是内存。
举例来说，玩家的主要城市都被攻打着火烧，如果有自动扩容，很有可能在落地窗口中，玩家再次请求，请求到另一个。主要城市又没起火。由于数据将首先存在于内存中。
又比如，玩家氪空间购买了一个礼包。接着退出游戏，在落地窗口中再次上线没有。这个数据并不简单，玩家这是花真金白银买来的道具，突然间没了，一、两个还好处理，如果多个玩家都有这样的问题，那就属于严重的线上事故了。修理资料的工作非常繁重。
因此，对一个游戏服务器来说，内存和CPU的可用资源都非常有限，不像Web服务器那样可以实现横向扩展，而不必花费大量成本。正因为如此，游戏服务器才会非常专注于代码的性能和稳定性。
3.3稳定。
正如上面所说的，如果游戏服务器在运行中出现BUG，导致服务直接无法使用，或者在BUG上刷到大量道具，将会是一次很严重的在线事故。
对Web服务器而言，如果是管理系统这样的话，很可能会有脏数据值得注意，脏数据对于Web来说，查找起来也是一件很头痛的事。在没有脏数据的情况下，服务只是暂时不可用，并且如果使用了微服务体系结构，重新启动服务的成本相对较低，只有被重新启动服务的业务无法获得，而其他部分则可以正常访问。
对游戏服务器而言，服务器重新启动会影响全服玩家。停服期间，玩家甚至不能进入游戏，尤其影响玩家体验。此外，如果在停用之前服务器的数据落地发生问题，那么在服务重新启动后将数据从数据库加载到内存，此时同样会导致数据不一致的问题。
3.4性能。
以我的经验来看，在做Web服务器时，没有为了减轻GC的压力，而是为了更少地使用内存而进行过度优化。自然，这是因为游戏服务器本身没有太大的体积，如果QPS很高，Web服务器也同样需要关注性能，不过游戏服务器总是需要特别关注这个方面。
但是在网络上，如果流量过大会导致单一服务无法承受压力，那么大多数人首先想到的解决办法就是做多个例子，毕竟可以实现很容易的横向扩展。
而在游戏服务器上，将会看到服务器资源相当珍贵。举例来说，能够不落地的字段是绝对不会落地的，一个字段的值可以根据已知的条件计算，尽量不要在代码中定义。但它也要视情况而定，权衡运算量和呼叫次数。由于上线后，如果遇到数据不一致，维护的数据越少，修复数据就越困难。
3.5严格。
从这个角度来看，我想两个公司都非常重视。不过，如果服务器抛出了异常或panic，则游戏服务器也会这样。它所产生的结果将在游戏的特殊环境中放大。
举例来说，召回你的队伍失败了，那么军队就会离开并且无法使用。与在浏览器中点一个按钮无反应相比，这种影响相对较小。此外，通过采用微服务体系结构，可以以非常低的成本重新启动相应的服务，并且游戏服务器还会修复一次数据。
另一个极端的例子就是点击商店，玩家要准备氪金。但却发现进不了商店，也可能无法拿到商品清单。这将直接影响游戏的体验，甚至收益。
对网络而言，服务器的稳定也同样重要。否则，就会因业务的不同而导致后果的严重程度而不同。对用户体验的影响，将直接影响产品口碑。
3.6资料传送格式。
熟知网络的人知道，数据传输格式是JSON。游戏服务器是Protobuf，是Google开发的数据传输格式，类似于JSON。Protobuf是二进制的，并且二进制数据量要小于JSON。此外，如果传输的字段为空值，则无法传送。JSON如果为null值，将传送相同的值。
Protobuf无论在哪一种环境中，比如Node.js和Java，都比JSON更好。Protobuf的速度比JSON还要快近80%。在Java的服务间通信存在性能瓶颈时，考虑使用RPC在服务间进行通信。
但任何事情都有两个方面。Protobuf的缺点依然存在：
文件更少。
团体和JSON相比较。
JSON不像JSON好。
4总结
上面所说的就是这两个月，总结出来的不同之处。只是大体上作了对比，没有任何详细的细节。以后还可以单独讨论具体的细节。
