MMOG Log Server 概要设计.docx

1、MMOG Log Server 概要设计MMOG Log Server 概要设计拟制：Willim日期：2004-04-26审核：日期：深圳市腾讯计算机系统有限公司版权所有 不得复制文档历史修订日期修订内容协议版本修订人2004-4-26createdV0.1.0willim2004-4-29根据review 意见增加以下内容：1、 在记录道具类日志时，如果该道具与角色相关，还需要在角色类日志中再记录一次2、 GM 有专门的LOG3、 基于特定角色的所有通信消息也可以记录日志V0.1.1willim目 录1 简介 51.1 需求简述 51.2 约定 52 Log Server的系统结构 52.

2、1 Log Server 与其它Server 的逻辑结构 62.2 Log Server 的内部结构 73 游戏日志 73.1 日志文件的分类和存储 73.1.1 日志文件的分类 73.1.2 日志文件的存储 83.2 帐号信息类日志 83.2.1 帐号信息种类 83.2.2 帐号日志内容 83.3 角色类信息 93.3.1 角色动作分类 93.3.2 玩家死亡的日志信息 93.3.3 角色移动 103.3.4 打开和关闭保险箱 103.3.5 角色升级 113.3.6 攻击 113.3.7 与保险箱中的道具相关的日志 113.3.8 道具的获得、遗失和修复 123.3.9 道具的交易 123

3、.3.10 角色类日志 123.4 道具类日志 133.4.1 道具的操作种类 133.4.2 与保险箱相关的日志 133.4.3 与道具相关的日志 133.4.4 道具日志结构 143.5 日志信息 143.6 动态 trace 和分析 143.6.1 对计费信息的跟踪 153.6.2 对角色信息的跟踪 153.6.3 对道具信息的跟踪 153.6.4 更改配置消息 163.7 建议的缺省的TRACE 配置 16MMOG Log Server概要设计关键词：Log server ，日志服务器摘 要：本文是MMOG 日志服务器的概要设计，包含Log Server 逻辑结构、与其它Server

4、之间的接口消息描述和日志文件的详细描述。缩略语清单：Log Server 日志服务器 GM 游戏的管理人员1 简介1.1 需求简述1、日志服务器能记录整个game world 的重要事件，以及活跃玩家进入游戏后的活动，为游戏的运营分析提供原始数据2、可以设置和取消，对某些特定角色在某时间段的特定活动进行跟踪，以便GM 分析和判断3、日志服务器可以根据实际的运行情况，在物理上进行动态的扩展1.2 约定Game Server ：是zone server / cluster login / role server 等具体的处理帐号与角色信息的进程的集合。日志信息的主体 ：由于某对象的特定动作，而导致

5、产生本日志信息。日志信息的主体可以是一个角色或者一个NPC （包含怪物 Monster ）2 Log Server的系统结构由于角色可以在一个game world 的各个地图任意移动，而zone server 只管理特定的某些地图，所以，玩家日志信息的分布应基于该角色所属的Uin 而不是Game Server ，这样便于GM 查找和分析某一角色的相关信息。若日志信息主体是NPC ，则此类日志的分布应基于所在的 zone server 的ID 。2.1 Log Server 与其它Server 的逻辑结构说明：1、 Game Server 和Log Server 之间是单向的UDP 通信方式，允

6、许在网络拥塞和系统异常情况下，有少量的信息丢失2、 不同的Log Server 进程负责处理不同的Uin 的所有日志信息。Game Server 将Uin （也可以是zone server ID ）先HASH，再以Log Server 的总数作为因子取模，运算的结果就是处理该角色的所有日志信息的 Log Server ID 3、 各Game Server 提供TCP 的接口，接收并处理Config Server 的更改配置请求。在增加Log Server 时，Game Server 在接收到Config Server 发送的管理命令后，自动更新本地的路由表，以便向不同的Log Server 继

7、续发送日志信息4、 各Game Server 还可以接收Monitor Server 的管理命令，设置或取消产生日志的条件5、 Log Server 进程可运行于不同的物理主机，如果主机的硬件资源满足要求，也可以有多个Log Server 进程在同一物理主机上，但监听的端口不同2.2 Log Server 的内部结构说明：1、 为了减少IO ，Log Server 采用了异步的读写模式。主进程接收到各game server 的日志信息后，只将其分类写到BUFFER（在共享内存中建立的缓冲区），后续由专门的 write 功能函数（或者 多个 thread ）定时将BUFFER 中的信息刷新到物理

