Web服務器與游戲服務器的區別：

1、狀態

首先要提到的就是狀態。可能你會聽說過一個概念，游戲服務器是有狀態的，而Web服務器是無狀態的。什么意思呢？Web服務器的數據流大多直接會到數據庫中。而游戲服務器的數據流首先會到內存中，然后定期的寫入數據庫（落地）。

換句話說，游戲服務器本身的數據與數據庫中的數據在運行期間會存在一個數據不一致的窗口。如果此時游戲服務器宕機了，那么就會造成數據首先到的內存數據與數據庫存的數據不一致。

而Web服務器則不會有這樣的問題，Web所有的數據狀態都會落地，而且可以針對操作加上事務，不用擔心因為操作失敗而引入臟數據。正因為有了狀態的約束，游戲服務器就會很慎重的使用內存、CPU。以求在資源有限的情況下，最大化的提高的承載量，并且降低服務延遲。當然，Web服務器會為了降低某個接口的響應時間而去做對應的優化。

2、擴容

在Web服務器中，如果你不能評估一個服務所面臨的壓力，又不想因為瞬時的熱點訪問導致服務直接不可用的話，完全可以設置成自動擴容，因為每個服務只是單純的接收請求，然后處理請求、返回結果，不會將數據保存在服務器的內存中。要有數據存到內存，那也是在Redis中。而Redis數據丟失對數據的一致性基本沒有影響。

但是在游戲服務器這邊很難做到像Web那樣靈活。首先，數據的流向不是數據庫，而是內存。

舉個很簡單的例子，玩家的主城被攻打著火了，如果有了自動擴容，很有可能在落地的窗口內，玩家再請求一次，請求到了另一個實例。主城又沒有著火了。因為數據都會先存在內存中。

再舉一個例子，玩家氪金買了一個禮包。然后退出游戲，落地窗口內再次上線沒了。這就不是單純的數據問題了，玩家這是花了真金白銀買的道具，突然就沒了，一兩個還好處理，如果多個玩家都出現這樣的問題，那這就屬于嚴重的線上事故了。修復數據的工作量十分的大。

所以，對于一個游戲服務器，所能使用的內存和CPU的資源是非常有限的，不像Web服務器可以不用花很大的代價做到橫向擴展。這也就是為什么游戲服務器會十分十分的注重代碼的性能以及穩定性。

3、穩定

就像上面說的例子，如果游戲服務器運行中出了BUG，導致服務直接不可用，或者說通過這個BUG刷到了大量的道具，將是一個非常嚴重的線上事故。

而對于Web服務器來說，如果是管理系統之類的，有可能會有臟數據值得一提的是，臟數據對于Web來說，排查起來也是一件很頭疼的事情。如果沒有臟數據，只是服務暫且不可用，而且如果用的是微服務架構，重啟服務的代價是相對來說比較小的，只有正在重啟的服務的業務是不可用的，其余的部分則可以正常的訪問。

而對于游戲服務器來說，服務器重啟影響的是全服的玩家。玩家在停服期間，甚至連游戲都進不了，特別的影響玩家體驗。而且，如果停服之前服務器的數據落地出現了問題，服務重啟之后會將數據從數據庫load到內存中，此時同樣會造成數據不一致的問題。

4、性能

從我的經驗來看，在做Web服務器的時候，沒有為了減少GC的壓力，為了少占用內存去做過多的優化。當然這是因為項目本身的體量不大，如果QPS很高的話，Web服務器同樣很需要注重性能，只不過游戲服務器需要一直特別注意這個方面。

不過在Web，如果訪問量很大的話導致單個服務不能扛住壓力，大部分人首先想到的解決方案應該就是搞多個實例，畢竟可以做到很輕松的橫向擴展。

在游戲服務器里，會把服務器的資源看的相當的寶貴。例如，能不落地的字段就絕對不要落地，某個字段的值可以通過已知的條件算出來的，就盡量不要定義在代碼里。不過這也要看具體情況權衡運算量和調用的頻率。因為上線之后，如果遇到了數據不一致，維護的數據越少，修復數據的難度就越小。

5、嚴謹

這一點上來說，我認為是兩者都很關注的一個重點。只不過，在游戲服務器的某些情況中，如果服務器拋出異常或者panic。其造成的后果會被游戲特殊的環境放大。

例如，召回你的在外部隊失敗了，那么部隊就會一直在外面且不可用。這跟在瀏覽器中點一個按鈕沒有反應比起來，影響相對較小。而且使用微服務架構，在修復問題之后可以以很低的成本來重啟對應的服務，而游戲服務器中還要修復一次數據。

再舉一個很極端的例子，點擊商店，玩家要準備氪金了。但是卻發現進不了商店，也可能不能獲取商品列表。這些會直接影響到游戲的體驗，甚至收入。

而對于Web來說，服務器的穩定性同樣很重要。不然根據業務的不同，造成后果的嚴重性也有可能不同。影響了用戶體驗，就會直接影響到產品的口碑。

6、數據傳輸格式

熟悉Web的都知道，數據傳輸格式是JSON。而在游戲服務器中是Protobuf，是由Google開發的數據傳輸格式，與JSON類似。Protobuf是二進制的，二進制數據量會比JSON更小一點。而且，如果傳輸的字段是空值，就不會被傳輸。而JSON如果是空值，一樣的也會被傳輸。

無論是在什么樣的環境中，舉個例子，Node.js和Java中，Protobuf的性能表現都比JSON好。在Java中，Protobuf甚至要比JSON快了接近80%。如果Java的服務之間通信有了性能瓶頸， 可以考慮服務之間使用RPC來通信。

但是凡事都具有兩面性。Protobuf的缺點仍然存在：

文檔較少 社區與JSON的對比起來 可讀性沒有JSON好

以上就是這兩個月以來，總結的兩者的區別。只是從大體上做了一個對比，并沒有具體深入細節。細節的話有可能會在以后單獨的來介紹。

關于我們：

Infocode藍暢信息技術有限公司成功為多家世界財富500強企業以及其他著名品牌提供優質服務，是您靠譜的互聯網開發供應商。

服務客戶遍及北京、上海、杭州、深圳、廣州、天津、青島、南京、寧波、蘇州、無錫、廈門、重慶、西安等大中型城市及地區    為您提供：H5開發，小程序開發，H5外包，微信開發，H5商城開發，小程序商城開發，網站開發外包，H5游戲開發，小程序開發外包，小程序設計、APP開發外包，UI設計，SEO優化，SEO外包，視頻后期制作等優質服務