有些對游戲服務(wù)器的介紹可能會說，游戲服務(wù)器是一個需要長期運(yùn)行的程序，然后怎么怎么樣。我個人認(rèn)為Web服務(wù)器一樣的需要長期運(yùn)行，也需要響應(yīng)不定點不定時來自用戶的請求。兩者從宏觀上來看其實沒有本質(zhì)的區(qū)別。同時Web服務(wù)器也會對于穩(wěn)定性和性能有要求，游戲服一般分為大小服，我們這里都按照小服舉例子。
狀態(tài)
首先要提到的就是狀態(tài)。可能你會聽說過一個概念，游戲服務(wù)器是有狀態(tài)的，而Web服務(wù)器是無狀態(tài)的。什么意思呢?Web服務(wù)器的數(shù)據(jù)流大多直接會到數(shù)據(jù)庫中。而游戲服務(wù)器的數(shù)據(jù)流首先會到內(nèi)存中，然后定期的寫入數(shù)據(jù)庫(落地)。
換句話說，游戲服務(wù)器本身的數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)在運(yùn)行期間會存在一個數(shù)據(jù)不一致的窗口。成都機(jī)柜租用如果此時游戲服務(wù)器宕機(jī)了，那么就會造成數(shù)據(jù)首先到的內(nèi)存數(shù)據(jù)與數(shù)據(jù)庫存的數(shù)據(jù)不一致。
而Web服務(wù)器則不會有這樣的問題，Web所有的數(shù)據(jù)狀態(tài)都會落地，而且可以針對操作加上事務(wù)，不用擔(dān)心因為操作失敗而引入臟數(shù)據(jù)。正因為有了狀態(tài)的約束，游戲服務(wù)器就會很慎重的使用內(nèi)存、CPU。以求在資源有限的情況下，大化的提高的承載量，并且降低服務(wù)延遲。當(dāng)然，Web服務(wù)器會為了降低某個接口的響應(yīng)時間而去做對應(yīng)的優(yōu)化。
擴(kuò)容
在Web服務(wù)器中，如果你不能評估一個服務(wù)所面臨的壓力，又不想因為瞬時的熱點訪問導(dǎo)致服務(wù)直接不可用的話，完全可以設(shè)置成自動擴(kuò)容，因為每個服務(wù)只是單純的接收請求，然后處理請求、返回結(jié)果，不會將數(shù)據(jù)保存在服務(wù)器的內(nèi)存中。要有數(shù)據(jù)存到內(nèi)存，那也是在Redis中。而Redis數(shù)據(jù)丟失對數(shù)據(jù)的一致性基本沒有影響。
但是在游戲服務(wù)器這邊很難做到像Web那樣靈活。首先，數(shù)據(jù)的流向不是數(shù)據(jù)庫，而是內(nèi)存。
舉個很簡單的例子，玩家的主城被攻打著火了，如果有了自動擴(kuò)容，很有可能在落地的窗口內(nèi)，玩家再請求一次，請求到了另一個實例。主城又沒有著火了。因為數(shù)據(jù)都會先存在內(nèi)存中。
再舉一個例子，玩家氪金買了一個禮包。然后退出游戲，落地窗口內(nèi)再次上線沒了。這就不是單純的數(shù)據(jù)問題了，玩家這是花了真金白銀買的道具，突然就沒了，一兩個還好處理，如果多個玩家都出現(xiàn)這樣的問題，那這就屬于嚴(yán)重的線上事故了。修復(fù)數(shù)據(jù)的工作量十分的大。
所以，對于一個游戲服務(wù)器，所能使用的內(nèi)存和CPU的資源是非常有限的，不像Web服務(wù)器可以不用花很大的代價做到橫向擴(kuò)展。這也就是為什么游戲服務(wù)器會十分十分的注重代碼的性能以及穩(wěn)定性。
穩(wěn)定
就像上面說的例子，如果游戲服務(wù)器運(yùn)行中出了BUG，導(dǎo)致服務(wù)直接不可用，或者說通過這個BUG刷到了大量的道具，將是一個非常嚴(yán)重的線上事故。
而對于Web服務(wù)器來說，如果是管理系統(tǒng)之類的，有可能會有臟數(shù)據(jù)值得一提的是，臟數(shù)據(jù)對于Web來說，排查起來也是一件很頭疼的事情。如果沒有臟數(shù)據(jù)，只是服務(wù)暫且不可用，而且如果用的是微服務(wù)架構(gòu)，重啟服務(wù)的代價是相對來說比較小的，只有正在重啟的服務(wù)的業(yè)務(wù)是不可用的，其余的部分則可以正常的訪問。
重慶分公司
重慶分公司
