原文地址：http://blog.csdn.net/itcombox/article/details/51445319
摘要：
MMO游戏服务器引擎设计工程总纲(一)
MMO游戏服务器引擎网络通信(二)
MMO游戏服务器引擎数据层集群(三)
MMO游戏服务器引擎设计工程总纲(一)
一、 网络游戏开发的基本流程
◆ 项目文档
◆ 开发的进行和文档准备流程
◆ 技术人员文档
二、 MMO游戏架构
◆ MMO游戏特点
◆ MMO架构的特有内容
三、 策划文档
◆ 考虑示例游戏的题材
◆ 详细设计文档
◆ MMO庞大的游戏设定
◆ 5种设计文档
系统的基本结构图
进程关系图
资源评估文档
协议定义文档
数据库设计图
◆ 设计上的重要判断
四、 系统基本结构图
◆ 系统基本结构图的基础
◆ 服务器必须具有可扩展性 ---- 商业模式的确认
◆ 各瓶颈 ---- 扩展方式的选择
◆ MMO客户端特有的渲染性能瓶颈
◆ 解决服务器/数据库的瓶颈
空间分割法
实例法
平行世界方式
◆ 一台服务器负责整个游戏世界(什么都不做)
◆ 服务器的空间分割法 ---- 解决服务器的瓶颈
◆ 实例法 ---- 解决服务器的瓶颈
◆ 平行世界方式 ---- 解决数据库瓶颈
1、 同时采用平行世界和空间分割法
2、 同时采用空间分割、平行世界、实例法
◆ 同时采用多种方法 ---- 大量玩家在线时的数据
◆ 各种方式的引入难度
◆ 各个世界中数据库服务器的绝对性能提高
◆ K-Online的设计估算---- 首先从同时在线开始
◆ 据游戏逻辑的处理成本估算
◆ 据游戏数据库的处理负荷估算 ---- 角色数据的保存频率和数据库负荷的关系
◆ 可扩展性的最低讨论结果及进一步的用户体验追求
◆ 服务器的基本结构
五、 进程关系图
◆ 服务器连接的结构 ---- 只用空间分割法/使用平行世界方式和空间分割法
proxy与gmsv的关系是据gmsv处理逻辑的性能瓶颈和proxy连接数量瓶颈决定的m:n关系
(1) 只是用空间分割法；
蓝色是使用现有的服务器、黑色需要独立制作、准备
(2)同时使用平行世界和空间分割法
图 5-1-2-1 同时使用平行世界和空间分割法
使用平行世界方式进行扩展的关键是将dbsv分为dbsv1、dbsv2、dbsv3这样的多个数据库服务器，从而线性的提高存储游戏数据时的写入性能。
● authsv是共通的
● 分为5个平行世界，1个平行世界允许同时连接6000名玩家，总共允许3W玩家同时访问游戏
● 1个平行世界分为8个区(8核，8个进程)
● 1个平行世界准备360个实例(16核, 16个进程)
● 玩家继续增加的情况下，追加平行世界
图 5-1-2-1中，各个服务器的分布情况：
① 尽量使得authsv进程并行化
② 各个世界中,worldsv为1个进程，gmsv中地区用到8个进程， 实例用到16个进程，不能动态增减。
③ proxy与gmsv的个数相同
④ dbsv、MySQL、备份用的MySql每个世界1套
⑤ msgsv是所有世界共用的，尽量并行化，实际的进程数据要根据之后的基准测试来决定
⑥ logsv是所有世界共用的，只要1个进程，生成多少日志要在开发中决定
进程所需的服务器资源
|
进程 |
CPU(内核) |
备注 |
|
RAM |
||
|
存储器 |
||
|
TCP会话数 |
||
|
Gmsv |
W * (8 + 16) |
K-Online中的世界数据都是二维的，故数据量没那么大，内存每个内核1G就够，CPU成为性能瓶颈可能性高 |
|
上述 * 1G |
||
|
不需要 |
||
|
3+ |
||
|
Loginsv |
W * 1 |
通信缓存部分的内存，实际上loginsv很少成为瓶颈 |
|
上述 * 500M |
||
|
不需要 |
||
|
2+ |
||
|
Dbsv |
W * 1 |
通信缓存部分的内存，dbsv中的Mysql大多会成为瓶颈 |
|
上述 * 500M |
||
|
不需要 |
||
|
(8 + 16)+ |
||
|
Proxy |
W * (8 + 16) |
通信缓存部分是十分必要的，关键是TCP/IP的QPS性能可达到多少，但1个proxy只为1个gmsv，就不会成为瓶颈 |
|
上述 * 500M |
||
|
不需要 |
||
|
500+ |
||
|
Msgsv |
W * 2 |
对玩家的在线状况进行管理，防止二次登录，内存和CPU都可能以外的成为瓶颈，beta测试前要进行基准测试 |
|
上述 * 2G |
||
|
不需要 |
||
|
3+ |
||
|
Worldsv |
W * 1 |
因必须一定程度上把握各个gmsv的玩家状态，经常增加排序和搜索处理，故CPU和内存都容易成为瓶颈 |
|
上述 * 2G |
||
|
不需要 |
||
|
(8+16)+ |
||
|
Commondbsv |
1 |
平行世界方式下，进行与世界无关的持久化处理；存储设备更多地使用后端的Mysql，Mysql可能成为瓶颈 |
|
上述 * 500M |
||
|
不需要 |
||
|
W |
||
|
Authsv |
W * 1 |
只具有结算公司网关的功能，通信缓存部分的内存即可，authsv与结算公司间的线路延迟时，会成为瓶颈 |
|
上述 * 500M |
||
|
不需要 |
||
|
2+ |
|
Logsv |
1 |
不考虑日志存储量瓶颈，若gmsv等前端服务器突然发送大量日志，网络QPS会成为瓶颈 |
|
1G |
||
|
10T |
||
|
(10 + W * 30)+ |
||
|
Mysql |
W * 2 |
|
|
内核数 * 8G |
||
|
W * 100G |
||
|
1+ |
资源估算分为两大类型：CPU为中心的服务器、存储为中心的服务器
■ CPU为中心的服务器：
CPU较快，内核较多，内存一般，存储量少，容错性低，一次性的
■ 存储为中心的服务器：
CPU一般，内核一般，内存高，存储量大，容错性高，使用长期
◆ 使用平行世界方式进行扩展的关键
六、 资源估算文档
◆ 以进程列表为基础估算服务器资源
◆ 分别以CPU、存储为中心的服务器
◆ 服务器资源估算 ---- 成本估算
七、 协议文档
◆ 协议的基本性质
C/SMMO中，TCP的基础上构建专用的协议，协议的基本性质：
■ 哪些作为Server，哪些作为Client
■ 长连接还是短链接，取决于是否需强连网进行频繁的网络消息发送
■ 与服务器端间的会话是否是有状态的，是否要进行管理各个会话(例如：定期统计在线玩家人数，可做在Client与Server的连接之间)
■ 是否管理认证时的状态
■ Client与Server之间的，Server与Server之间的m :n关系，取决于硬件系统和软件系统设计及处理的性能瓶颈的关系，例如：通常，一个Proxy远远满足于一个GameServer的处理性能需求
■ 是否需要服务器的主动推送(Push)
■ 连接中断时，是否需要立即结束服务
进程种类：
■ 客户端 cli
■ 逻辑服务器 gmsv
■ 登录服务器 loginsv
■ 消息服务器 msgsv
■ 数据库服务器 dbsv
■ 逆向代理服务器 proxy
■ 世界服务器 worldsv
■ 全体公用服务器 commondbsv
■ 收费认证服务器 authsv
■ 日志服务器 logsv
■ DBMS
■ 结算公司服务器 paysv
表7-1 进程间的关系
|
cli |
gmsv |
loginsv |
msgsv |
dbsv |
worldsv |
com-dbsv |
authsv |
logsv |
DBMS |
paysv |
|
|
cli |
● |
● |
● |
||||||||
|
gmsv |
● |
● |
● |
● |
|||||||
|
loginsv |
● |
● |
● |
● |
● |
||||||
|
msgsv |
● |
● |
● |
● |
|||||||
|
dbsv |
● |
● |
|||||||||
|
worldsv |
● |
||||||||||
|
com-dbsv |
● |
||||||||||
|
authsv |
● |
● |
|||||||||
|
logsv |
|||||||||||
|
DBMS |
|||||||||||
|
paysv |
协议性质划分原则：连到谁，就叫谁
■ gmsv协议
■ loginsv协议
■ msgsv协议
■ dbsv协议(gmsv、loginsv、msgsv都连接dbsv，就叫dbsv协议)
■ worldsv协议(gmsv、loginsv、msgsv都连接worldsv，就叫worldsv协议)
■ com-dbsv协议(gmsv、loginsv、msgsv都连接com-dbsv，就叫com-dbsv协议)
■ authsv协议
■ logsv协议(gmsv、loginsv、msgsv、dbsv、worldsv、com-dbsv、authsv)
表7-2 协议基本性质关系
|
Cli ① |
gmsv |
loginsv |
msgsv |
dbsv |
worldsv |
com-dbsv |
authsv |
logsv |
DBMS |
paysv |
||
|
Cli |
state n:1 push |
每次连接n:1 |
stateful n:1 push harmful |
② |
||||||||
|
Gmsv |
n:1 |
n:1 |
n:1 |
n:1 harmful |
||||||||
|
loginsv |
n:1 |
n:1 |
n:1 |
n:1 |
n:1 harmful |
|||||||
|
msgsv |
n:1 |
n:1 |
n:1 |
n:1 harmful |
||||||||
|
Dbsv |
③ |
n:1 harmful |
1:1 |
|||||||||
|
worldsv |
n:1 harmful |
|||||||||||
|
com-dbsv |
③ |
n:1 harmful |
1:1 |
|||||||||
|
authsv |
n:1 harmful |
n:1 |
||||||||||
|
logsv |
||||||||||||
|
DBMS |
||||||||||||
|
paysv |
state/stateful:需要服务器端管理各个会话的状态
push:需推送信息
harmful:连接中断时，不需要立即结束服务
表7-2各服务连接中断时，是否需要立即结束服务
① cli连接gmsv，连接中断时，MMO中是需要立即停止游戏的；但msgsv是聊天服务器，若出问题，游戏还是可以继续进行的，不需立即关闭客户端
② 各服务器间的连接，若前端服务器与后端服务器的连接中断或超时的情况下，前端服务器则停止运行。特别是dbsv异常的情况下，无法保存数据，若还是运行游戏，则产生与存储数据的不一致，这情况得避免，没有等待几秒重连的空闲
③ DBMS,authsv都是低频访问的服务器，则dbsv、authsv都得停止，而引起其余服务器都得停止
协议设计的基本原则：
■ 与后端服务器通信时，尽可能无状态；是可做到对于所有后端服务器无状态的
■ MMO系统，战斗、聊天服务器通常采用常连接，亦有使用到短链的场景
◆ 协议的API规范(概要)
协议的实现原则：
■ 后端Server实现基本的、通用的功能，前端Server实现专用功能，降低系统的修改成本，提高开发效率。但若在各自的进程中实现各项功能，即使发生内存访问冲突时，也能防止包含相关功能的部分同时崩溃，Google Chrome采用的多进程就是出于这种考虑
■ 前端Server依赖于后端Server结构，位于后端的Server先启动，前端Server后启动
■ 协议是无状态和简单操作的集合,C/S MMO中，复杂处理集中在gmsv，可将有状态的协议限制在client与gmsv之间，除了gmsv协议，若有其他协议需要有状态，一般都是不合理的设计
■ 尽量在一个地方接受外部的异常情况，数据的持久化在一个地方进行，易于维护
■ 优秀的API的调用时序：最上最优
● 不调用API，即不需要；能做到不调用其他接口最好
● 只调用没有返回值的API的单向时序图(图7-3)
● 只调用一次然后获取返回值的呈三角状的时序图(图7-4)
● 呈锯齿状的时序图(图7-5)
gmsv采用比线程更轻量级的回调和任务系统实现异步编程，当C/S MMO中出现“锯齿状时序图”时就需要对其必要性重新加以讨论；在处理互斥机制的部分时，采用“三角状时序图”或“线状时序图”来实现
图7-3 单向时序图
图7-3 三角状时序图
图7-4 锯齿状时序图
■ 是否有必要Push
◆ 协议的API规范(详细)
◆ 网络数据包格式
八、 数据库设计
◆ 数据库设计图
◆ 编码前的重要的表的设计
◆ K-Online所需的表
◆ 数据库性能测试
九、 C/S + 中间件
◆ 网络游戏的中间件
◆ MMO的基础支持单元
十、 开发中的基本原则
◆ 编程之始，编程之续
◆ 数据结构优先原则
◆ 实现数据结构之前的讨论
◆ 维持可玩的状态的原则
◆ 后端服务器的延后原则
◆ 持续测定的原则
GThinkServerEngine
Server_Gate
◆ complie : 编译和生成protobuf协议相关及.C文件
◆ config_server : 服务器配置
◆ console_mgr : 输入管理
◆ logger : 日志模块
◆ utility_game : 服务器ID相关函数
◆ globals : 全局接口、common库头文件，服务器状态
◆ service_mgr : 服务管理
◆ service_client : 面向客户端的服务
◆ service_login : 登陆验证的服务(应考虑独立出来)
◆ service_game : 面向游戏逻辑服的服务
◆ handle_service_client : 处理客户端的网络消息
◆ handle_service_login : 处理登陆的网络消息
◆ handle_service_game : 处理逻辑服的网络消息
◆ handle_server_performance : 处理qps等性能提升
Server_Game
◆ complie : 编译和生成protobuf协议相关及.C文件
◆ config_server : 服务器配置
◆ console_mgr : 输入管理
◆ logger : 日志模块
◆ utility_game : 服务器ID相关函数
◆ globals : common库头文件和全局的接口
◆ server_pool : 服务器Socket连接池
◆ suffix_trie : 敏感词过滤、后缀树
◆ json_help : json格式转换
◆ user_data : 玩家所有基类数据节点
◆ user_extend : 玩家数据节点扩展
◆ csv_storage : .csv配置文件的打开关闭、读写操作
◆ mail_template : 邮件模版
◆ client_layer : 验证客户端网络包的合法性及会话状态是否建立
◆ client_message_object : 解析客户端消息Object的相关操作：解包[获取msgID、获取msgData + len、获取client session info]、打包，encode + 加密 [rspData]
◆ client_session : 客户端会话的定义和操作，包含客户端的上下线信息及定时扫描
◆ client_session_mgr : 客户端会话管理，使用循环队列管理会话信息
◆ message_listen : 消息监听
◆ notify_system : 游戏内的服务器主动推送系统
◆ oss : 运营日志
◆ rpc_call_db : rpc调用数据库
◆ service_game : 面向server_gate服务器的连接等管理
◆ service_game_handler : 处理客户端的网络消息
◆ service_login : 登录流程的验证服务
◆ service_mgr : 逻辑服务器本身的网络和服务的管理，例如，服务的创建、网络的状态
◆ service_tool : 逻辑服务器要管理提供的服务的工具，针对其网络层和服务状态
◆ user_finger : 逻辑服务器中的金手指功能
◆ base_object/
游戏节点数据缓存机制：
game_object ---> CMemObject : 内存对象类
game_object ---> CGameObject : 游戏节点类
game_object ---> CGameObjectT : 游戏节点模版类
game_objectsT ---> CGameObjectsT : 游戏节点模版s类1，重载
game_objects2T ---> CGameObjects2T : 游戏节点模版s类2，重载
rich_user ---> CRichUser : 游戏玩家类，包含玩家所有基类节点的增删查改等操作；玩家所有基类数据节点放在user_data中
rich_user ---> IUser : 玩家的功能接口
注意：基类Set和Get的接口，仅限于到下一层的信息，接口层次统一，其他具体获取可放具体模块逻辑中。
IGameObject:声明CGameObject、CRichUser
IGameObject---> IGameObject : virtualvoid Release( ) = 0;
IGameObject---> IGameObjectBuilder :
■ virtualCGameObject* BuildObject(pb_common::xxxInfo& info ) = 0;
GameObjectBuilder ---> CGameObjectBuilder:声明玩家所有基类节点CBasexxx，
提供生成和获取GameObject的Builder接口；
■ static IGameObjectBuilder*Builder(){return m_builer;}
■ static voidBuilder(IGameObjectBuilder* builder){m_builder =builder;}
■ 数据成员：
IGameObjectBuilder* m_builder;
游戏基类数据节点：
user_data ---> CUserData : 存放玩家所有基类节点数据
rich_user ---> CRichUser : 包含玩家所有基类节点的操作(对应client_rich_user)
base_users ---> CBaseUsers : 声明了CUserData、CRichUser；提供的接口：
■ void Load() : 玩家数据加载
■ void Save() : 玩家数据保存
■ bool SafeUpdate() : 安全更新玩家数据
■ bool SynUserData() : 同步玩家数据
■ void EnumUser() : 遍历玩家数据
■ 数据成员 :
pb_common::DataCtrl m_ctrl;
map<USERID, RichUserSPtr> m_users;
base_user_mgrT --->CBaseUserMgrT : 按标志Flag加载玩家数据节点及更新玩家数据
base_role --->CBaseRole
base_army_tech --->CBaseArmyTech
base_army_tech --->CBaseArmyTechs
base_bag_item --->CBaseBagItem
base_bag_items --->CBaseBagItems
base_battle --->CBaseBattle
base_enemy --->CBaseEnemy
base_enemys --->CBaseEnemys
base_friend --->CBaseFriend
base_friends --->CBaseFriends
base_manor --->CBaseManor
base_plant --->CBasePlant
base_plants --->CBasePlants
base_quest --->CBaseQuest
base_quests --->CBaseQuests
base_suit --->CBaseSuit
base_suits --->CBaseSuits
等都是挂载在User节点下的，而User的做法是将数据放在CUserData类中，将数据的操作放在CRichUser类中
最终，玩家所有节点数据派生为以GameObject为父类的子类，并且以模版类GameObjectsT和GameObjects2T的形式存储在内存中，提供GameServer全局的数据访问和修改的接口IGameObject。
节点数据生命周期中的轨迹图：
◆ codec : 网络层数据设计：数据包格式、解包和打包方式、加解密方式等
网络包消息格式定义：
--------4--------8--------12-------16------20-------24--------28
| | | | | | |
|- MsgHead -| userid |- TokenBlob -| EncodeBlob|
|- MsgHeadClientRequest -|
MsgHeadClientRequest -- MsgHead - hdr_len4Byte
| |
| - hdr_msg 2Byte
-- session 4Byte
|
-- userid 4Byte
|
-- TokenBlob - org_len4Byte
| |
| - mode 1Byte
-- EncodeBlob - checksum4Byte
|
- reqid 8Byte
--------4---------8--------12-------16
| | | | | |
|- MsgHead -| |EncodeBlob |
|- MsgHeadClientResponse -|
hdr_len 4Byte
hdr_msg 2Byte
result 2Byte
ogr_len 4Byte
mode 1Byte
◆ client_object/
client_game_object_builder--->CClientGameObjectBuilder
client_user_mgr --->CClientUserMgr
client_users --->CClientUsers
client_army_tech --->CClientArmyTech
client_army_techs --->CClientArmyTechs
client_bag_item --->CClientBagItem
client_bag_items --->CClientBagItems
client_battle --->CClientBattle
client_enemy --->CClientEnemy
client_enemys --->CClientEnemys
client_friend --->CClientFriend
client_friends --->CClientFriends
client_manor --->CClientManor
client_plant --->CClientPlant
client_plants --->CClientPlants
client_quest --->CClientQuest
client_quests --->CClientQuests
client_rich_user --->CClientRichUser
client_role --->CClientRole
client_suit --->CClientSuit
client_suits --->CClientSuits
Server_Redis_Cluster
Server_Redis_To_DB===>???(有没有更好的方法)
Server_Db_Cluster
Server_Common_DB ===>???(必要性)
Server_Login
Server_Auth
Server_Fight
Server_World
Server_Log
未完待续！待完善！