8、硬盘上2、 如果采用多 thread 的方式，主进程在BUFFER 达到一定程度时向thread 发送信号，由后者对BUFFER 进行处理；或者，thread 每隔 N 秒主动处理一次BUFFER。考虑到并发的情况，在thread 处理过程中，主进程在写入某一类的BUFFER 时可能需要等待一段很短时间，若超过了等待时间，主进程将当前的那一条日志消息另存其它文件。3 游戏日志3.1 日志文件的分类和存储3.1.1 日志文件的分类日志文件可分为以下几类：1、BILLING：与计费相关，包含帐号的login / logout / billing 2、PLAYER：与角色数据相关，包含角色login

9、 / logout / new / delete / update character 3、ITEM ：与道具相关，包含获得、丢弃、交易、合成等4、CLAN：与行会相关，包含行会的创建/加入/解散/授权5、TALK：角色所讲的话，包含私聊/在频道里的说话 6、 GM ：GM 的所有活动enum LogType BILLING ,PLAYER ,ITEM ,CLAN ,TALK，GM ;3.1.2 日志文件的存储PLAYER 、ITEM和TALK 类信息量巨大，写入日志文件时，需根据文件大小存储到不同文件上（如大于2M 则另存一新文件），以便查找。而BILLING 、CLAN 和GM 类日志，则

10、可以根据时间段进行划分，如每小时一个文件。日志文件的内容是二进制格式，每一条日志信息前都有该记录的长度，必须通过特定的工具来查看日志文件的内容。日志文件名为：LogType.yyyymmdd.hhmm ，LogType 表示此文件记载的日志的种类，yyyymmdd.hhmm 表示该文件的创建时间。每天一个目录，存放当天的所有日志文件。CLAN 和TALK 在目前版本暂不支持，以下描述只涉及BILLING 、PLAYER 和ITEM 部分内容。3.2 帐号信息类日志3.2.1 帐号信息种类enum Billing login , /* 帐号LOGIN */logout, /* 帐号LOGOUT

11、*/billing /* 中间计费报告 */ ;3.2.2 帐号日志内容typedef struct char m_szRoleName32; /* 角色名 */long m_lIp ; /* login 的IP （CLIENT） */int m_iWorldId ; /* 登陆的world ID */char m_cChargeType ; /* 该帐号的计费类型：包月/点卡*/int m_iConsumed ; /* 消耗点数（时间） */ BillingDetail ;帐号日志信息：typedef struct Billing m_eType ;BillingDetail m_stDet

12、ail ; BillingLog ;3.3 角色类信息3.3.1 角色动作分类enum PlayerAction login , /*角色登陆*/logout, /*角色退出*/new, /*创建角色*/delete, /*删除角色*/levelup, /*角色升级*/move, /*移动*/attack, /*攻击*/kill, /*杀死 MONSTER 或其它角色 */ character, /*基本属性更改*/stash, /*打开/关闭保险箱*/stash_get, /*从保险箱取出道具 */stash_put, /*放道具进保险箱 */pickup, /*获得物品 ，如完成任务或杀死

13、MONSTER后获得*/lose , /*道具丢失 ，如角色被杀死而遗失 */discard, /*丢弃物品 */repair, /*修复物品 */disappear, /*道具消失，如合成失败 */trade, /*道具（包含金钱）的买卖与交换 */comm. /*角色的所有通信数据 */ ;3.3.2 玩家死亡的日志信息typedef struct char m_szKiller32; /* 杀人者角色名或怪物名*/short m_nKillerLevel ; /* 杀人者的级别 */char m_cKilledType ; /* 被杀者的类型：0 怪物 ， 1 角色 */char m_s

14、zKilled32; /* 被杀者名字 */short m_nKilledLevel ; /* 被杀者级别 */int m_iZoneId ; /* 杀人者所在的 Zone Server 编号 */int m_iMap ; /* 事件发生的所在地点 */int m_iPosX ;int m_iPosY ;int m_iPosZ ; KillDetail ;本结构适合于 kill 类型。杀人者是NPC 时，其Uin 为该zone server 的ID 。若是角色之间的攻击，将分别记录2 条日志：杀人方与被杀方。如果被杀者是 NPC ，只需要一条杀人者的记录3.3.3 角色移动typedef st

