游戲服務(wù)器和一般服務(wù)器有何區(qū)別？宇眾網(wǎng)絡(luò)高防服務(wù)器租用，183.60.201.1佛山德勝游戲?qū)Ｓ梅?wù)器！！！

      在中國(guó)的互聯(lián)網(wǎng)諸多業(yè)務(wù)領(lǐng)域中，游戲一直是充當(dāng)“現(xiàn)金牛”而存在的。但是，在游戲服務(wù)器端開(kāi)發(fā)領(lǐng)域中的很多重要問(wèn)題，并沒(méi)有被明確的分辨出其特異性，從而得到專門的對(duì)待。我們不管是在業(yè)界開(kāi)源領(lǐng)域，還是內(nèi)部分享中，很少會(huì)有專門針對(duì)游戲業(yè)務(wù)特征進(jìn)行專門設(shè)計(jì)的組件、類庫(kù)或者框架。我們從游戲的客戶端方面來(lái)看，一款專業(yè)的游戲客戶端引擎，已經(jīng)是游戲開(kāi)發(fā)的標(biāo)配，比如最早的Flash Builder，到后期的Cocos2d-X，Unity，Unreal；但是服務(wù)器端，我們幾乎找不到同樣重量級(jí)的產(chǎn)品。

游戲服務(wù)器和一般服務(wù)器的區(qū)別

　　在游戲服務(wù)器端開(kāi)發(fā)所有要面對(duì)的問(wèn)題中，有兩個(gè)是最核心和最普遍的：一是和客戶端的通訊；二是游戲登錄用戶的數(shù)據(jù)處理。對(duì)于和客戶端通訊的這個(gè)問(wèn)題，大量的游戲開(kāi)發(fā)者會(huì)使用“通用”的開(kāi)源組件，比如Protocol Buffer，Thrift，Jetty，Node.js等等通信或RPC框架。雖然針對(duì)游戲，還是要做大量的改造，但一般都有很多現(xiàn)成的代碼可供修改。

　　在一般的互聯(lián)網(wǎng)應(yīng)用中，我們一般認(rèn)為服務(wù)都是通過(guò)請(qǐng)求-響應(yīng)的方式來(lái)完成的。而在游戲業(yè)務(wù)領(lǐng)域中，請(qǐng)求-響應(yīng)可以看成是一種類型的通訊方式，但還有另外一種重要的通訊模型，就是“數(shù)據(jù)同步”方式：游戲中某個(gè)角色的HP、位置坐標(biāo)改變了，需要在客戶端和服務(wù)器之間、客戶端和客戶端之間同步。這造成了一般情況下通信協(xié)議的大量增加。

　　對(duì)于第二個(gè)問(wèn)題，不管是memcache還是MySQL，或者是Redis，都不能完全滿足游戲開(kāi)發(fā)者的需求。很多團(tuán)隊(duì)嘗試過(guò)各種組合和修改，試圖創(chuàng)造出利用現(xiàn)有開(kāi)源軟件，建設(shè)既能迎合靈活的需求變化，又具備低延遲和高可用的數(shù)據(jù)處理系統(tǒng)，但最后這些努力基本上都很難圓滿成功。因此我們?cè)谟螒蚍?wù)器端代碼中，還是充斥著大量的內(nèi)存、緩存管理，數(shù)據(jù)同步、落地等等代碼。而且每個(gè)游戲都要重新去寫一遍這些類似的功能，不能不說(shuō)一種浪費(fèi)。

　　如果我們要想出一種能滿足“游戲”這個(gè)業(yè)務(wù)領(lǐng)域的數(shù)據(jù)系統(tǒng)設(shè)計(jì)，那么就一定要搞清楚為什么在如此之多的開(kāi)源項(xiàng)目和游戲團(tuán)隊(duì)中，沒(méi)能實(shí)現(xiàn)完美契合的原因。

電子商務(wù)/一般互聯(lián)網(wǎng)業(yè)務(wù)的C-S通訊流程

　　基于WebService類型的通訊模型，現(xiàn)在基本已經(jīng)成為互聯(lián)網(wǎng)開(kāi)源組件的標(biāo)準(zhǔn)。由此而誕生的RESTful API，或者各種RPC模型，其實(shí)都是基于這樣的客觀事實(shí)： 
 

• 用戶主動(dòng)請(qǐng)求，服務(wù)器產(chǎn)生回應(yīng)。典型的就是網(wǎng)頁(yè)的點(diǎn)擊、表單的提交。

