一 專(zhuān)業(yè)基礎(chǔ)

1.1 網(wǎng)絡(luò)

1.1.1 理解TCP/IP協(xié)議

網(wǎng)絡(luò)傳輸模型

滑動(dòng)窗口技術(shù)

建立連接的三次握手與斷開(kāi)連接的四次握手

連接建立與斷開(kāi)過(guò)程中的各種狀態(tài)

TCP/IP協(xié)議的傳輸效率

思考

1）請(qǐng)解釋DOS攻擊與DRDOS攻擊的基本原理

2）一個(gè)100Byte數(shù)據(jù)包，精簡(jiǎn)到50Byte, 其傳輸效率提高了50%

3）TIMEWAIT狀態(tài)怎么解釋?zhuān)?/dd>

1.1.2 掌握常用的網(wǎng)絡(luò)通信模型

Select

Epoll，邊緣觸發(fā)與平臺(tái)出發(fā)點(diǎn)區(qū)別與應(yīng)用

Select與Epoll的區(qū)別及應(yīng)用

1.2 存儲(chǔ)

計(jì)算機(jī)系統(tǒng)存儲(chǔ)體系

程序運(yùn)行時(shí)的內(nèi)存結(jié)構(gòu)

計(jì)算機(jī)文件系統(tǒng)，頁(yè)表結(jié)構(gòu)

內(nèi)存池與對(duì)象池的實(shí)現(xiàn)原理，應(yīng)用場(chǎng)景與區(qū)別

關(guān)系數(shù)據(jù)庫(kù)MySQL的使用

共享內(nèi)存

1.3 程序

對(duì)C/C++語(yǔ)言有較深的理解

深刻理解接口，封裝與多態(tài)，并且有實(shí)踐經(jīng)驗(yàn)

深刻理解常用的數(shù)據(jù)結(jié)構(gòu)：數(shù)組，鏈表，二叉樹(shù)，哈希表

熟悉常用的算法及相關(guān)復(fù)雜度：冒泡排序，快速排序

二 游戲開(kāi)發(fā)入門(mén)

2.1防御式編程

不要相信客戶(hù)端數(shù)據(jù)，一定要檢驗(yàn)。作為服務(wù)器端你無(wú)法確定你的客戶(hù)端是誰(shuí)，你也不能假定它是善意的，請(qǐng)做好自我保護(hù)。(這是判斷一個(gè)服務(wù)器端程序員是否入門(mén)的基本標(biāo)準(zhǔn))

務(wù)必對(duì)于函數(shù)的傳人參數(shù)和返回值進(jìn)行合法性判斷，內(nèi)部子系統(tǒng)，功能模塊之間不要太過(guò)信任，要求低耦合，高內(nèi)聚

插件式的模塊設(shè)計(jì)，模塊功能的健壯性應(yīng)該是內(nèi)建的，盡量減少模塊間耦合

2.2 設(shè)計(jì)模式

道法自然。不要迷信，迷戀設(shè)計(jì)模式，更不要生搬硬套

簡(jiǎn)化，簡(jiǎn)化，再簡(jiǎn)化，用最簡(jiǎn)單的辦法解決問(wèn)題

借大寶一句話(huà)：設(shè)計(jì)本天成，妙手偶得之

2.3 網(wǎng)絡(luò)模型

自造輪子: Select, Epoll， Epoll一定比Select高效嗎？

開(kāi)源框架: Libevent, libev, ACE

2.4 數(shù)據(jù)持久化

自定義文件存儲(chǔ)，如《夢(mèng)幻西游》

關(guān)系數(shù)據(jù)庫(kù): MySQL

NO-SQL數(shù)據(jù)庫(kù): MongoDB

2.5 內(nèi)存管理

使用內(nèi)存池和對(duì)象池，禁止運(yùn)行期間動(dòng)態(tài)分配內(nèi)存

對(duì)于輸入輸出的指針參數(shù)，嚴(yán)格檢查，寧濫勿缺

寫(xiě)內(nèi)存保護(hù)。使用帶內(nèi)存保護(hù)的函數(shù)(strncpy, memcpy, snprintf, vsnprintf等)，嚴(yán)防數(shù)組下標(biāo)越界

防止讀內(nèi)存溢出，確保字符串以’\0’結(jié)束

2.6 日志系統(tǒng)

簡(jiǎn)單高效，大量日志操作不應(yīng)該影響程序性能

穩(wěn)定，做到服務(wù)器崩潰是日志不丟失