15、ruct char m_szRoleName32; /* 角色名*/int m_iZoneId ; /* 原zone server ID */int m_iMap ; /* 原始地点 */int m_iPosX ;int m_iPosY ;int m_iPosZ ;int m_iZoneId ; /* 新zone server ID */int m_iMap ; /* 目标地点 */int m_iPosX ;int m_iPosY ;int m_iPosZ ;unsigned char m_szItemId8 ; /*所使用道具的ID ，如飞空艇，移动卷等*/Move ;本结构适合于 move

16、 类型。3.3.4 打开和关闭保险箱tyoedef struct char m_szRoleName32; /* 角色名*/char m_cOperation ; /* 0 打开保险箱 ， 1 关闭保险箱 */int m_iZoneId ; /* zone server ID */int m_iMap ; /* 地点 */int m_iPosX ;int m_iPosY ;int m_iPosZ ;char m_szStashName32 ; Stash ;本结构适合于 stash 类型。 3.3.5 角色升级typedef struct char m_szRoleName32; /* 角色名

17、*/short m_nLevel ;int m_iLevelupTime ; /* 从上一次升级到这次升级所需要的游戏时间 */ LevelUp ;本结构适合于 levelup 类型。角色在每次登陆时，先从角色DB server获得当前级别已花费的游戏时间，本次升级后，需将其清 0 。设计本日志信息的目的是统计玩家的升级模型。3.3.6 攻击typedef struct char m_szAttacker32; /* 攻击者名*/char m_szSkillDetail64 ; /* 包含了技能的名称和属性等详细信息 */char m_szAttacked32; /* 被攻击者 */ Atta

18、ck ;本结构适合于 attack 类型。攻击者是NPC 时，其Uin 为给zone server 的ID 。若是角色之间的攻击，一次动作将分别记录2 条日志：攻击方与被攻击方。如果被攻击者是 NPC ，只需要一条攻击者的记录。3.3.7 与保险箱中的道具相关的日志tyoedef struct char m_szRoleName32; /* 角色名*/char m_szStashName32 ;unsigned char m_szCharacter64 ; /* 道具的属性，已包含道具的INDEX、唯一ID等属性 , 请参见C/S 之间的道具的具体定义。下同*/int m_iQuantity

19、; /* 道具的数量 */long m_lMoney ; /* 所涉及的金钱 */ StashOperation ;本结构适合于 stash_get 和stash_put 类型。3.3.8 道具的获得、遗失和修复typedef struct char m_szRoleName32; /* 角色名*/unsigned char m_szChar164 ; /* 道具的原始属性*/unsigned char m_szChar264 ; /* 道具的变化后属性 ， 如果操作类型是 repair 时才有意义*/int m_iQuantity ; /* 道具的数量 */long m_lMoney ; /

20、* 所涉及的金钱 */ PlayerItem ;本结构适合于 pickup、lose、discard 、repair 和disappear 类型。3.3.9 道具的交换与买卖typedef struct char m_szObject132; /* 甲方 ，可以是角色或者NPC */char m_szObject232; /* 乙方，可以是角色或者NPC */unsigned char m_szChar164 ; /* 道具的属性*/int m_iQuantity ; /* 道具的数量 */long m_lMoney ; /* 所涉及的金钱 */ ItemTrade;本结构适合于trade 类

21、型。如果任一方是NPC ，则其Uin 是zone server 的ID 。除了记录基于交易双方的日志信息外，还需要产生相关的道具类日志。3.3.10 角色类日志内容日志的具体内容是一个联合体：union PlayerDetail BasicUpdate m_stBasic ; /* 不经常更新的基本信息 */ActiveUpdate m_stActive ; /* 经常更新的基本信息 ，请参见MMOG DATABASE SERVER 消息接口协议 */KillDetail m_stKillDetail ; /* 杀与被杀 */Move m_stMove ; /* 移动 */LevelUp m_

22、stLevelup ; /* 升级 */Attack m_stAttack ; /* 攻击过程 */Stash m_stStash ; /* 打开与关闭保险箱 */StashOperation m_stStashOp ; /* 保险箱操作 */PlayerItem m_stPlayerItem ; /* 玩家的道具 */ItemTrade m_stItemTrade ; /* 交易类 */unsigned char m_szPackageMAX_PACKAGE_LEN ; /*通信包 */ ;typedef struct enum PlayerAction m_eType ;union Pla