• 主動(dòng)通知的消息，僅僅是提示用戶發(fā)起查詢請(qǐng)求。比如在APP按鈕上的小紅點(diǎn)，消息頁(yè)的數(shù)字提示等等，這些主動(dòng)通知都是為了通知用戶去刷新頁(yè)面。

游戲類業(yè)務(wù)的通信流程

　　游戲中的通信，一般和操作有關(guān)。這些操作一般分為兩類：

• UI面板類操作

• 戰(zhàn)斗場(chǎng)景操作

  　　這兩者的最大區(qū)別，就是UI面板類操作一般無(wú)需讓其他玩家看見(jiàn)。而戰(zhàn)斗場(chǎng)景操作則需要廣播給所有玩家看到。

　　在第二種情況下，一般就不是客戶端主動(dòng)發(fā)起，而是服務(wù)器端直接推送實(shí)際數(shù)據(jù)，然后客戶端直接顯示這些數(shù)據(jù)。這個(gè)模式和簡(jiǎn)單的“推送”還不一樣，而應(yīng)該更進(jìn)一步，是一種從服務(wù)器端發(fā)起的，向客戶端“同步”數(shù)據(jù)的請(qǐng)求。

　　因此，一個(gè)好的游戲服務(wù)器端框架，應(yīng)該是能同時(shí)支持請(qǐng)求-響應(yīng)模型和“推送同步”模型的。

電子商務(wù)/一般互聯(lián)網(wǎng)類業(yè)務(wù)的數(shù)據(jù)處理流程

　　Memcache、Redis、MySQL在一般互聯(lián)網(wǎng)業(yè)務(wù)中的應(yīng)用非常廣泛。而且基本上能很好的應(yīng)對(duì)各種常見(jiàn)的應(yīng)用場(chǎng)景，包括類似BBS的社區(qū)、新聞門戶、電子商務(wù)類系統(tǒng)。在企業(yè)內(nèi)部信息系統(tǒng)中（Intranet），這一類數(shù)據(jù)軟件也能發(fā)揮非常好的功效。由于電子商務(wù)類是其中最復(fù)雜的系統(tǒng)，所以我在這里以此為例說(shuō)明，一般數(shù)據(jù)處理的流程是如何的。

假設(shè)我們?yōu)g覽了一個(gè)網(wǎng)店，選中了一個(gè)商品，點(diǎn)擊了下單這個(gè)流程，實(shí)際上需要的后臺(tái)流程可能是下圖所示：

　　從上面的分析大概可以總結(jié)出幾個(gè)特點(diǎn)：

　　一、忍受延遲：每個(gè)操作的延遲要求較低，操作頻率不會(huì)太高。一般我們頁(yè)面在5秒內(nèi)打開(kāi)，都不會(huì)引起太多客戶的抗議。所以，就算我們處理一個(gè)請(qǐng)求的時(shí)候，后臺(tái)進(jìn)行多次的進(jìn)程間調(diào)用，產(chǎn)生的延遲和帶寬消耗也是可以忍受的。

　　二、在線交互少：互聯(lián)網(wǎng)業(yè)務(wù)大多數(shù)是基于瀏覽器的，所以在線用戶之間很少實(shí)時(shí)交互。

　　三、數(shù)據(jù)分散：一般來(lái)說(shuō)，互聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)可以在多個(gè)不同的業(yè)務(wù)系統(tǒng)中共用，但是需要專門的業(yè)務(wù)模塊來(lái)做管理，以維持?jǐn)?shù)據(jù)的一致性。

　　四、數(shù)據(jù)變更面廣：系統(tǒng)需要持續(xù)處理很多數(shù)據(jù)變更，互聯(lián)網(wǎng)業(yè)務(wù)有很大一部分?jǐn)?shù)據(jù)是來(lái)源于普通用戶、網(wǎng)絡(luò)編輯、店主等等使用者，在使用的過(guò)程中，他們會(huì)大量的修改系統(tǒng)所存儲(chǔ)的數(shù)據(jù)。

　　以上四個(gè)特點(diǎn)，導(dǎo)致了我們一般會(huì)把后臺(tái)要處理的數(shù)據(jù)，分別用Cache系統(tǒng)和DB系統(tǒng)來(lái)處理。并且，我們一般會(huì)按業(yè)務(wù)功能劃分模塊，同時(shí)也劃分業(yè)務(wù)系統(tǒng)。由于延遲和在線交互的需求較弱，所以使用大量進(jìn)程來(lái)做模塊隔離，依然是非常可行的，總體來(lái)說(shuō)，就是一種比較“分散”的數(shù)據(jù)使用方式。

