小編給大家分享一下Python編寫EVE的具體思路，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討方法吧！

成都創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)新沂,十余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108

大多數(shù)熟悉EVE的人都知道，它是用Python語言編寫的，如果要說得更具體點(diǎn)，那就是Stackless Python。Stackless是在Python基礎(chǔ)上編寫的一套微線程框架，它能在不產(chǎn)生大量Python自身額外開銷的情況下同時容納數(shù)百萬條的線程。

但話還是要說回來，它畢竟還是Python，因此擺脫不了“解釋器全局鎖”（Global Interpreter Lock，下文將其簡稱為GIL）。

GIL是一個序列鎖，用來保證在任何時候都只能有一個線程利用Python解釋器（包括其所有數(shù)據(jù)）來運(yùn)行自己。因此，盡管Stackless Python感覺上好像具備多線程處理能力，但實(shí)際上它還是單線程的，只不過運(yùn)用了任務(wù)分離、頻道、定時器及共享內(nèi)存等一系列招數(shù)而已。

其實(shí)過去有些協(xié)作式的多任務(wù)操作系統(tǒng)也是這樣干的，其好處是保證了所有線程都能被執(zhí)行，不會出現(xiàn)被操作系統(tǒng)提前結(jié)束這一情況（除非被操作系統(tǒng)懷疑非法宕機(jī)）。GIL的存在使得程序員在編寫游戲邏輯時能自信推斷出程序的全局狀態(tài)，省去了一大堆采用異步回調(diào)函數(shù)的麻煩。

但這樣有一大缺點(diǎn)：由于EVE中有部分框架的代碼是用Python編寫的，因此它們都免不了GIL造成的負(fù)面影響。比如，一段用來讀取Python數(shù)據(jù)的C++語言代碼必須在獲得GIL后才能讀取一個字符串。

使用Python的任務(wù)都要獲得GIL才能合法地被處理，這樣等同于Python任務(wù)都是單線程執(zhí)行。

（這圖畫得不太好看，人家只是個程序員，不是美術(shù)師哦）

一言以蔽之，Stackless Python 代碼的運(yùn)行速度不會高于你最快的那個CPU核心的速度。在一臺4核或8核CPU的服務(wù)器上，其中只有一核在超負(fù)荷運(yùn)作，其他都沒派上用場。當(dāng)然，為了讓這些CPU核心物盡其用，我們可以在它們身上加載更多的節(jié)點(diǎn)。

對于EVE中許多無狀態(tài)或?qū)蚕頎顟B(tài)依賴度極低的代碼而言，這沒什么問題。但對于像太空模擬或空間站行走這樣高度依賴共享狀態(tài)的代碼而言，就成了一個大問題。

假設(shè)一個CPU核心就能處理所有的邏輯并且寫出來的Python代碼較為清晰，那我之前說的都不是什么問題。不過，想必我不用說大家也知道，盡管Gridlock等小組已經(jīng)在優(yōu)化工作方面做到了其極致，但我們現(xiàn)在面臨的情況依舊是單個CPU已經(jīng)無法處理一場大型會戰(zhàn)了。

最近上市的CPU速度是更快、緩存容量也更大、總線也更寬裕并且具備更好的執(zhí)行流水線，但在EVE需要其給力的地方，卻沒有任何進(jìn)步。近期（也可能包括中長期）的趨勢是“橫向增長”，即同時運(yùn)行多個CPU核心。

總體而言，多核CPU的流行對EVE的長遠(yuǎn)發(fā)展是一大利好。未來那些30乃至60核CPU的機(jī)器能夠很好地體現(xiàn)EVE集群部署方式的優(yōu)勢，這是因?yàn)镃PU核心之間切換的效率將遠(yuǎn)遠(yuǎn)大于線程之間切換的效率。

但就目前而言，為了提升游戲運(yùn)行速度，我們需要把網(wǎng)絡(luò)及通用讀寫這樣的EVE模塊從GIL中解放出來。

