游戏服务器端开发要点

摘要: 本文作为游戏服务器端开发的基本大纲，是游戏实践开发中的总结。第一部分专业基础，用于指导招聘和实习考核， 第二部分游戏入门，讲述游戏服务器端开发的基本要点，第三部分服务端架构，介绍架构设计中的一些基本原则。希望能帮到大家

一 专业基础

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%， 没必要从程序代码里面去抠性能

热更新是必须的

人难免会犯错，尽可能的用一套机制去保障逻辑的健壮性

原文链接