★若服務(wù)器租用可咨詢宇眾臨風(fēng)，QQ：2850293179    Tel：15999932452    訂購(gòu)網(wǎng)址：www.jindaxi.cn

游戲類業(yè)務(wù)的數(shù)據(jù)處理流程

　　在各種游戲中，MMORPG是數(shù)據(jù)處理最為復(fù)雜的一類，也是最典型的一種“重服務(wù)器端”的游戲類型，因此可以作為游戲業(yè)務(wù)中通用性的參考標(biāo)準(zhǔn)。在MMORPG中，我們可以發(fā)現(xiàn)，數(shù)據(jù)的處理需求，和一般互聯(lián)網(wǎng)業(yè)務(wù)大相徑庭，它體現(xiàn)出的是一種明顯的“集中”式的數(shù)據(jù)處理需求。我們可以從一般MMORPG的服務(wù)器架構(gòu)中體現(xiàn)出來(lái)：

　　在游戲業(yè)務(wù)中，一般我們都會(huì)發(fā)現(xiàn)以下的特點(diǎn)：

　　一、延遲敏感：游戲中用戶會(huì)產(chǎn)生大量操作，都要求“實(shí)時(shí)”進(jìn)行反饋，所以一般都不能忍受1秒以上的延遲，在大量動(dòng)作類型的游戲中，一般都會(huì)要求服務(wù)器的反饋時(shí)延在50ms左右。因此游戲開(kāi)發(fā)者都習(xí)慣于盡量減少后臺(tái)進(jìn)程間的交互，盡管這對(duì)提高系統(tǒng)吞吐量很不利。所以大部分游戲服務(wù)器端都有一個(gè)所謂“GameServer”，里面運(yùn)行了游戲70%以上的功能。

　　二、大量實(shí)時(shí)交互：在線游戲的特點(diǎn)，就是很多玩家可以通過(guò)服務(wù)器“看見(jiàn)”彼此，能實(shí)時(shí)的互動(dòng)。因此我們必須要把用戶的在線數(shù)據(jù)，集中到一起，才能提供互相操作的可能；而且A用戶操作B用戶的數(shù)據(jù)，是最常見(jiàn)的數(shù)據(jù)操作，所謂戰(zhàn)斗玩法，就是互相修改對(duì)方的數(shù)據(jù)的過(guò)程。

　　三、數(shù)據(jù)集中：游戲是一個(gè)幾乎完全虛擬的世界，在游戲中的數(shù)據(jù)，實(shí)際上很少能在其他系統(tǒng)中產(chǎn)生價(jià)值。而游戲邏輯也禁止通過(guò)游戲以外的方式，修改游戲的數(shù)據(jù)。所以游戲中的數(shù)據(jù)，一般都會(huì)集中存放在單獨(dú)的數(shù)據(jù)庫(kù)中。由于沒(méi)有數(shù)據(jù)共用的需求，所以也不需要把GameServer里面集中的邏輯劃分出很多單獨(dú)的進(jìn)程模塊來(lái)。

　　四、數(shù)據(jù)變更少：實(shí)際上游戲的數(shù)據(jù)變更還是很快的，比如游戲中的每次中彈，都要減少HP的數(shù)值。但是游戲里的數(shù)據(jù)，一般都遵守這樣一個(gè)規(guī)則：“變化越快的數(shù)據(jù)，重要性越低”。也就是說(shuō)，游戲中是可以容忍一定程度的數(shù)據(jù)不一致和不完整的。而游戲中的數(shù)據(jù)，一般會(huì)分成兩類：玩家存檔和游戲設(shè)置。對(duì)于玩家存檔來(lái)說(shuō)，其單條數(shù)據(jù)量一般不大，但會(huì)有大量的記錄數(shù)，因?yàn)槊總€(gè)玩家都會(huì)有一個(gè)存檔。但是其讀取、修改，一般很典型的和玩家的登錄、登出、升級(jí)等業(yè)務(wù)邏輯密切關(guān)聯(lián)，所以其緩存時(shí)機(jī)是比較容易根據(jù)業(yè)務(wù)邏輯來(lái)把握的。而對(duì)于游戲設(shè)置數(shù)據(jù)來(lái)說(shuō)，幾乎只有升級(jí)游戲版本的時(shí)候才會(huì)修改，大部分運(yùn)行時(shí)是只讀的，其緩存簡(jiǎn)單的讀入內(nèi)存就解決問(wèn)題了。

　　一般的緩存系統(tǒng)的特點(diǎn)在游戲中的問(wèn)題