多核心、超標(biāo)量的硬件對當(dāng)今的網(wǎng)絡(luò)游戲來說，都是個好消息。這些游戲很適合這種架構(gòu)，并且能很容易地進(jìn)行并行處理?？上τ谝蕾嘝ython的EVE來說，這就算不得好消息了。

那些對運(yùn)行速度要求極高、不需要Python便利開發(fā)優(yōu)勢的EVE系統(tǒng)需要盡早擺脫GIL的束縛。CarbonIO在這個方向上可以說是向前邁進(jìn)了一大步。

CarbonIO 是在StacklessIO 基礎(chǔ)上的一個自然提升。它實(shí)際上是個從頭寫起的全新引擎，目標(biāo)非常明確：讓網(wǎng)絡(luò)流量擺脫GIL的束縛，并且讓任何C++代碼也能這樣做。后半個目的是重頭戲，我們花了大半年才把它完成。

這里不得不先稍微提一下StacklessIO。對Stackless Python的網(wǎng)絡(luò)通信而言，它可以說是個質(zhì)的飛躍。通過讓網(wǎng)絡(luò)操作變得具有“無堆棧的意識”，StacklessIO可以將一個被鎖住的操作轉(zhuǎn)移到一個未被GIL鎖住的線程上，這樣該操作就可以繼續(xù)等候，而Stackless則繼續(xù)處理其他事務(wù)。

然后，該操作重新獲得GIL，告訴Stackless其操作已完成。這樣，接收端就可以同步進(jìn)行，使得通訊速度可以達(dá)到操作系統(tǒng)級別，并且能基本上在第一時間內(nèi)回報給Python。

StacklessIO在沒有GIL的情況下完成Python請求

CarbonIO在此基礎(chǔ)上更上一層樓。由于它是在完全脫離于GIL的情況下運(yùn)行多線程通信引擎，因此Python與該系統(tǒng)之間的交互便是完全獨(dú)立了。沒有Python的要求，它也能收發(fā)數(shù)據(jù)。

請?jiān)试S我再強(qiáng)調(diào)一下：CarbonIO能在Python不作任何要求的情況下收發(fā)數(shù)據(jù)。這是并發(fā)性的，不需要GIL。

當(dāng)一個連接通過CarbonIO被建立后，系統(tǒng)會調(diào)用WSARecv()開始接收數(shù)據(jù)。與Python進(jìn)程并行的線程池將這些數(shù)據(jù)解密、解壓縮然后轉(zhuǎn)義到數(shù)據(jù)包里。這些數(shù)據(jù)包會排隊(duì)，等著Python來處理。

當(dāng)Python覺得它需要一個數(shù)據(jù)包時，它會往下調(diào)用“可能已將此包準(zhǔn)備就緒”的CarbonIO。這意味著數(shù)據(jù)在離開隊(duì)列被返回整個過程中根本沒有用到GIL。這是一個瞬時過程，至少也有納秒那么快。這個并行讀取能力是CarbonIO的第一大好處。

第二大好處便是發(fā)送了。數(shù)據(jù)以其原始形式排在工作線程隊(duì)列里，然后便等著Python來調(diào)用了。

其間的壓縮、加密、打包及WSASend()調(diào)用都沒有觸及GIL而發(fā)生在另一個線程里，這樣操作系統(tǒng)便可以安排它運(yùn)行在另一顆CPU上了。C++代碼也可以調(diào)用一個方法來這樣做，并不需要特別的架構(gòu)變更。StacklessIO也可以那樣做，但在脫離上述背景的情況下，這會變得很沒意義。

讓我們再來回顧一下之前提到的“已將此包準(zhǔn)備就緒”。但如果我們要安置一個C++回調(diào)鉤子函數(shù)，使得非Python模塊能在不觸及Machonet的情況下獲得那個數(shù)據(jù)，這可行嗎？行啊，這時我們要用的就是BlueNet了。