完備，玩家關(guān)鍵操作一定要記日志，理想的情況是通過(guò)日志能重建任何時(shí)刻的玩家數(shù)據(jù)

開(kāi)關(guān)，開(kāi)發(fā)日志的要加級(jí)別開(kāi)關(guān)控制

2.7 通信協(xié)議

采用PDL(Protocol Design Language)， 如Protobuf，可以同時(shí)生成前后端代碼，減少前后端協(xié)議聯(lián)調(diào)成本， 擴(kuò)展性好

JSON，文本協(xié)議，簡(jiǎn)單，自解釋?zhuān)瑹o(wú)聯(lián)調(diào)成本，擴(kuò)展性好，也很方便進(jìn)行包過(guò)濾以及寫(xiě)日志

自定義二進(jìn)制協(xié)議，精簡(jiǎn)，有高效的傳輸性能，完全可控，幾乎無(wú)擴(kuò)展性

2.8 全局唯一Key（GUID）

為合服做準(zhǔn)備

方便追蹤道具，裝備流向

每個(gè)角色，裝備，道具都應(yīng)對(duì)應(yīng)有全局唯一Key

2.9 多線(xiàn)程與同步

消息隊(duì)列進(jìn)行同步化處理

2.10 狀態(tài)機(jī)

強(qiáng)化角色的狀態(tài)

前置狀態(tài)的檢查校驗(yàn)

2.11 數(shù)據(jù)包操作

合并, 同一幀內(nèi)的數(shù)據(jù)包進(jìn)行合并，減少I(mǎi)O操作次數(shù)

單副本, 用一個(gè)包盡量只保存一份，減少內(nèi)存復(fù)制次數(shù)

AOI同步中減少中間過(guò)程無(wú)用數(shù)據(jù)包

2.12 狀態(tài)監(jiān)控

隨時(shí)監(jiān)控服務(wù)器內(nèi)部狀態(tài)

內(nèi)存池，對(duì)象池使用情況

幀處理時(shí)間

網(wǎng)絡(luò)IO

包處理性能

各種業(yè)務(wù)邏輯的處理次數(shù)

2.13 包頻率控制

基于每個(gè)玩家每條協(xié)議的包頻率控制，癱瘓變速齒輪

2.14 開(kāi)關(guān)控制

每個(gè)模塊都有開(kāi)關(guān)，可以緊急關(guān)閉任何出問(wèn)題的功能模塊

2.15 反外掛反作弊

包頻率控制可以消滅變速齒輪

包id自增校驗(yàn)，可以消滅WPE

包校驗(yàn)碼可以消滅包攔截篡改

圖形識(shí)別嗎，可以踢掉99%非人的操作

魔高一尺，道高一丈

2.16 熱更新

核心配置邏輯的熱更新，如防沉迷系統(tǒng)，包頻率控制，開(kāi)關(guān)控制等

代碼基本熱更新，如Erlang，Lua等

2.17 防刷

關(guān)鍵系統(tǒng)資源（如元寶，精力值，道具，裝備等）的產(chǎn)出記日志

資源的產(chǎn)出和消耗盡量依賴(lài)兩個(gè)或以上的獨(dú)立條件的檢測(cè)

嚴(yán)格檢查各項(xiàng)操作的前置條件

校驗(yàn)參數(shù)合法性

2.18 防崩潰

系統(tǒng)底層與具體業(yè)務(wù)邏輯無(wú)關(guān)，可以用大量的機(jī)器人壓力測(cè)試暴露各種bug，確保穩(wěn)定

業(yè)務(wù)邏輯建議使用腳本

系統(tǒng)性的保證游戲不會(huì)崩潰

2.19 性能優(yōu)化

IO操作異步化

IO操作合并緩寫(xiě) （事務(wù)性的提交db操作，包合并，文件日志緩寫(xiě)）

Cache機(jī)制

減少競(jìng)態(tài)條件 (避免頻繁進(jìn)出切換，盡量減少鎖定使用，多線(xiàn)程不一定由于單線(xiàn)程) 多線(xiàn)程不一定比單線(xiàn)程快

減少內(nèi)存復(fù)制

自己測(cè)試，用數(shù)據(jù)說(shuō)話(huà)，別猜

2.20 運(yùn)營(yíng)支持

接口支持：實(shí)時(shí)查詢(xún)，控制指令，數(shù)據(jù)監(jiān)控，客服處理等

實(shí)現(xiàn)考慮提供Http接口

2.21 容災(zāi)與故障預(yù)案

