很多公司在對有些對游戲服務器的介紹可能會說，游戲服務器是一個需要長期運行的程序，然后怎么怎么樣。我個人認為Web服務器一樣的需要長期運行，也需要響應不定點不定時來自用戶的請求。兩者從宏觀上來看其實沒有本質的區(qū)別。同時Web服務器也會對于穩(wěn)定性和性能有要求，游戲服一般分為大小服，我們這里都按照小服舉例子。

　　一、服務器性能狀態(tài)

　　首先要提到的就是狀態(tài)?？赡苣銜犝f過一個概念，游戲服務器是有狀態(tài)的，而Web服務器是無狀態(tài)的。什么意思呢?Web服務器的數(shù)據(jù)流大多直接會到數(shù)據(jù)庫中。而游戲服務器的數(shù)據(jù)流首先會到內存中，然后定期的寫入數(shù)據(jù)庫(落地)。

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

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

　　二、服務器擴容性

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

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

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

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

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

　　三、服務器穩(wěn)定性

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

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