CarbonIO不停地進(jìn)行數(shù)據(jù)接收，并且能在無Python介入的情況下告訴C++模塊數(shù)據(jù)已收到。

Machonet是一個大型功能集合，它負(fù)責(zé)對會話進(jìn)行分流、導(dǎo)向及管理，負(fù)責(zé)對數(shù)據(jù)包的時間計(jì)劃/發(fā)送以及其他一系列將EVE撮合成一個有機(jī)整體的功能。

由于它是個Python模塊，因此所有的數(shù)據(jù)遲早都必須觸及那倒霉的GIL，無論數(shù)據(jù)在哪個節(jié)點(diǎn)。無論一個C++模塊的速度有多快，GIL仍然是個繞不過的瓶頸。這使得我們曾經(jīng)都不太愿意做大量的C++優(yōu)化，因?yàn)槿魏蝺?yōu)化后取得的優(yōu)勢都會被Machonet 中的GIL吞噬。

但現(xiàn)在情況不一樣了。

現(xiàn)在C++的系統(tǒng)能通過BlueNet收發(fā)數(shù)據(jù)包，無需再理會GIL。這原來是專門為了空間站行走設(shè)計(jì)的?？臻g站行走功能需要發(fā)送大量的表示移動的數(shù)據(jù)。

EVE中太空飛行的那部分功能所需要收發(fā)的數(shù)據(jù)，我們以前可以用旁門左道的方法來解決，但對于如此近距離的人物動作，就不行了。之前我們做的預(yù)測顯示，即使把空間站行走發(fā)送數(shù)據(jù)的頻率控制在一般程度，該功能也會把整個服務(wù)器集群拖垮。

通過在沒有GIL干擾的情況下對流入/流出C++原生系統(tǒng)（比如物理系統(tǒng)）的數(shù)據(jù)進(jìn)行分流，BlueNet成功地解決了該問題。由于在這種情況下，數(shù)據(jù)還是保持著其原生態(tài)，因此整個系統(tǒng)運(yùn)行的速度就比之前提高了。

這個具體是怎么運(yùn)作的呢？BlueNet保存著一份所有必要Machonet結(jié)構(gòu)的只讀拷貝，另外，所有的數(shù)據(jù)包前都會附上很小的一段（8到10個字節(jié)的）數(shù)據(jù)頭。這個數(shù)據(jù)頭里含有路徑信息。

當(dāng)BlueNet接到一個數(shù)據(jù)包時，它會對其進(jìn)行檢測，然后合理地再分發(fā)：要么轉(zhuǎn)發(fā)到另一個節(jié)點(diǎn)上，要么交給被本地的已注冊的C++應(yīng)用程序。如果它轉(zhuǎn)發(fā)，那這個過程中將用不到GIL，根本不會調(diào)用Machonet/Python。

這意味著我們的代理服務(wù)器完全能以并行方式對BlueNet的數(shù)據(jù)包進(jìn)行分流，而不必去經(jīng)過Python導(dǎo)致額外開銷的產(chǎn)生。那這效率究竟提高了多少呢？我們還無法確定，但在降低機(jī)器負(fù)載及延遲方面，它還是非常非常明顯的。實(shí)際上我們還不能將數(shù)據(jù)公開，因?yàn)樗鼈兒玫秒y以置信。

除此之外，CarbonIO也包含了大量底層優(yōu)化，絕大多數(shù)都是小規(guī)模的速度提升，但把這些統(tǒng)統(tǒng)疊加起來，整個系統(tǒng)的運(yùn)行速度也就有了顯著提高。以下幾點(diǎn)值得一提：

工作分組

雖然我很難在本文中把這事兒說得太細(xì)，但CarbonIO非常出色地將工作分組來處理。