略

三 服務(wù)器端架構(gòu)

3.1 什么是好的架構(gòu)？

滿(mǎn)足業(yè)務(wù)要求

能迅速的實(shí)現(xiàn)策劃需求，響應(yīng)需求變更

系統(tǒng)級(jí)的穩(wěn)定性保障

簡(jiǎn)化開(kāi)發(fā)。將復(fù)雜性控制在架構(gòu)底層，降低對(duì)開(kāi)發(fā)人員的技術(shù)要求，邏輯開(kāi)發(fā)不依賴(lài)于開(kāi)發(fā)人員本身強(qiáng)大的技術(shù)實(shí)力，提高開(kāi)發(fā)效率

完善的運(yùn)營(yíng)支撐體系

3.2 架構(gòu)實(shí)踐的思考

簡(jiǎn)單，滿(mǎn)足需求的架構(gòu)就是好架構(gòu)

設(shè)計(jì)性能，抓住重要的20%， 沒(méi)必要從程序代碼里面去摳性能

熱更新是必須的

人難免會(huì)犯錯(cuò)，盡可能的用一套機(jī)制去保障邏輯的健壯性

游戲服務(wù)器的設(shè)計(jì)是一項(xiàng)頗有挑戰(zhàn)性的工作，游戲服務(wù)器的發(fā)展也由以前的單服結(jié)構(gòu)轉(zhuǎn)變?yōu)槎喾C(jī)構(gòu)，甚至出現(xiàn)了bigworld引擎的分布式解決方案，最近了解到Unreal的服務(wù)器解決方案atlas也是基于集群的方式。

負(fù)載均衡是一個(gè)很復(fù)雜的課題，這里暫不談bigworld和atlas的這類(lèi)服務(wù)器的設(shè)計(jì)，更多的是基于功能和場(chǎng)景劃分服務(wù)器結(jié)構(gòu)。

首先說(shuō)一下思路，服務(wù)器劃分基于以下原則：

1. 分離游戲中占用系統(tǒng)資源（cpu，內(nèi)存，IO等）較多的功能，獨(dú)立成服務(wù)器。
2. 在同一服務(wù)器架構(gòu)下的不同游戲，應(yīng)盡可能的復(fù)用某些服務(wù)器（進(jìn)程級(jí)別的復(fù)用）。
3. 以多線(xiàn)程并發(fā)的編程方式適應(yīng)多核處理器。
4. 寧可在服務(wù)器之間多復(fù)制數(shù)據(jù)，也要保持清晰的數(shù)據(jù)流向。
5. 主要按照?qǐng)鼍皠澐诌M(jìn)程，若需按功能劃分，必須保持整個(gè)邏輯足夠的簡(jiǎn)單，并滿(mǎn)足以上1，2點(diǎn)。

服務(wù)器結(jié)構(gòu)圖：

各個(gè)服務(wù)器的簡(jiǎn)要說(shuō)明：

Gateway 是應(yīng)用網(wǎng)關(guān)，主要用于保持和client的連接，該服務(wù)器需要2種IO，對(duì)client采用高并發(fā)連接，低吞吐量的網(wǎng)絡(luò)模型，如IOCP等，對(duì)服務(wù)器采用高吞吐量連接，如阻塞或異步IO。

網(wǎng)關(guān)主要有以下用途：

1. 分擔(dān)了網(wǎng)絡(luò)IO資源
2. 同時(shí)，也分擔(dān)了網(wǎng)絡(luò)消息包的加解密，壓縮解壓等cpu密集的操作。
3. 隔離了client和內(nèi)部服務(wù)器組，對(duì)client來(lái)說(shuō)，它只需要知道網(wǎng)關(guān)的相關(guān)信息即可（ip和port）。
4. client由于一直和網(wǎng)關(guān)保持常連接，所以切換場(chǎng)景服務(wù)器等操作對(duì)client來(lái)說(shuō)是透明的。
5. 維護(hù)玩家登錄狀態(tài)。

World Server 是一個(gè)控制中心，它負(fù)責(zé)把各種計(jì)算資源分布到各個(gè)服務(wù)器，它具有以下職責(zé)：

1. 管理和維護(hù)多個(gè)Scene Server。
2. 管理和維護(hù)多個(gè)功能服務(wù)器，主要是同步數(shù)據(jù)到功能服務(wù)器。
3. 復(fù)雜轉(zhuǎn)發(fā)其他服務(wù)器和Gateway之間的數(shù)據(jù)。
4. 實(shí)現(xiàn)其他需要跨場(chǎng)景的功能，如組隊(duì)，聊天，幫派等。

