MMOG Log Server 概要设计.docx
《MMOG Log Server 概要设计.docx》由会员分享，可在线阅读，更多相关《MMOG Log Server 概要设计.docx（20页珍藏版）》请在冰豆网上搜索。
MMOGLogServer概要设计
MMOGLogServer概要设计
拟制：
Willim
日期：
2004-04-26
审核：
日期：
深圳市腾讯计算机系统有限公司
版权所有不得复制
文档历史
修订日期
修订内容
协议版本
修订人
2004-4-26
created
V0.1.0
willim
2004-4-29
根据review意见增加以下内容：
1、在记录道具类日志时，如果该道具与角色相关，还需要在角色类日志中再记录一次
2、GM有专门的LOG
3、基于特定角色的所有通信消息也可以记录日志
V0.1.1
willim
目录
1简介5
1.1需求简述5
1.2约定5
2LogServer的系统结构5
2.1LogServer与其它Server的逻辑结构6
2.2LogServer的内部结构7
3游戏日志7
3.1日志文件的分类和存储7
3.1.1日志文件的分类7
3.1.2日志文件的存储8
3.2帐号信息类日志8
3.2.1帐号信息种类8
3.2.2帐号日志内容8
3.3角色类信息9
3.3.1角色动作分类9
3.3.2玩家死亡的日志信息9
3.3.3角色移动10
3.3.4打开和关闭保险箱10
3.3.5角色升级11
3.3.6攻击11
3.3.7与保险箱中的道具相关的日志11
3.3.8道具的获得、遗失和修复12
3.3.9道具的交易12
3.3.10角色类日志12
3.4道具类日志13
3.4.1道具的操作种类13
3.4.2与保险箱相关的日志13
3.4.3与道具相关的日志13
3.4.4道具日志结构14
3.5日志信息14
3.6动态trace和分析14
3.6.1对计费信息的跟踪15
3.6.2对角色信息的跟踪15
3.6.3对道具信息的跟踪15
3.6.4更改配置消息16
3.7建议的缺省的TRACE配置16
MMOGLogServer概要设计
关键词：
Logserver，日志服务器
摘要：
本文是MMOG日志服务器的概要设计，包含LogServer逻辑结构、与其它Server之间的接口消息描述和日志文件的详细描述。
缩略语清单：
LogServer日志服务器
GM游戏的管理人员
1
简介
1.1需求简述
1、日志服务器能记录整个gameworld的重要事件，以及活跃玩家进入游戏后的活动，为游戏的运营分析提供原始数据
2、可以设置和取消，对某些特定角色在某时间段的特定活动进行跟踪，以便GM分析和判断
3、日志服务器可以根据实际的运行情况，在物理上进行动态的扩展
1.2约定
GameServer：
是zoneserver/clusterlogin/roleserver等具体的处理帐号与角色信息的进程的集合。
日志信息的主体：
由于某对象的特定动作，而导致产生本日志信息。
日志信息的主体可以是一个角色或者一个NPC（包含怪物Monster）
2LogServer的系统结构
由于角色可以在一个gameworld的各个地图任意移动，而zoneserver只管理特定的某些地图，所以，玩家日志信息的分布应基于该角色所属的Uin而不是GameServer，这样便于GM查找和分析某一角色的相关信息。
若日志信息主体是NPC，则此类日志的分布应基于所在的zoneserver的ID。
2.1LogServer与其它Server的逻辑结构
说明：
1、GameServer和LogServer之间是单向的UDP通信方式，允许在网络拥塞和系统异常情况下，有少量的信息丢失
2、不同的LogServer进程负责处理不同的Uin的所有日志信息。
GameServer将Uin（也可以是zoneserverID）先HASH，再以LogServer的总数作为因子取模，运算的结果就是处理该角色的所有日志信息的LogServerID
3、各GameServer提供TCP的接口，接收并处理ConfigServer的更改配置请求。
在增加LogServer时，GameServer在接收到ConfigServer发送的管理命令后，自动更新本地的路由表，以便向不同的LogServer继续发送日志信息
4、各GameServer还可以接收MonitorServer的管理命令，设置或取消产生日志的条件
5、LogServer进程可运行于不同的物理主机，如果主机的硬件资源满足要求，也可以有多个LogServer进程在同一物理主机上，但监听的端口不同
2.2LogServer的内部结构
说明：
1、为了减少IO，LogServer采用了异步的读写模式。
主进程接收到各gameserver的日志信息后，只将其分类写到BUFFER（在共享内存中建立的缓冲区），后续由专门的write功能函数（或者多个thread）定时将BUFFER中的信息刷新到物理硬盘上
2、如果采用多thread的方式，主进程在BUFFER达到一定程度时向thread发送信号，由后者对BUFFER进行处理；或者，thread每隔N秒主动处理一次BUFFER。
考虑到并发的情况，在thread处理过程中，主进程在写入某一类的BUFFER时可能需要等待一段很短时间，若超过了等待时间，主进程将当前的那一条日志消息另存其它文件。
3游戏日志
3.1日志文件的分类和存储
3.1.1日志文件的分类
日志文件可分为以下几类：
1、BILLING：
与计费相关，包含帐号的login/logout/billing
2、PLAYER：
与角色数据相关，包含角色login/logout/new/delete/updatecharacter
3、ITEM：
与道具相关，包含获得、丢弃、交易、合成等
4、CLAN：
与行会相关，包含行会的创建/加入/解散/授权
5、TALK：
角色所讲的话，包含私聊/在频道里的说话
6、GM：
GM的所有活动
enumLogType{
BILLING,
PLAYER,
ITEM,
CLAN,
TALK，
GM
};
3.1.2日志文件的存储
PLAYER、ITEM和TALK类信息量巨大，写入日志文件时，需根据文件大小存储到不同文件上（如大于2M则另存一新文件），以便查找。
而BILLING、CLAN和GM类日志，则可以根据时间段进行划分，如每小时一个文件。
日志文件的内容是二进制格式，每一条日志信息前都有该记录的长度，必须通过特定的工具来查看日志文件的内容。
日志文件名为：
LogType.yyyymmdd.hhmm，LogType表示此文件记载的日志的种类，yyyymmdd.hhmm表示该文件的创建时间。
每天一个目录，存放当天的所有日志文件。
CLAN和TALK在目前版本暂不支持，以下描述只涉及BILLING、PLAYER和ITEM部分内容。
3.2帐号信息类日志
3.2.1帐号信息种类
enumBilling{
login,/*帐号LOGIN*/
logout,/*帐号LOGOUT*/
billing/*中间计费报告*/
};
3.2.2帐号日志内容
typedefstruct{
charm_szRoleName[32];/*角色名*/
longm_lIp;/*login的IP（CLIENT）*/
intm_iWorldId;/*登陆的worldID*/
charm_cChargeType;/*该帐号的计费类型：
包月/点卡…*/
intm_iConsumed;/*消耗点数（时间）*/
}BillingDetail;
帐号日志信息：
typedefstruct{
Billingm_eType;
BillingDetailm_stDetail;
}BillingLog;
3.3角色类信息
3.3.1角色动作分类
enumPlayerAction{
login,/*角色登陆*/
logout,/*角色退出*/
new,/*创建角色*/
delete,/*删除角色*/
levelup,/*角色升级*/
move,/*移动*/
attack,/*攻击*/
kill,/*杀死MONSTER或其它角色*/
character,/*基本属性更改*/
stash,/*打开/关闭保险箱*/
stash_get,/*从保险箱取出道具*/
stash_put,/*放道具进保险箱*/
pickup,/*获得物品，如完成任务或杀死MONSTER后获得*/
lose,/*道具丢失，如角色被杀死而遗失*/
discard,/*丢弃物品*/
repair,/*修复物品*/
disappear,/*道具消失，如合成失败*/
trade,/*道具（包含金钱）的买卖与交换*/
comm./*角色的所有通信数据*/
};
3.3.2玩家死亡的日志信息
typedefstruct{
charm_szKiller[32];/*杀人者角色名或怪物名*/
shortm_nKillerLevel;/*杀人者的级别*/
charm_cKilledType;/*被杀者的类型：
0怪物，1角色*/
charm_szKilled[32];/*被杀者名字*/
shortm_nKilledLevel;/*被杀者级别*/
intm_iZoneId;/*杀人者所在的ZoneServer编号*/
intm_iMap;/*事件发生的所在地点*/
intm_iPosX;
intm_iPosY;
intm_iPosZ;
}KillDetail;
本结构适合于kill类型。
杀人者是NPC时，其Uin为该zoneserver的ID。
若是角色之间的攻击，将分别记录2条日志：
杀人方与被杀方。
如果被杀者是NPC，只需要一条杀人者的记录
3.3.3角色移动
typedefstruct{
charm_szRoleName[32];/*角色名*/
intm_iZoneId;/*原zoneserverID*/
intm_iMap;/*原始地点*/
intm_iPosX;
intm_iPosY;
intm_iPosZ;
intm_iZoneId;/*新zoneserverID*/
intm_iMap;/*目标地点*/
intm_iPosX;
intm_iPosY;
intm_iPosZ;
unsignedcharm_szItemId[8];/*所使用道具的ID，如飞空艇，移动卷等*/
}Move;
本结构适合于move类型。
3.3.4打开和关闭保险箱
tyoedefstruct{
charm_szRoleName[32];/*角色名*/
charm_cOperation;/*0打开保险箱，1关闭保险箱*/
intm_iZoneId;/*zoneserverID*/
intm_iMap;/*地点*/
intm_iPosX;
intm_iPosY;
intm_iPosZ;
charm_szStashName[32];
}Stash;
本结构适合于stash类型。
3.3.5角色升级
typedefstruct{
charm_szRoleName[32];/*角色名*/
shortm_nLevel;
intm_iLevelupTime;/*从上一次升级到这次升级所需要的游戏时间*/
}LevelUp;
本结构适合于levelup类型。
角色在每次登陆时，先从角色DBserver获得当前级别已花费的游戏时间，本次升级后，需将其清0。
设计本日志信息的目的是统计玩家的升级模型。
3.3.6攻击
typedefstruct{
charm_szAttacker[32];/*攻击者名*/
charm_szSkillDetail[64];/*包含了技能的名称和属性等详细信息*/
charm_szAttacked[32];/*被攻击者*/
}Attack;
本结构适合于attack类型。
攻击者是NPC时，其Uin为给zoneserver的ID。
若是角色之间的攻击，一次动作将分别记录2条日志：
攻击方与被攻击方。
如果被攻击者是NPC，只需要一条攻击者的记录。
3.3.7与保险箱中的道具相关的日志
tyoedefstruct{
charm_szRoleName[32];/*角色名*/
charm_szStashName[32];
unsignedcharm_szCharacter[64];/*道具的属性，已包含道具的INDEX、唯一ID等属性,
请参见C/S之间的道具的具体定义。
下同*/
intm_iQuantity;/*道具的数量*/
longm_lMoney;/*所涉及的金钱*/
}StashOperation;
本结构适合于stash_get和stash_put类型。
3.3.8道具的获得、遗失和修复
typedefstruct{
charm_szRoleName[32];/*角色名*/
unsignedcharm_szChar1[64];/*道具的原始属性*/
unsignedcharm_szChar2[64];/*道具的变化后属性，如果操作类型是repair时才有意义*/
intm_iQuantity;/*道具的数量*/
longm_lMoney;/*所涉及的金钱*/
}PlayerItem;
本结构适合于pickup、lose、discard、repair和disappear类型。
3.3.9道具的交换与买卖
typedefstruct{
charm_szObject1[32];/*甲方，可以是角色或者NPC*/
charm_szObject2[32];/*乙方，可以是角色或者NPC*/
unsignedcharm_szChar1[64];/*道具的属性*/
intm_iQuantity;/*道具的数量*/
longm_lMoney;/*所涉及的金钱*/
}ItemTrade;
本结构适合于trade类型。
如果任一方是NPC，则其Uin是zoneserver的ID。
除了记录基于交易双方的日志信息外，还需要产生相关的道具类日志。
3.3.10角色类日志内容
日志的具体内容是一个联合体：
unionPlayerDetail{
BasicUpdatem_stBasic;/*不经常更新的基本信息*/
ActiveUpdatem_stActive;/*经常更新的基本信息，
请参见《MMOGDATABASESERVER消息接口协议》*/
KillDetailm_stKillDetail;/*杀与被杀*/
Movem_stMove;/*移动*/
LevelUpm_stLevelup;/*升级*/
Attackm_stAttack;/*攻击过程*/
Stashm_stStash;/*打开与关闭保险箱*/
StashOperationm_stStashOp;/*保险箱操作*/
PlayerItemm_stPlayerItem;/*玩家的道具*/
ItemTradem_stItemTrade;/*交易类*/
unsignedcharm_szPackage[MAX_PACKAGE_LEN];/*通信包*/
};
typedefstruct{
enumPlayerActionm_eType;
unionPlayerDetailm_Detail;
}PlayerLog;
3.4道具类日志
3.4.1道具的操作种类
enumItemType{
compose,/*合成之后的属性改变*/
disappear,/*道具消失，如合成失败*/
system,/*系统生成的道具，如完成任务、杀死NPC后获得*/
trade,/*由于交易而获得的道具，包含向NPC购买和角色之间的交易*/
lose,/*道具丢失，如角色被杀死而遗失*/
stash_get,/*从保险箱取出的道具*/
stash_put,/*把道具放进保险箱*/
super/*由GM手工生成的道具*/
};
3.4.2与保险箱相关的日志
请参见3.3.7节的StashOperation结构。
3.4.3与道具相关的日志
typedefstruct{
charm_szObject[32];/*本条日志信息的主体名字，可以是角色、NPC*/
unsignedcharm_szChar1[64];/*道具的原始属性*/
unsignedcharm_szChar2[64];/*道具的变化后属性，如果操作类型是compose时才有意义*/
intm_iQuantity;/*道具的数量*/
longm_lMoney;/*所涉及的金钱*/
}Item;
若日志信息的主体是NPC，其对应的Uin为该gameserver的ID。
3.4.4道具日志结构
unionItemDetal{
Itemm_stItem;
StashOperationm_stStash;
};
typedefstruct{
enumItemTypem_eType;
ItemDetailm_stDetail;
}ItemLog;
3.5日志信息
日志的具体内容是一个联合体：
unionLogDetail{
BillingLogm_stBillingDetail;/*计费类日志*/
PlayerLogm_stPlayerDetail;/*角色类日志*/
ItemLogm_stItemDetail;/*道具类日志*/
unsignedcharm_szPackage[MAX_PACKAGE_LEN];
};
完整的日志信息结构：
typedefstruct{
enumLogTypem_eLogType;/*日志种类：
BILLING/PLAYER/ITEM/CLAN/TALK*/
longm_lUin;/*该日志信息主体的Uin*/
longm_lTime;/*发生时间*/
unionLogDetailm_LogDetail;/*日志内容*/
}LogInfo;
3.6动态trace和分析
为了减少日志的内容，正常运行时，GameServer并不是针对每一件事情都记录日志的，比如角色移动、低等级道具的获得与丢弃等是不产生日志的。
GM可以通过管理终端，经由monitorserver向某GameServer发送设置获取取消产生日志的命令，以达到只对某些角色、特定的动作、特定的物品进行动态跟踪的目的。
各GameServer进程在自己的共享内存中，保存是否写日志的动态配置表。
当每一件事件发生时，GameServer进程都要先根据内存中的配置，与事件类型、事件的主体进行比较，满足条件后才将日志信息发送到LogServer。
GameServer缺省情况是对所有事件都记录日志，不能修改其设置。
3.6.1对计费信息的跟踪
typedefstruct{
enumBillingm_eType;
longm_lBegin;
longm_lEnd;
}TraceBilling;
可以设置对[m_lBegin，m_lEnd]之间的Uin段的m_eType类型活动，记录日志。
如果eType为-1则表示对所有活动都记录日志。
对计费信息的设置命令，应该发送给负责计费的各实际进程db_process和cluster_login，由后者在进行计费时产生日志。
3.6.2对角色信息的跟踪
typedefstruct{
enumPlayerActionm_eType;
charm_szRoleName[32];
}TracePlayer;
m_szRoleName支持“*”匹配符号，可以支持对所有满足m_szRoleName的m_eType类型的活动进行跟踪。
如果m_eType为-1则表示对所有活动均记录日志。
对角色类信息的设置命令，应发送给各zoneserver，由后者在处理角色动作时产生日志。
3.6.3对道具信息的跟踪
typedefstruct{
enumItemTypem_eType;
shortm_nItemLevel;
}TraceItem;
可以设置对所涉及的道具的level在m_nItemLevel以上的m_eType类型活动进行跟踪。
如果m_eType为-1则表示对所有道具的操作均记录日志。
对道具类信息的设置命令，应发送给各zoneserver，由后者在处理道具相关操作时产生日志。
3.6.4更改配置消息
typedefstruct{
charm_cOperation;/*0：
取消以前的设置并恢复到缺省配置
1：
设定对某些活动进行跟踪*/
enumLogTypem_eType;/*种类：
BILLING/PLAYER/ITEM/CLAN/TALK*/
unionTraceDetail{
TraceBillingm_stBilling;/*计费类*/
TracePlayerm_stPlayer;/*角色类*/
TraceItemm_stIt
升级会员 