一 专业基础

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%, 没必要从程序代码里面去抠性能
  • 热更新是必须的
  • 人难免会犯错,尽可能的用一套机制去保障逻辑的健壮性

转载自网络