轉至：http://jiangwen2011.blog.163.com/blog/static/194801340201181104532377/

摘要: 本文作為游戲服務器端開發的基本大綱，是游戲實踐開發中的總結。第一部分專業基礎，用于指導招聘和實習考核， 第二部分游戲入門，講述游戲服務器端開發的基本要點，第三部分服務端架構，介紹架構設計中的一些基本原則。希望能幫到大家

一 專業基礎

1.1 網絡

1.1.1 理解TCP/IP協議

網絡傳輸模型

滑動窗口技術

建立連接的三次握手與斷開連接的四次握手

連接建立與斷開過程中的各種狀態

TCP/IP協議的傳輸效率

思考

1）請解釋DOS攻擊與DRDOS攻擊的基本原理

2）一個100Byte數據包，精簡到50Byte, 其傳輸效率提高了50%

3）TIMEWAIT狀態怎么解釋？

1.1.2 掌握常用的網絡通信模型

Select

Epoll，邊緣觸發與平臺出發點區別與應用

Select與Epoll的區別及應用

1.2 存儲

計算機系統存儲體系

程序運行時的內存結構

計算機文件系統，頁表結構

內存池與對象池的實現原理，應用場景與區別

關系數據庫MySQL的使用

共享內存

1.3 程序

對C/C++語言有較深的理解

深刻理解接口，封裝與多態，并且有實踐經驗

深刻理解常用的數據結構：數組，鏈表，二叉樹，哈希表

熟悉常用的算法及相關復雜度：冒泡排序，快速排序

二 游戲開發入門

2.1防御式編程

不要相信客戶端數據，一定要檢驗。作為服務器端你無法確定你的客戶端是誰，你也不能假定它是善意的，請做好自我保護。(這是判斷一個服務器端程序員是否入門的基本標準)

務必對于函數的傳人參數和返回值進行合法性判斷，內部子系統，功能模塊之間不要太過信任，要求低耦合，高內聚

插件式的模塊設計，模塊功能的健壯性應該是內建的，盡量減少模塊間耦合

2.2 設計模式

道法自然。不要迷信，迷戀設計模式，更不要生搬硬套

簡化，簡化，再簡化，用最簡單的辦法解決問題

借大寶一句話：設計本天成，妙手偶得之

2.3 網絡模型

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

開源框架: Libevent, libev, ACE

2.4 數據持久化

自定義文件存儲，如《夢幻西游》

關系數據庫: MySQL

NO-SQL數據庫: MongoDB

選擇存儲系統要考慮到因素：穩定性，性能，可擴展性
2.5 內存管理

使用內存池和對象池，禁止運行期間動態分配內存

對于輸入輸出的指針參數，嚴格檢查，寧濫勿缺

寫內存保護。使用帶內存保護的函數(strncpy, memcpy, snprintf, vsnprintf等)，嚴防數組下標越界

防止讀內存溢出，確保字符串以’\0’結束

2.6 日志系統

簡單高效，大量日志操作不應該影響程序性能

穩定，做到服務器崩潰是日志不丟失

完備，玩家關鍵操作一定要記日志，理想的情況是通過日志能重建任何時刻的玩家數據

開關，開發日志的要加級別開關控制

2.7 通信協議

采用PDL(Protocol Design Language)， 如Protobuf，可以同時生成前后端代碼，減少前后端協議聯調成本， 擴展性好

JSON，文本協議，簡單，自解釋，無聯調成本，擴展性好，也很方便進行包過濾以及寫日志

自定義二進制協議，精簡，有高效的傳輸性能，完全可控，幾乎無擴展性

2.8 全局唯一Key（GUID）

為合服做準備

方便追蹤道具，裝備流向

每個角色，裝備，道具都應對應有全局唯一Key

2.9 多線程與同步

消息隊列進行同步化處理

2.10 狀態機

強化角色的狀態

前置狀態的檢查校驗

2.11 數據包操作

合并, 同一幀內的數據包進行合并，減少IO操作次數

單副本, 用一個包盡量只保存一份，減少內存復制次數

AOI同步中減少中間過程無用數據包

2.12 狀態監控

隨時監控服務器內部狀態

內存池，對象池使用情況

幀處理時間

網絡IO

包處理性能

各種業務邏輯的處理次數

2.13 包頻率控制

基于每個玩家每條協議的包頻率控制，癱瘓變速齒輪

2.14 開關控制

每個模塊都有開關，可以緊急關閉任何出問題的功能模塊

2.15 反外掛反作弊

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

包id自增校驗，可以消滅WPE

包校驗碼可以消滅包攔截篡改

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

魔高一尺，道高一丈

2.16 熱更新

核心配置邏輯的熱更新，如防沉迷系統，包頻率控制，開關控制等

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

2.17 防刷

關鍵系統資源（如元寶，精力值，道具，裝備等）的產出記日志

資源的產出和消耗盡量依賴兩個或以上的獨立條件的檢測

嚴格檢查各項操作的前置條件

校驗參數合法性

2.18 防崩潰

系統底層與具體業務邏輯無關，可以用大量的機器人壓力測試暴露各種bug，確保穩定

業務邏輯建議使用腳本

系統性的保證游戲不會崩潰

2.19 性能優化

IO操作異步化

IO操作合并緩寫 （事務性的提交db操作，包合并，文件日志緩寫）

Cache機制

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

減少內存復制

自己測試，用數據說話，別猜

2.20 運營支持

接口支持：實時查詢，控制指令，數據監控，客服處理等

實現考慮提供Http接口

2.21 容災與故障預案

略

三 服務器端架構

3.1 什么是好的架構？

滿足業務要求

能迅速的實現策劃需求，響應需求變更

系統級的穩定性保障

簡化開發。將復雜性控制在架構底層，降低對開發人員的技術要求，邏輯開發不依賴于開發人員本身強大的技術實力，提高開發效率

完善的運營支撐體系

3.2 架構實踐的思考

簡單，滿足需求的架構就是好架構

設計性能，抓住重要的20%， 沒必要從程序代碼里面去摳性能

熱更新是必須的

人難免會犯錯，盡可能的用一套機制去保障邏輯的健壯性

總結

以上是生活随笔為你收集整理的游戏服务器端开发要点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。