Phys Server 主要用于玩家移動(dòng)，碰撞等檢測(cè)。

所有玩家的移動(dòng)類(lèi)操作都在該服務(wù)器上做檢查，所以該服務(wù)器本身具備所有地圖的地形等相關(guān)信息。具體檢查過(guò)程是這樣的：首先，Worldserver收到一個(gè)移動(dòng)信息，WorldServer收到后向Phys Server請(qǐng)求檢查，Phys Server檢查成功后再返回給world Server，然后world server傳遞給相應(yīng)的Scene Server。

Scene Server 場(chǎng)景服務(wù)器，按場(chǎng)景劃分，每個(gè)服務(wù)器負(fù)責(zé)的場(chǎng)景應(yīng)該是可以配置的。理想情況下是可以動(dòng)態(tài)調(diào)節(jié)的。

ItemMgr Server 物品管理服務(wù)器，負(fù)責(zé)所有物品的生產(chǎn)過(guò)程。在該服務(wù)器上存儲(chǔ)一個(gè)物品掉落數(shù)據(jù)庫(kù)，服務(wù)器初始化的時(shí)候載入到內(nèi)存。任何需要產(chǎn)生物品的服務(wù)器均與該服務(wù)器直接通信。

AIServer 又一個(gè)功能服務(wù)器，負(fù)責(zé)管理所有NPC的AI。AI服務(wù)器通常有2個(gè)輸入，一個(gè)是Scene Server發(fā)送過(guò)來(lái)的玩家相關(guān)操作信息，另一個(gè)時(shí)鐘Timer驅(qū)動(dòng)，在這個(gè)設(shè)計(jì)中，對(duì)其他服務(wù)器來(lái)說(shuō)，AIServer就是一個(gè)擁有很多個(gè)NPC的客戶(hù)端。AIserver需要同步所有與AI相關(guān)的數(shù)據(jù)，包括很多玩家數(shù)據(jù)。由于AIServer的Timer驅(qū)動(dòng)特性，可在很大程度上使用TBB程序庫(kù)來(lái)發(fā)揮多核的性能。

把網(wǎng)絡(luò)游戲服務(wù)器分拆成多個(gè)進(jìn)程，分開(kāi)部署。這種設(shè)計(jì)的好處是模塊自然分離，可以單獨(dú)設(shè)計(jì)。分擔(dān)負(fù)荷，可以提高整個(gè)系統(tǒng)的承載能力。

缺點(diǎn)在于，網(wǎng)絡(luò)環(huán)境并不那么可靠。跨進(jìn)程通訊有一定的不可預(yù)知性。服務(wù)器間通訊往往難以架設(shè)調(diào)試環(huán)境，并很容易把事情攪成一團(tuán)糨糊。而且正確高效的管理多連接，對(duì)程序員來(lái)說(shuō)也是一項(xiàng)挑戰(zhàn)。

前些年，我也曾寫(xiě)過(guò)好幾篇與之相關(guān)的設(shè)計(jì)。這幾天在思考一個(gè)問(wèn)題：如果我們要做一個(gè)底層通用模塊，讓后續(xù)開(kāi)發(fā)更為方便。到底要解決怎樣的需求。這個(gè)需求應(yīng)該是單一且基礎(chǔ)的，每個(gè)應(yīng)用都需要的。

正如 TCP 協(xié)議解決了互聯(lián)網(wǎng)上穩(wěn)定可靠的點(diǎn)對(duì)點(diǎn)數(shù)據(jù)流通訊一樣。游戲世界實(shí)際需要的是一個(gè)穩(wěn)定可靠的在游戲系統(tǒng)內(nèi)的點(diǎn)對(duì)點(diǎn)通訊需要。

我們可以在一條 TCP 連接之上做到這一點(diǎn)。一旦實(shí)現(xiàn)，可以給游戲服務(wù)的開(kāi)發(fā)帶來(lái)極大的方便。

可以把游戲系統(tǒng)內(nèi)的各項(xiàng)服務(wù)，包括并不限于登陸，拍賣(mài)，戰(zhàn)斗場(chǎng)景，數(shù)據(jù)服務(wù)，等等獨(dú)立服務(wù)看成網(wǎng)絡(luò)上的若干終端。每個(gè)玩家也可以是一個(gè)獨(dú)立終端。它們一起構(gòu)成一個(gè)網(wǎng)絡(luò)。在這個(gè)網(wǎng)絡(luò)之上，終端之間可以進(jìn)行可靠的連接和通訊。

