站务联系
而对于游戏服务器来说，服务器重启影响的是全服的玩家。玩家在停服其间，甚至连游戏都进不了，特别的影响玩家感受。而且，如果停服之前服务器的数据落地出现了问题，服务重启以后会将数据从数据库load至显存中，此时同样会导致数据不一致的问题。
3.4 性能
从我的经验来看，在做Web服务器的时侯，没有为了提高GC的压力，为了少占用显存去做过多的优化。当然这是因为项目原本的体量不大，如果QPS很高的话，Web服务器同样太还要重视功耗，只不过游戏服务器还要经常非常留意这个方面。
不过在Web，如果访问量巨大的话引起单个服务不能扛住压力，大部分人首先想起的解决方案应当就是弄多个例子，毕竟可以做到太轻松的纵向扩充。
在游戏服务器里，会把服务器的资源看的相当的宝贵。例如，能不落地的数组就绝对不要落地，某个数组的值可以通过已知的条件算进去的，就尽量不要定义在代码里。不过这也要看详细状况考量运算量跟读取的速率。因为上线以后，如果碰到了数据不一致，维护的数据越少，修复数据的难度就越小。
3.5 严谨
这一点上来说，我觉得是二者都太关注的一个重点。只不过，在游戏服务器的某种状况中，如果服务器抛出异常或则panic。其导致的后果会被游戏特殊的环境放大。
例如，召回你的在外军队失败了，那么军队都会经常在外边且不可用。这和在浏览器中点一个按键没有反应比上去，影响相对较小。而且使用微服务构架，在修补问题以后可以以太低的费用来重启对应的服务，而游戏服务器中需要修补一次数据。
再举一个太极端的事例，点击商场，玩家要打算爆肝了。但是竟发觉进不了商场，也可能不能获取商品列表。这些会直接影响至游戏的感受，甚至收入。
而对于Web来说，服务器的稳定性同样很重要。不然依照业务的不同，造成后果的严重性还有或许不同。影响了用户感受，就会直接影响至产品的口碑。
3.6 数据传输格式
熟悉Web的都晓得，数据传输格式是JSON。而在游戏服务器中是Protobuf，是由Google开发的数据传输格式，与JSON类似。Protobuf是二进制的，二进制数据量会比JSON更小一点。而且，如果传输的数组是空值，就不会被传输。而JSON假如是空值，一样的也会被传输。
无论是在什么样的环境中，举个实例，Node.js跟Java中，Protobuf的功耗表现都比JSON好。在Java中，Protobuf并且要比JSON快了接近80%。如果Java的服务之间通讯有了功耗难题， 可以考虑服务之间使用RPC来通讯。
但是遇事都具备两面性。Protobuf的劣势依然存在：
4 总结
以上就是这两个月以来，总结的三者的差别。只是从大体上做了一个对比，并没有详细深入细节。细节的话有可能会在之后单独的来介绍。
往期文章：
相关：