23、yerDetail m_Detail ; PlayerLog ;3.4 道具类日志3.4.1 道具的操作种类enum ItemType compose , /*合成之后的属性改变 */disappear , /*道具消失 ，如合成失败 */system , /*系统生成的道具 ，如完成任务、杀死 NPC 后获得*/trade , /*由于交易而获得的道具，包含向NPC 购买和角色之间的交易 */lose , /*道具丢失 ，如角色被杀死而遗失 */stash_get, /*从保险箱取出的道具 */stash_put, /*把道具放进保险箱 */super /*由GM 手工生成的道具 */ ;3

24、.4.2 与保险箱相关的日志 请参见3.3.7 节的 StashOperation 结构。3.4.3 与道具相关的日志typedef struct char m_szObject32; /* 本条日志信息的主体名字，可以是角色、NPC */unsigned char m_szChar164 ; /* 道具的原始属性*/unsigned char m_szChar264 ; /* 道具的变化后属性 ， 如果操作类型是 compose 时才有意义*/int m_iQuantity ; /* 道具的数量 */long m_lMoney ; /* 所涉及的金钱 */ Item ;若日志信息的主体是NP

25、C ，其对应的Uin 为该game server 的ID 。3.4.4 道具日志结构union ItemDetal Item m_stItem ;StashOperation m_stStash ; ;typedef struct enum ItemType m_eType ;ItemDetail m_stDetail ; ItemLog ;3.5 日志信息日志的具体内容是一个联合体：union LogDetail BillingLog m_stBillingDetail ; /*计费类日志 */PlayerLog m_stPlayerDetail ; /*角色类日志 */ItemLog m_

26、stItemDetail ; /*道具类日志 */unsigned char m_szPackageMAX_PACKAGE_LEN ; ;完整的日志信息结构：typedef struct enum LogType m_eLogType ; /* 日志种类：BILLING /PLAYER /ITEM /CLAN /TALK */long m_lUin ; /* 该日志信息主体的Uin */long m_lTime ; /* 发生时间 */union LogDetail m_LogDetail ; /* 日志内容 */ LogInfo ;3.6 动态 trace 和分析为了减少日志的内容，正常运行

27、时，Game Server 并不是针对每一件事情都记录日志的，比如角色移动、低等级道具的获得与丢弃等是不产生日志的。GM 可以通过管理终端，经由 monitor server 向某Game Server 发送设置获取取消产生日志的命令，以达到只对某些角色、特定的动作、特定的物品进行动态跟踪的目的。各Game Server 进程在自己的共享内存中，保存是否写日志的动态配置表。当每一件事件发生时，Game Server 进程都要先根据内存中的配置，与事件类型、事件的主体进行比较，满足条件后才将日志信息发送到Log Server 。Game Server 缺省情况是对所有事件都记录日志，不能修改其设

28、置。3.6.1 对计费信息的跟踪typedef struct enum Billing m_eType ;long m_lBegin ;long m_lEnd ; TraceBilling ;可以设置对m_lBegin，m_lEnd 之间的Uin 段的m_eType 类型活动，记录日志。如果eType 为 -1 则表示对所有活动都记录日志。对计费信息的设置命令，应该发送给负责计费的各实际进程 db_process 和cluster_login ，由后者在进行计费时产生日志。3.6.2 对角色信息的跟踪typedef struct enum PlayerAction m_eType ;char

29、m_szRoleName32 ; TracePlayer ;m_szRoleName 支持“*” 匹配符号，可以支持对所有满足 m_szRoleName 的 m_eType 类型的活动进行跟踪。如果 m_eType 为 -1 则表示对所有活动均记录日志。对角色类信息的设置命令，应发送给各zone server ，由后者在处理角色动作时产生日志。3.6.3 对道具信息的跟踪typedef struct enum ItemType m_eType ;short m_nItemLevel ; TraceItem ;可以设置对所涉及的道具的 level 在m_nItemLevel 以上的m_eType

30、 类型活动进行跟踪。如果 m_eType 为 -1 则表示对所有道具的操作均记录日志。对道具类信息的设置命令，应发送给各zone server ，由后者在处理道具相关操作时产生日志。3.6.4 更改配置消息typedef struct char m_cOperation ; /* 0 ：取消以前的设置并恢复到缺省配置1 ：设定对某些活动进行跟踪 */enum LogType m_eType ; /* 种类：BILLING /PLAYER /ITEM /CLAN /TALK */union TraceDetail TraceBilling m_stBilling ; /* 计费类 */TracePlayer m_stPlayer ; /* 角色类 */TraceItem m_stIt