-
互聯網安全法,互聯網凈網行動
-
”凈網2020”落實好維護網絡安全責任
-
關于端午節放假通知-宇眾網絡
-
宇眾網絡春節放假通知
-
關于公司收款銀行賬戶變更通知函-宇眾網絡
-
關于網上有人冒充我公司名義進行詐騙的公告。
-
關于端午節放假通知,節日放假,但是我們業務不“放假”-宇眾網絡
-
工信部進一步加強未備案網站管理工作的通知-宇眾網絡
-
關于東莞市宇眾網絡科技有限公司香港數據中心(香港機房)路由優化通知
-
宇眾網絡慶祝五·一勞動節快樂
-
東莞東城機房網絡升級通知
-
臨近過年,互聯網IDC貴圈也有被騙的,請認準宇眾網絡公司官方聯系方式
-
我司已獲得ISP/ICP/IDC三證資格,更好的為客戶服務
-
關于浙江金華高防機房網絡線路切割通知
-
工信部近日下發關于進一步規范域名備案工作的通知
行業資訊
- 首頁
- 新聞中心
- 行業資訊
游戲服務器和一般服務器有何區別?宇眾網絡高防服務器租用,183.60.201.1佛山德勝游戲專用服務器!!!
在中國的互聯網諸多業務領域中,游戲一直是充當“現金牛”而存在的。但是,在游戲服務器端開發領域中的很多重要問題,并沒有被明確的分辨出其特異性,從而得到專門的對待。我們不管是在業界開源領域,還是內部分享中,很少會有專門針對游戲業務特征進行專門設計的組件、類庫或者框架。我們從游戲的客戶端方面來看,一款專業的游戲客戶端引擎,已經是游戲開發的標配,比如最早的Flash Builder,到后期的Cocos2d-X,Unity,Unreal;但是服務器端,我們幾乎找不到同樣重量級的產品。
游戲服務器和一般服務器的區別
在游戲服務器端開發所有要面對的問題中,有兩個是最核心和最普遍的:一是和客戶端的通訊;二是游戲登錄用戶的數據處理。對于和客戶端通訊的這個問題,大量的游戲開發者會使用“通用”的開源組件,比如Protocol Buffer,Thrift,Jetty,Node.js等等通信或RPC框架。雖然針對游戲,還是要做大量的改造,但一般都有很多現成的代碼可供修改。
在一般的互聯網應用中,我們一般認為服務都是通過請求-響應的方式來完成的。而在游戲業務領域中,請求-響應可以看成是一種類型的通訊方式,但還有另外一種重要的通訊模型,就是“數據同步”方式:游戲中某個角色的HP、位置坐標改變了,需要在客戶端和服務器之間、客戶端和客戶端之間同步。這造成了一般情況下通信協議的大量增加。
對于第二個問題,不管是memcache還是MySQL,或者是Redis,都不能完全滿足游戲開發者的需求。很多團隊嘗試過各種組合和修改,試圖創造出利用現有開源軟件,建設既能迎合靈活的需求變化,又具備低延遲和高可用的數據處理系統,但最后這些努力基本上都很難圓滿成功。因此我們在游戲服務器端代碼中,還是充斥著大量的內存、緩存管理,數據同步、落地等等代碼。而且每個游戲都要重新去寫一遍這些類似的功能,不能不說一種浪費。
如果我們要想出一種能滿足“游戲”這個業務領域的數據系統設計,那么就一定要搞清楚為什么在如此之多的開源項目和游戲團隊中,沒能實現完美契合的原因。
電子商務/一般互聯網業務的C-S通訊流程
基于WebService類型的通訊模型,現在基本已經成為互聯網開源組件的標準。由此而誕生的RESTful API,或者各種RPC模型,其實都是基于這樣的客觀事實:
-
用戶主動請求,服務器產生回應。典型的就是網頁的點擊、表單的提交。
-
主動通知的消息,僅僅是提示用戶發起查詢請求。比如在APP按鈕上的小紅點,消息頁的數字提示等等,這些主動通知都是為了通知用戶去刷新頁面。
游戲類業務的通信流程
游戲中的通信,一般和操作有關。這些操作一般分為兩類:
-
UI面板類操作
-
戰斗場景操作
這兩者的最大區別,就是UI面板類操作一般無需讓其他玩家看見。而戰斗場景操作則需要廣播給所有玩家看到。
在第二種情況下,一般就不是客戶端主動發起,而是服務器端直接推送實際數據,然后客戶端直接顯示這些數據。這個模式和簡單的“推送”還不一樣,而應該更進一步,是一種從服務器端發起的,向客戶端“同步”數據的請求。
因此,一個好的游戲服務器端框架,應該是能同時支持請求-響應模型和“推送同步”模型的。
電子商務/一般互聯網類業務的數據處理流程
Memcache、Redis、MySQL在一般互聯網業務中的應用非常廣泛。而且基本上能很好的應對各種常見的應用場景,包括類似BBS的社區、新聞門戶、電子商務類系統。在企業內部信息系統中(Intranet),這一類數據軟件也能發揮非常好的功效。由于電子商務類是其中最復雜的系統,所以我在這里以此為例說明,一般數據處理的流程是如何的。
假設我們瀏覽了一個網店,選中了一個商品,點擊了下單這個流程,實際上需要的后臺流程可能是下圖所示:
從上面的分析大概可以總結出幾個特點:
一、忍受延遲:每個操作的延遲要求較低,操作頻率不會太高。一般我們頁面在5秒內打開,都不會引起太多客戶的抗議。所以,就算我們處理一個請求的時候,后臺進行多次的進程間調用,產生的延遲和帶寬消耗也是可以忍受的。
二、在線交互少:互聯網業務大多數是基于瀏覽器的,所以在線用戶之間很少實時交互。
三、數據分散:一般來說,互聯網應用的數據可以在多個不同的業務系統中共用,但是需要專門的業務模塊來做管理,以維持數據的一致性。
四、數據變更面廣:系統需要持續處理很多數據變更,互聯網業務有很大一部分數據是來源于普通用戶、網絡編輯、店主等等使用者,在使用的過程中,他們會大量的修改系統所存儲的數據。
以上四個特點,導致了我們一般會把后臺要處理的數據,分別用Cache系統和DB系統來處理。并且,我們一般會按業務功能劃分模塊,同時也劃分業務系統。由于延遲和在線交互的需求較弱,所以使用大量進程來做模塊隔離,依然是非常可行的,總體來說,就是一種比較“分散”的數據使用方式。
★若服務器租用可咨詢宇眾臨風,QQ:2850293179 Tel:15999932452 訂購網址:www.jindaxi.cn
游戲類業務的數據處理流程
在各種游戲中,MMORPG是數據處理最為復雜的一類,也是最典型的一種“重服務器端”的游戲類型,因此可以作為游戲業務中通用性的參考標準。在MMORPG中,我們可以發現,數據的處理需求,和一般互聯網業務大相徑庭,它體現出的是一種明顯的“集中”式的數據處理需求。我們可以從一般MMORPG的服務器架構中體現出來:
在游戲業務中,一般我們都會發現以下的特點:
一、延遲敏感:游戲中用戶會產生大量操作,都要求“實時”進行反饋,所以一般都不能忍受1秒以上的延遲,在大量動作類型的游戲中,一般都會要求服務器的反饋時延在50ms左右。因此游戲開發者都習慣于盡量減少后臺進程間的交互,盡管這對提高系統吞吐量很不利。所以大部分游戲服務器端都有一個所謂“GameServer”,里面運行了游戲70%以上的功能。
二、大量實時交互:在線游戲的特點,就是很多玩家可以通過服務器“看見”彼此,能實時的互動。因此我們必須要把用戶的在線數據,集中到一起,才能提供互相操作的可能;而且A用戶操作B用戶的數據,是最常見的數據操作,所謂戰斗玩法,就是互相修改對方的數據的過程。
三、數據集中:游戲是一個幾乎完全虛擬的世界,在游戲中的數據,實際上很少能在其他系統中產生價值。而游戲邏輯也禁止通過游戲以外的方式,修改游戲的數據。所以游戲中的數據,一般都會集中存放在單獨的數據庫中。由于沒有數據共用的需求,所以也不需要把GameServer里面集中的邏輯劃分出很多單獨的進程模塊來。
四、數據變更少:實際上游戲的數據變更還是很快的,比如游戲中的每次中彈,都要減少HP的數值。但是游戲里的數據,一般都遵守這樣一個規則:“變化越快的數據,重要性越低”。也就是說,游戲中是可以容忍一定程度的數據不一致和不完整的。而游戲中的數據,一般會分成兩類:玩家存檔和游戲設置。對于玩家存檔來說,其單條數據量一般不大,但會有大量的記錄數,因為每個玩家都會有一個存檔。但是其讀取、修改,一般很典型的和玩家的登錄、登出、升級等業務邏輯密切關聯,所以其緩存時機是比較容易根據業務邏輯來把握的。而對于游戲設置數據來說,幾乎只有升級游戲版本的時候才會修改,大部分運行時是只讀的,其緩存簡單的讀入內存就解決問題了。
一般的緩存系統的特點在游戲中的問題
根據以上的分析,我們可以看到,普通的緩存系統,如memcache和Redis,實際上其特點是不太適合游戲業務的:
-
一般跨進程的緩存系統,無法解決游戲要求的低延遲問題。級別是同機房,每次數據存取都需要10-20ms的時間,對于游戲戰斗中大量的數據讀、寫來說,是很難接受的。(但是一些回合制戰斗、低頻操作還是有用的)
-
通用型的緩存系統或者數據庫,一般都比較難集結多個進程,形成一個完整的數據存儲網格。這讓玩家間的互相交互產生了額外的難度,開發者必須先想辦法確定玩家的數據在哪個后臺進程上,然后才能去讀寫。一般的數據庫或緩存系統,為了保證數據的一致性或者完整性,往往會需要犧牲一些分布式的能力。而這種犧牲在游戲業務中,其實是一種浪費,因為游戲的很多數據都無需這種能力。
-
通用性數據系統一般不依賴于特定的語言,所以很少能直接把某種“對象”存入到數據系統中。在游戲開發中,需要存儲的數據結構數量往往是非常大量的:一個普通的游戲,基本上都會超過100種數據結構。對于每個數據結構,都去建表或者編寫序列化/反序列化配置,是一種非常累人的工作。–明明在代碼中,已經用編程語言定義了他們的結構,還要重復的搞一次。
根據上面說的這些問題,我們實際上是需要另外一種完全不同設計思想的數據系統。
對于游戲業務來說,一個好用的數據系統,應該包括這樣一些特點:
-
可以利用GameServer進程內的內存進行自動化的緩存管理。由于GameServer進程往往集中了大部分的邏輯運算,所以大部分的數據緩存也應該在這個進程中,這樣才能符合游戲所需的延遲要求。
-
自動進行數據落地和容災管理。由于游戲數據中有大量的“過程數據”,所以其一致性和完整性要求會稍微低于其他業務,所以應該利用這一點,讓GameServer本身也可以是分布式的程序,從而提高系統整體的吞吐量。
-
具備良好的編程易用性。最好是能直接存取編程中的對象,避免反復對數據結構的描述,節省大量的開發時間。
總結
游戲服務器和普通互聯網業務服務器端,最大的區別實際上就在于“狀態”。游戲服務器的狀態是實時快速變化的、可以容忍丟失的、需要大量廣播同步的;普通互聯網業務服務器的狀態一般是持久化的、不容忍丟失的、只和特定客戶端相關的。所以一個好的游戲服務器框架,在通訊和數據這兩個基本層面,會和一般我們所接觸的開源組件有很大的差異。這也是作為游戲服務器端開發者,需要去共同建設行業標準的地方。