共計(jì) 5650 個(gè)字符，預(yù)計(jì)需要花費(fèi) 15 分鐘才能閱讀完成。
本篇內(nèi)容主要講解“經(jīng)典游戲服務(wù)器端架構(gòu)實(shí)例分析”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓丸趣 TV 小編來(lái)帶大家學(xué)習(xí)“經(jīng)典游戲服務(wù)器端架構(gòu)實(shí)例分析”吧!
架構(gòu)的分析模型一. 討論的背景
現(xiàn)代電子游戲，基本上都會(huì)使用一定的網(wǎng)絡(luò)功能。從驗(yàn)證正版，到多人交互等等，都需要架設(shè)一些專用的服務(wù)器，以及編寫(xiě)在服務(wù)器上的程序。因此，游戲服務(wù)器端軟件的架構(gòu)，本質(zhì)上也是游戲服務(wù)器這個(gè)特定領(lǐng)域的軟件架構(gòu)。
軟件架構(gòu)的分析，可以通過(guò)不同的層面入手。比較經(jīng)典的軟件架構(gòu)描述，包含了以下幾種架構(gòu)：
運(yùn)行時(shí)架構(gòu)——這種架構(gòu)關(guān)心如何解決運(yùn)行效率問(wèn)題，通常以程序進(jìn)程圖、數(shù)據(jù)流圖為表達(dá)方式。在大多數(shù)開(kāi)發(fā)團(tuán)隊(duì)的架構(gòu)設(shè)計(jì)文檔中，都會(huì)包含運(yùn)行時(shí)架構(gòu)，說(shuō)明這是一種非常重要的設(shè)計(jì)方面。這種架構(gòu)也會(huì)顯著的影響軟件代碼的開(kāi)發(fā)效率和部署效率。本文主要討論的是這種架構(gòu)。
邏輯架構(gòu)——這種架構(gòu)關(guān)心軟件代碼之間的關(guān)系，主要目的是為了提高軟件應(yīng)對(duì)需求變更的便利性。人們往往會(huì)以類圖、模塊圖來(lái)表達(dá)這種架構(gòu)。這種架構(gòu)設(shè)計(jì)在需要長(zhǎng)期運(yùn)營(yíng)和重用性高的項(xiàng)目中，有至關(guān)重要的作用。因?yàn)檐浖目蓴U(kuò)展性和可重用度基本是由這個(gè)方面的設(shè)計(jì)決定的。特別是在游戲領(lǐng)域，需求變更的頻繁程度，在多個(gè)互聯(lián)網(wǎng)產(chǎn)業(yè)領(lǐng)域里可以說(shuō)是最高的。本文會(huì)涉及一部分這種架構(gòu)的內(nèi)容，但不是本文的討論重點(diǎn)。
物理架構(gòu)——關(guān)心軟件如何部署，以機(jī)房、服務(wù)器、網(wǎng)絡(luò)設(shè)備為主要描述對(duì)象。
數(shù)據(jù)架構(gòu)——關(guān)心軟件涉及的數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)，對(duì)于數(shù)據(jù)分析挖掘，多系統(tǒng)協(xié)作有較大的意義。
開(kāi)發(fā)架構(gòu)——關(guān)心軟件開(kāi)發(fā)庫(kù)之間的關(guān)系，以及版本管理、開(kāi)發(fā)工具、編譯構(gòu)建的設(shè)計(jì)，主要為了提高多人協(xié)作開(kāi)發(fā)，以及復(fù)雜軟件庫(kù)引用的開(kāi)發(fā)效率?，F(xiàn)在流行的集成構(gòu)建系統(tǒng)就是一種開(kāi)發(fā)架構(gòu)的理論。
二. 游戲服務(wù)器架構(gòu)的要素
服務(wù)器端軟件的本質(zhì)，是一個(gè)會(huì)長(zhǎng)期運(yùn)行的程序，并且它還要服務(wù)于多個(gè)不定時(shí)，不定地點(diǎn)的網(wǎng)絡(luò)請(qǐng)求。所以這類軟件的特點(diǎn)是要非常關(guān)注穩(wěn)定性和性能。這類程序如果需要多個(gè)協(xié)作來(lái)提高承載能力，則還要關(guān)注部署和擴(kuò)容的便利性；同時(shí)，還需要考慮如何實(shí)現(xiàn)某種程度容災(zāi)需求。由于多進(jìn)程協(xié)同工作，也帶來(lái)了開(kāi)發(fā)的復(fù)雜度，這也是需要關(guān)注的問(wèn)題。
功能約束，是架構(gòu)設(shè)計(jì)決定性因素。一個(gè)萬(wàn)能的架構(gòu)，必定是無(wú)能的架構(gòu)。一個(gè)優(yōu)秀的架構(gòu)，則是正好把握了對(duì)應(yīng)業(yè)務(wù)領(lǐng)域的核心功能產(chǎn)生的。游戲領(lǐng)域的功能特征，于服務(wù)器端系統(tǒng)來(lái)說(shuō)，非常明顯的表現(xiàn)為幾個(gè)功能的需求：
對(duì)于游戲數(shù)據(jù)和玩家數(shù)據(jù)的存儲(chǔ)
對(duì)玩家客戶端進(jìn)行數(shù)據(jù)廣播
把一部分游戲邏輯在服務(wù)器上運(yùn)算，便于游戲更新內(nèi)容，以及防止外掛。
針對(duì)以上的需求特征，在服務(wù)器端軟件開(kāi)發(fā)上，我們往往會(huì)關(guān)注軟件對(duì)電腦內(nèi)存和 CPU 的使用，以求在特定業(yè)務(wù)代碼下，能盡量滿足承載量和響應(yīng)延遲的需求。最基本的做法就是“時(shí)空轉(zhuǎn)換”，用各種緩存的方式來(lái)開(kāi)發(fā)程序，以求在 CPU 時(shí)間和內(nèi)存空間上取得合適的平衡。在 CPU 和內(nèi)存之上，是另外一個(gè)約束因素：網(wǎng)卡。網(wǎng)絡(luò)帶寬直接限制了服務(wù)器的處理能力，所以游戲服務(wù)器架構(gòu)也必定要考慮這個(gè)因素。
對(duì)于游戲服務(wù)器架構(gòu)設(shè)計(jì)來(lái)說(shuō)，最重要的是利用游戲產(chǎn)品的需求約束，從而優(yōu)化出對(duì)此特定功能最合適的“時(shí) - 空”架構(gòu)。并且最小化對(duì)網(wǎng)絡(luò)帶寬的占用。
[圖 - 游戲服務(wù)器的分析模型]三. 核心的三個(gè)架構(gòu)
基于上述的分析模型，對(duì)于游戲服務(wù)端架構(gòu)，最重要的三個(gè)部分就是，如何使用 CPU、內(nèi)存、網(wǎng)卡的設(shè)計(jì)：
內(nèi)存架構(gòu)：主要決定服務(wù)器如何使用內(nèi)存，以保證盡量少的內(nèi)存泄漏的可能，以及最大化利用服務(wù)器端內(nèi)存來(lái)提高承載量，降低服務(wù)延遲。
調(diào)度架構(gòu)：設(shè)計(jì)如何使用進(jìn)程、線程、協(xié)程這些對(duì)于 CPU 調(diào)度的方案。選擇同步、異步等不同的編程模型，以提高服務(wù)器的穩(wěn)定性和承載量。同時(shí)也要考慮對(duì)于開(kāi)發(fā)帶來(lái)的復(fù)雜度問(wèn)題?，F(xiàn)在出現(xiàn)的虛擬化技術(shù)，如虛擬機(jī)、docker、云服務(wù)器等，都為調(diào)度架構(gòu)提供了更多的選擇。
通信模式：決定使用何種方式通訊。網(wǎng)絡(luò)通訊包含有傳輸層的選擇，如 TCP/UDP；據(jù)表達(dá)層的選擇，如定義協(xié)議；以及應(yīng)用層的接口設(shè)計(jì)，如消息隊(duì)列、事件分發(fā)、遠(yuǎn)程調(diào)用等。
本文的討論，也主要是集中于對(duì)以上三個(gè)架構(gòu)的分析。
四. 游戲服務(wù)器模型的進(jìn)化歷程
最早的游戲服務(wù)器是比較簡(jiǎn)單的，如 UO《網(wǎng)絡(luò)創(chuàng)世紀(jì)》的服務(wù)端一張 3.5 寸軟盤(pán)就能存下?；旧现皇且粋€(gè)廣播和存儲(chǔ)文件的服務(wù)器程序。后來(lái)由于國(guó)內(nèi)的外掛、盜版流行，各游戲廠商開(kāi)始以 MUD 為模型，建立主要運(yùn)行邏輯在服務(wù)器端的架構(gòu)。這種架構(gòu)在 MMORPG 類產(chǎn)品的不斷更新中發(fā)揚(yáng)光大，從而出現(xiàn)了以地圖、視野等分布要素設(shè)計(jì)的分布式游戲服務(wù)器。而在另外一個(gè)領(lǐng)域，休閑游戲，天然的需要集中超高的在線用戶，所以全區(qū)型架構(gòu)開(kāi)始出現(xiàn)?，F(xiàn)代的游戲服務(wù)器架構(gòu)，基本上都希望能結(jié)合承載量和擴(kuò)展性的有點(diǎn)來(lái)設(shè)計(jì)，從而形成了更加豐富多樣的形態(tài)。
本文的討論主要是選取這些比較典型的游戲服務(wù)器模型，分析其底層各種選擇的優(yōu)點(diǎn)和缺點(diǎn)，希望能探討出更具廣泛性，更高開(kāi)發(fā)效率的服務(wù)器模型。
分服模型一. 模型描述
分服模型是游戲服務(wù)器中最典型，也是歷久最悠久的模型。其特征是游戲服務(wù)器是一個(gè)個(gè)單獨(dú)的世界。每個(gè)服務(wù)器的帳號(hào)是獨(dú)立的，而且只用同一服務(wù)器的帳號(hào)才能產(chǎn)生線上交互。在早期服務(wù)器的承載量達(dá)到上限的時(shí)候，游戲開(kāi)發(fā)者就通過(guò)架設(shè)更多的服務(wù)器來(lái)解決。這樣提供了很多個(gè)游戲的“平行世界”，讓游戲中的人人之間的比較，產(chǎn)生了更多的空間。所以后來(lái)以服務(wù)器的開(kāi)放、合并形成了一套成熟的運(yùn)營(yíng)手段。一個(gè)技術(shù)上的選擇最后導(dǎo)致了游戲運(yùn)營(yíng)方式的模式，是一個(gè)非常有趣的現(xiàn)象。
[圖 - 單進(jìn)程調(diào)度模型]
同步 - 動(dòng)態(tài)多線程：每接收一個(gè)用戶會(huì)話，就建立一個(gè)線程。這個(gè)用戶會(huì)話往往就是由客戶端的 TCP 連接來(lái)代表，這樣每次從 socket 中調(diào)用讀取或?qū)懗鰯?shù)據(jù)包的時(shí)候，都可以使用阻塞模式，編碼直觀而簡(jiǎn)單。有多少個(gè)游戲客戶端的連接，就有多少個(gè)線程。但是這個(gè)方案也有很明顯的缺點(diǎn)，就是服務(wù)器容易產(chǎn)生大量的線程，這對(duì)于內(nèi)存占用不好控制，同時(shí)線程切換也會(huì)造成 CPU 的性能損失。更重要的多線程下對(duì)同一塊數(shù)據(jù)的讀寫(xiě)，需要處理鎖的問(wèn)題，這可能讓代碼變的非常復(fù)雜，造成各種死鎖的 BUG，影響服務(wù)器的穩(wěn)定性。
同步 - 多線程池：為了節(jié)約線程的建立和釋放，建立了一個(gè)線程池。每個(gè)用戶會(huì)話建立的時(shí)候，向線程池申請(qǐng)?zhí)幚砭€程的使用。在用戶會(huì)話結(jié)束的時(shí)候，線程不退出，而是向線程池“釋放”對(duì)此線程的使用。線程池能很好的控制線程數(shù)量，可以防止用戶暴漲下對(duì)服務(wù)器造成的連接沖擊，形成一種排隊(duì)進(jìn)入的機(jī)制。但是線程池本身的實(shí)現(xiàn)比較復(fù)雜，而“申請(qǐng)”、“施放”線程的調(diào)用規(guī)則需要嚴(yán)格遵守，否則會(huì)出現(xiàn)線程泄露，耗盡線程池。
異步 - 單線程 / 協(xié)程：在游戲行業(yè)中，采用 Linux 的 epoll 作為網(wǎng)絡(luò) API，以期得到高性能，是一個(gè)常見(jiàn)的選擇。游戲服務(wù)器進(jìn)程中最常見(jiàn)的阻塞調(diào)用就是網(wǎng)路 IO，因此在采用 epoll 之后，整個(gè)服務(wù)器進(jìn)程就可能變得完全沒(méi)有阻塞調(diào)用，這樣只需要一個(gè)線程即可。這徹底解決了多線程的鎖問(wèn)題，而且也簡(jiǎn)化了對(duì)于并發(fā)編程的難度。但是，“所有調(diào)用都不得阻塞”的約束，并不是那么容易遵守的，比如有些數(shù)據(jù)庫(kù)的 API 就是阻塞的；另外單進(jìn)程單線程只能使用一個(gè) CPU，在現(xiàn)在多核多 CPU 的服務(wù)器情況下，不能充分利用 CPU 資源。異步編程由于是基于“回調(diào)”的方式，會(huì)導(dǎo)致要定義很多回調(diào)函數(shù)，并且把一個(gè)流程里面的邏輯，分別寫(xiě)在多個(gè)不同的回調(diào)函數(shù)里面，對(duì)于代碼閱讀非常不理?！槍?duì)這種編碼問(wèn)題，協(xié)程 (Coroutine) 能較好的幫忙，所以現(xiàn)在比較流行使用異步 + 協(xié)程的組合。不管怎樣，異步 - 單線程模型由于性能好，無(wú)需并發(fā)思維，依然是現(xiàn)在很多團(tuán)隊(duì)的首選。
異步 - 固定多線程：這是基于異步 - 單線程模型進(jìn)化出來(lái)的一種模型。這種模型一般有三類線程：主線程、IO 線程、邏輯線程。這些線程都在內(nèi)部以全異步的方式運(yùn)行，而他們之間通過(guò)無(wú)鎖消息隊(duì)列通信。
多進(jìn)程游戲服務(wù)器
多進(jìn)程的游戲服務(wù)器系統(tǒng)，最早起源于對(duì)于性能問(wèn)題需求。由于單進(jìn)程架構(gòu)下，總會(huì)存在承載量的極限，越是復(fù)雜的游戲，其單進(jìn)程承載量就越低，因此開(kāi)發(fā)者們一定要突破進(jìn)程的限制，才能支撐更復(fù)雜的游戲。
一旦走上多進(jìn)程之路，開(kāi)發(fā)者們還發(fā)現(xiàn)了多進(jìn)程系統(tǒng)的其他一些好處：能夠利用上多核 CPU 能力；利用操作系統(tǒng)的工具能更仔細(xì)的監(jiān)控到運(yùn)行狀態(tài)、更容易進(jìn)行容災(zāi)處理。多進(jìn)程系統(tǒng)比較經(jīng)典的模型是“三層架構(gòu)”：
在多進(jìn)程架構(gòu)下，開(kāi)發(fā)者一般傾向于把每個(gè)模塊的功能，都單獨(dú)開(kāi)發(fā)成一個(gè)進(jìn)程，然后以使用進(jìn)程間通信來(lái)協(xié)調(diào)處理完整的邏輯。這種思想是典型的“管道與過(guò)濾器”架構(gòu)模式思想——把每個(gè)進(jìn)程看成是一個(gè)過(guò)濾器，用戶發(fā)來(lái)的數(shù)據(jù)包，流經(jīng)多個(gè)過(guò)濾器銜接而成的管道，最后被完整的處理完。由于使用了多進(jìn)程，所以首選使用單進(jìn)程單線程來(lái)構(gòu)造其中的每個(gè)進(jìn)程。這樣對(duì)于程序開(kāi)發(fā)來(lái)說(shuō)，結(jié)構(gòu)清晰簡(jiǎn)單很多，也能獲得更高的性能。
[圖 - 對(duì)象樹(shù)架構(gòu)]
在 Objective C 語(yǔ)言中，有所謂 autorealse 的特性，這種特性實(shí)際上是一種引用計(jì)數(shù)的技術(shù)。由于能配合在某個(gè)調(diào)度模型下，所以使用起來(lái)會(huì)比較簡(jiǎn)單。同樣的思想，有些開(kāi)發(fā)者會(huì)使用一些智能指針，配合自己寫(xiě)的框架，在完整的業(yè)務(wù)邏輯調(diào)用后一次性清理相關(guān)內(nèi)存。
[圖 - 預(yù)分配內(nèi)存池]
不過(guò)這樣做，同樣有一些缺點(diǎn)：首先是不太好部署，比如你想在某個(gè)資源較小的虛擬機(jī)上部署一套用來(lái)測(cè)試，可能一位內(nèi)沒(méi)改內(nèi)存池的大小，導(dǎo)致啟動(dòng)不成功。每次更換環(huán)境都需要修改這個(gè)配置。其次，是所有的用到的類對(duì)象，都要在根節(jié)點(diǎn)對(duì)象那里有個(gè)指針或者引用，否則就可能泄漏內(nèi)存。由于對(duì)于非基本類型的對(duì)象，我們一般不喜歡用拷貝的方式來(lái)作為函數(shù)的參數(shù)和返回值，而指針和應(yīng)用所指向的內(nèi)存，如果不能 new 的話，只能是現(xiàn)成的某個(gè)對(duì)象的成員屬性。這回導(dǎo)致程序越復(fù)雜，這類的成員屬性就越多，這些屬性在代碼維護(hù)是一個(gè)不小的負(fù)擔(dān)。
要解決以上的缺點(diǎn)，可以修改內(nèi)存池的實(shí)現(xiàn)，為動(dòng)態(tài)增長(zhǎng)，但是具備上限的模型，每次從內(nèi)存池中“獲取”對(duì)象的時(shí)候才 new。這樣就能避免在小內(nèi)存機(jī)器上啟動(dòng)不了的問(wèn)題。對(duì)于對(duì)象屬性復(fù)雜的問(wèn)題，一般上需要好好的按面向?qū)ο蟮脑瓌t規(guī)劃代碼，做到盡量少用僅僅表示函數(shù)參數(shù)和返回值的屬性，而是主要是記錄對(duì)象的“業(yè)務(wù)狀態(tài)”屬性為主，多花點(diǎn)功夫在構(gòu)建游戲的數(shù)據(jù)模型上。
四. 進(jìn)程間通訊手段
在多進(jìn)程的系統(tǒng)中，進(jìn)程間如何通訊是一個(gè)至關(guān)重要的問(wèn)題，其性能和使用便利性，直接決定了多進(jìn)程系統(tǒng)的技術(shù)效能。
Socket 通訊
TCP/IP 協(xié)議是一種通用的、跨語(yǔ)言、跨操作系統(tǒng)、跨機(jī)器的通訊方案。這也是開(kāi)發(fā)者首先想到的一種手段。在使用上，有使用 TCP 和 UDP 兩個(gè)選擇。一般我們傾向在游戲系統(tǒng)中使用 TCP，因?yàn)橛螒驍?shù)據(jù)的邏輯相關(guān)性比較強(qiáng)，UDP 由于可能存在的丟包和重發(fā)處理，在游戲邏輯上的處理一般比較復(fù)雜。由于多進(jìn)程系統(tǒng)的進(jìn)程間網(wǎng)絡(luò)一般情況較好，UDP 的性能優(yōu)勢(shì)不會(huì)特別明顯。
要使用 TCP 做跨進(jìn)程通訊，首先就是要寫(xiě)一個(gè) TCP Server，做端口監(jiān)聽(tīng)和連接管理；其次需要對(duì)可能用到的通信內(nèi)容做協(xié)議定制；最后是要編寫(xiě)編解碼和業(yè)務(wù)邏輯轉(zhuǎn)發(fā)的邏輯。這些都完成了之后，才能真正的開(kāi)始用來(lái)作為進(jìn)程間通信手段。
使用 Socket 編程的好處是通用性廣，你可以用來(lái)實(shí)現(xiàn)任何的功能，和任何的進(jìn)程進(jìn)行協(xié)作。但是其缺點(diǎn)也異常明顯，就是開(kāi)發(fā)量很大。雖然現(xiàn)在有一些開(kāi)源組件，可以幫你簡(jiǎn)化 Socket Server 的編寫(xiě)工作，簡(jiǎn)化連接管理和消息分發(fā)的處理，但是選擇目標(biāo)建立連接、定制協(xié)議編解碼這兩個(gè)工作往往還是要自己去做。游戲的特點(diǎn)是業(yè)務(wù)邏輯變化很多，導(dǎo)致協(xié)議修改的工作量非常大。因此我們除了直接使用 TCP/IP socket 以外，還有很多其他的方案可以嘗試。
[圖 - 消息隊(duì)列]
需要注意的是，有些開(kāi)發(fā)者缺乏經(jīng)驗(yàn)，使用了數(shù)據(jù)庫(kù)，如 MySQL，或者是 NFS 這類運(yùn)行效率比較低的媒介作為隊(duì)列的存儲(chǔ)者。這在功能上雖然可以行得通，但是操作一頻繁，就難以發(fā)揮作用了。如以前有一些手機(jī)短信應(yīng)用系統(tǒng)，就用 MySQL 來(lái)存儲(chǔ)“待發(fā)送”的短信。
消息隊(duì)列雖然非常好用，但是我們還是要自己對(duì)消息進(jìn)行編解碼，并且分發(fā)給所需要的處理程序。在消息到處理程序之間，存在著一個(gè)轉(zhuǎn)換和對(duì)應(yīng)的工作。由于游戲邏輯的繁多，這種對(duì)應(yīng)工作完全靠手工編碼，是比較容易出錯(cuò)的。所以這里還有進(jìn)一步的改進(jìn)空間。
遠(yuǎn)程調(diào)用
有一些開(kāi)發(fā)者會(huì)希望，在編碼的時(shí)候完全屏蔽是否跨進(jìn)程在進(jìn)行調(diào)用，完全可以好像調(diào)用本地函數(shù)或者本地對(duì)象的方法一樣。于是誕生了很多遠(yuǎn)程調(diào)用的方案，最經(jīng)典的有 Corba 方案，它試圖實(shí)現(xiàn)能在不同語(yǔ)言的代碼直接，實(shí)現(xiàn)遠(yuǎn)程調(diào)用。JAVA 虛擬機(jī)自帶了 RMI 方案的支持，在 JAVA 進(jìn)程之間遠(yuǎn)程調(diào)用是比較方便的。在互聯(lián)網(wǎng)的環(huán)境下，還有各種 Web Service 方案，以 HTTP 協(xié)議作為承載，WSDL 作為接口描述。
使用遠(yuǎn)程調(diào)用的方案，最大好處是開(kāi)發(fā)的便捷，你只需要寫(xiě)一個(gè)函數(shù)，就能在任何一個(gè)其他進(jìn)程上對(duì)此函數(shù)進(jìn)行調(diào)用。這對(duì)游戲開(kāi)發(fā)來(lái)說(shuō)，就解決了多進(jìn)程方案最大的一個(gè)開(kāi)發(fā)效率問(wèn)題。但是這種便捷是有成本的：一般來(lái)說(shuō)，遠(yuǎn)程調(diào)用的性能會(huì)稍微差一點(diǎn)，因?yàn)樾枰靡惶捉y(tǒng)一的編解碼方案。如果你使用的是 C /C++ 這類靜態(tài)語(yǔ)言，還需要使用一種 IDL 語(yǔ)言來(lái)先描述這種遠(yuǎn)程函數(shù)的接口。但是這些困難帶來(lái)的好處，在游戲開(kāi)發(fā)領(lǐng)域還是非常值得的。
[圖 - 服務(wù)器狀態(tài)管理]
盡管用簡(jiǎn)單的目錄服務(wù)器可以實(shí)現(xiàn)大部分容災(zāi)和擴(kuò)容的需求，但是如果被訪問(wèn)進(jìn)程的內(nèi)存中有數(shù)據(jù)存在，那么問(wèn)題就比較復(fù)雜了。對(duì)于容災(zāi)來(lái)說(shuō)，新的進(jìn)程必須要有辦法重建那個(gè)“失效”了的進(jìn)程內(nèi)存中的數(shù)據(jù)，才可能完成容災(zāi)功能；對(duì)于擴(kuò)容功能來(lái)說(shuō)，新加入的進(jìn)程，也必須能把需要的數(shù)據(jù)載入到自己的內(nèi)存中才行，而這些數(shù)據(jù)，可能已經(jīng)存在于其他平行的進(jìn)程中，如何把這部分?jǐn)?shù)據(jù)轉(zhuǎn)移過(guò)來(lái)，是一個(gè)比較耗費(fèi)性能和需要編寫(xiě)相當(dāng)多代碼的工作。——所以一般我們喜歡對(duì)“無(wú)狀態(tài)”的進(jìn)程來(lái)做擴(kuò)容和容災(zāi)。
到此，相信大家對(duì)“經(jīng)典游戲服務(wù)器端架構(gòu)實(shí)例分析”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
