摘要: 本文作爲遊戲服務器端開發的基本大綱，是遊戲實踐開發中的總結。第一部分專業基礎，用於指導招聘和實習考覈， 第二部分遊戲入門，講述遊戲服務器端開發的基本要點，第三部分服務端架構，介紹架構設計中的一些基本原則。希望能幫到大家
專業基礎
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%， 沒必要從程序代碼裏面去摳性能
- 熱更新是必須的
- 人難免會犯錯，儘可能的用一套機制去保障邏輯的健壯性