摘要: 本文作爲遊戲服務器端開發的基本大綱,是遊戲實踐開發中的總結。第一部分專業基礎,用於指導招聘和實習考覈, 第二部分遊戲入門,講述遊戲服務器端開發的基本要點,第三部分服務端架構,介紹架構設計中的一些基本原則。希望能幫到大家
一 專業基礎
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 開關控制
- 每個模塊都有開關,可以緊急關閉任何出問題的功能模塊
- 包頻率控制可以消滅變速齒輪
- 包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%, 沒必要從程序代碼裏面去摳性能
- 熱更新是必須的
- 人難免會犯錯,儘可能的用一套機制去保障邏輯的健壯性