實(shí)現(xiàn)可以是這樣的：每個(gè)虛擬終端都在游戲虛擬網(wǎng)絡(luò)(Game Network)上有一個(gè)唯一地址 (Game Network Address , GNA) 。這個(gè)地址可以預(yù)先設(shè)定，也可以動(dòng)態(tài)分配。每個(gè)終端都可以通過(guò)游戲網(wǎng)絡(luò)的若干接入點(diǎn) ( GNAP ) 通過(guò)唯一一條 TCP 連接接入網(wǎng)絡(luò)。接入過(guò)程需要通過(guò)鑒權(quán)。

鑒權(quán)過(guò)程依賴(lài)內(nèi)部的安全機(jī)制，可以包括密碼證書(shū)，或是特別的接入點(diǎn)區(qū)分。（例如，玩家接入網(wǎng)絡(luò)就需要特定的接入點(diǎn)，這個(gè)接入點(diǎn)接入的終端都一定是玩家）

鑒權(quán)通過(guò)后，網(wǎng)絡(luò)為終端分配一個(gè)固定的游戲域名。例如，玩家進(jìn)入會(huì)分配到 player.12345 這樣的域名，數(shù)據(jù)庫(kù)接入可能分配到 database 。

游戲網(wǎng)絡(luò)默認(rèn)提供一個(gè)域名查詢(xún)服務(wù)（這個(gè)服務(wù)可以通過(guò)鑒權(quán)的過(guò)程注冊(cè)到網(wǎng)絡(luò)中），讓每個(gè)終端都能通過(guò)域名查詢(xún)到對(duì)應(yīng)的地址。

然后，游戲網(wǎng)絡(luò)里所有合法接入的終端都可以通過(guò)其地址相互發(fā)起連接并通訊了。整個(gè)協(xié)議建立在 TCP 協(xié)議之上，工作于唯一的這個(gè) TCP 連接上。和直接使用 TCP 連接不同。游戲網(wǎng)絡(luò)中每個(gè)終端之間相互發(fā)起連接都是可靠的。不僅玩家可以向某個(gè)服務(wù)發(fā)起連接，反過(guò)來(lái)也是可以的。玩家之間的直接連接也是可行的（是否允許這樣，取決于具體設(shè)計(jì)）。

由于每個(gè)虛擬連接都是建立在單一的 TCP 連接之上。所以減少了互連網(wǎng)上發(fā)起 TCP 連接的各種不可靠性。鑒權(quán)過(guò)程也是一次性唯一的。并且我們提供域名反查服務(wù)，我們的游戲服務(wù)可以清楚且安全的知道連接過(guò)來(lái)的是誰(shuí)。

系統(tǒng)可以設(shè)計(jì)為，游戲網(wǎng)絡(luò)上每個(gè)終端離網(wǎng)，域名服務(wù)將廣播這條消息，通知所有人。這種廣播服務(wù)在互聯(lián)網(wǎng)上難以做到，但無(wú)論是廣播還是組播，在這個(gè)虛擬游戲網(wǎng)絡(luò)中都是可行的。

在這種設(shè)計(jì)上。在邏輯層面，我們可以讓玩家直接把聊天信息從玩家客互端發(fā)送到聊天服務(wù)器，而不需要建立多余的 TCP 連接，也不需要對(duì)轉(zhuǎn)發(fā)處理聊天消息做多余的處理。聊天服務(wù)器可以獨(dú)立的存在于游戲網(wǎng)絡(luò)。也可以讓廣播服務(wù)主動(dòng)向玩家推送消息，由服務(wù)器向玩家發(fā)起連接，而不是所有連接請(qǐng)求都是由玩家客互端發(fā)起。

虛擬游戲網(wǎng)絡(luò)的構(gòu)成是一個(gè)獨(dú)立的層次，完全可以撇開(kāi)具體游戲邏輯來(lái)實(shí)現(xiàn)，并能夠單獨(dú)去按承載量考慮具體設(shè)計(jì)方案。非常利于剝離出具體游戲項(xiàng)目來(lái)開(kāi)發(fā)并優(yōu)化。

最終，我們或許需要的一套 C 庫(kù)，用于游戲網(wǎng)絡(luò)內(nèi)的通訊。api 可以和 socket api 類(lèi)似。額外多兩條接入與離開(kāi)游戲網(wǎng)絡(luò)即可。