簡而言之，就是某些操作有了一個固定的開銷。網(wǎng)絡(luò)引擎有許多這樣的開銷，但其他所有具有重要意義的代碼也有大量開銷。通過一些別出心裁的技巧，我們是可以將許多這樣的工作合并在一起，這樣就只產(chǎn)生一次開銷。

就像把邏輯數(shù)據(jù)包都組合在一起發(fā)送在一個TCP/IP MTU里一樣（EVE一直就是這樣干的），CarbonIO將這一做法進(jìn)一步深化。一個比較簡單的例子就是GIL獲取集合。

第一個要嘗試取得GIL的線程會先建立起一個隊(duì)列，這樣其他要獲取GIL的線程只需將自己的喚醒調(diào)用排在隊(duì)列末尾然后返回線程池就行。那GIL最后被取得時，第一個線程會吸干整個隊(duì)列，不必在每次IO喚醒時釋放/重拾GIL。

在一個繁忙的服務(wù)器上這種情況很多，因此這種改進(jìn)對我們來說是一大利好。

openSSL 整合

CarbonIO用openSSL來實(shí)現(xiàn)SSL，并且能在不鎖定GIL的情況下與該協(xié)議數(shù)據(jù)通信。該庫只是用作一個BIO對而已，所有的數(shù)據(jù)導(dǎo)航還是由CarbonIO通過完成端口進(jìn)行的。

這有助于我們循序漸進(jìn)地讓EVE變得更安全，甚至將來可以把官方網(wǎng)站上的某些帳號管理功能挪到EVE客戶端上去，這樣可以更方便大家。

壓縮整合

CarbonIO能利用zlib或snappy對每一個數(shù)據(jù)包都進(jìn)行壓縮/解壓縮，這一過程同樣是無需GIL的。

實(shí)戰(zhàn)檢驗(yàn)

通過對一個繁忙的代理服務(wù)器（人數(shù)峰值大約1600人，一個平常工作日）的24小時數(shù)據(jù)的收集，我們發(fā)現(xiàn)CPU的總體使用率與單個用戶的CPU使用率都出現(xiàn)了大幅下降。

這都?xì)w功于CarbonIO的總體架構(gòu)，其作用就是降低事務(wù)的開銷。當(dāng)服務(wù)器變得繁忙之后，這些優(yōu)化的效果會被逐漸增多且必須處理的事務(wù)所抵消，但在最高負(fù)載時，CarbonIO還是讓我們的游戲增速了不少。

以上為24小時內(nèi)單個用戶的CPU使用率

以上為同樣的24小時內(nèi)總體CPU使用率

至于SOL（星系）節(jié)點(diǎn)，由于它們的主要職責(zé)是游戲機(jī)制而非網(wǎng)絡(luò)管理，因此它們從該優(yōu)化中獲得的優(yōu)勢并不那么明顯，但我們還是看到它們的CPU使用率下降了8%-10%。

需要指出的是，在上述的檢驗(yàn)中我們沒有運(yùn)用BlueNet，沒有用CarbonIO的數(shù)據(jù)導(dǎo)航，也沒有用脫離GIL的數(shù)據(jù)壓縮/解壓縮。

總的來說，比起以前，EVE能更好地利用現(xiàn)代服務(wù)器硬件帶來的優(yōu)勢，能讓它在同樣的時間內(nèi)完成更多的工作，這樣就間接提升了一個系統(tǒng)所能進(jìn)行的操作上限。

通過將我們的代碼盡量與GIL脫離，我們反而為那些真正需要用它的代碼騰出了空間。另外，由于不再有那么多代碼需要競相獲取GIL，系統(tǒng)的總體運(yùn)行效率也會提升。有了BlueNet再加上很好的代碼優(yōu)化，提速空間已被打開。雖然最后的結(jié)果仍有待實(shí)踐檢驗(yàn)，但至少，我們已經(jīng)消除了一大瓶頸。

看完了這篇文章，相信你對Python編寫EVE的具體思路有了一定的了解，想了解更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！