　　根據(jù)以上的分析，我們可以看到，普通的緩存系統(tǒng)，如memcache和Redis，實(shí)際上其特點(diǎn)是不太適合游戲業(yè)務(wù)的：

• 一般跨進(jìn)程的緩存系統(tǒng)，無(wú)法解決游戲要求的低延遲問(wèn)題。級(jí)別是同機(jī)房，每次數(shù)據(jù)存取都需要10-20ms的時(shí)間，對(duì)于游戲戰(zhàn)斗中大量的數(shù)據(jù)讀、寫來(lái)說(shuō)，是很難接受的。（但是一些回合制戰(zhàn)斗、低頻操作還是有用的）

• 通用型的緩存系統(tǒng)或者數(shù)據(jù)庫(kù)，一般都比較難集結(jié)多個(gè)進(jìn)程，形成一個(gè)完整的數(shù)據(jù)存儲(chǔ)網(wǎng)格。這讓玩家間的互相交互產(chǎn)生了額外的難度，開(kāi)發(fā)者必須先想辦法確定玩家的數(shù)據(jù)在哪個(gè)后臺(tái)進(jìn)程上，然后才能去讀寫。一般的數(shù)據(jù)庫(kù)或緩存系統(tǒng)，為了保證數(shù)據(jù)的一致性或者完整性，往往會(huì)需要犧牲一些分布式的能力。而這種犧牲在游戲業(yè)務(wù)中，其實(shí)是一種浪費(fèi)，因?yàn)橛螒虻暮芏鄶?shù)據(jù)都無(wú)需這種能力。

• 通用性數(shù)據(jù)系統(tǒng)一般不依賴于特定的語(yǔ)言，所以很少能直接把某種“對(duì)象”存入到數(shù)據(jù)系統(tǒng)中。在游戲開(kāi)發(fā)中，需要存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)數(shù)量往往是非常大量的：一個(gè)普通的游戲，基本上都會(huì)超過(guò)100種數(shù)據(jù)結(jié)構(gòu)。對(duì)于每個(gè)數(shù)據(jù)結(jié)構(gòu)，都去建表或者編寫序列化/反序列化配置，是一種非常累人的工作。–明明在代碼中，已經(jīng)用編程語(yǔ)言定義了他們的結(jié)構(gòu)，還要重復(fù)的搞一次。

  　　根據(jù)上面說(shuō)的這些問(wèn)題，我們實(shí)際上是需要另外一種完全不同設(shè)計(jì)思想的數(shù)據(jù)系統(tǒng)。

  　　對(duì)于游戲業(yè)務(wù)來(lái)說(shuō)，一個(gè)好用的數(shù)據(jù)系統(tǒng)，應(yīng)該包括這樣一些特點(diǎn)：

• 可以利用GameServer進(jìn)程內(nèi)的內(nèi)存進(jìn)行自動(dòng)化的緩存管理。由于GameServer進(jìn)程往往集中了大部分的邏輯運(yùn)算，所以大部分的數(shù)據(jù)緩存也應(yīng)該在這個(gè)進(jìn)程中，這樣才能符合游戲所需的延遲要求。

• 自動(dòng)進(jìn)行數(shù)據(jù)落地和容災(zāi)管理。由于游戲數(shù)據(jù)中有大量的“過(guò)程數(shù)據(jù)”，所以其一致性和完整性要求會(huì)稍微低于其他業(yè)務(wù)，所以應(yīng)該利用這一點(diǎn)，讓GameServer本身也可以是分布式的程序，從而提高系統(tǒng)整體的吞吐量。

• 具備良好的編程易用性。最好是能直接存取編程中的對(duì)象，避免反復(fù)對(duì)數(shù)據(jù)結(jié)構(gòu)的描述，節(jié)省大量的開(kāi)發(fā)時(shí)間。

總結(jié)

　　游戲服務(wù)器和普通互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器端，最大的區(qū)別實(shí)際上就在于“狀態(tài)”。游戲服務(wù)器的狀態(tài)是實(shí)時(shí)快速變化的、可以容忍丟失的、需要大量廣播同步的；普通互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器的狀態(tài)一般是持久化的、不容忍丟失的、只和特定客戶端相關(guān)的。所以一個(gè)好的游戲服務(wù)器框架，在通訊和數(shù)據(jù)這兩個(gè)基本層面，會(huì)和一般我們所接觸的開(kāi)源組件有很大的差異。這也是作為游戲服務(wù)器端開(kāi)發(fā)者，需要去共同建設(shè)行業(yè)標(biāo)準(zhǔn)的地方。