uqee卧龙吟的战报总是丢,分析一下

从技术角度分析一下战报的存放

最近战报总是丢,半年内至少2次了吧?最近两天又出了问题,我余毒的那个就看不了了。所以写这个,估计一下战报的存储量多大,再考虑到备份,能否真正避免战报的丢失?

1、双线一共48区,算50个好了。
2、每区算500人(老区没这么多,新区估计和这个差不多),一共有25000人。假设R占了20%(10元党也算),那么R有0.5万人,非R有2万人。
3、每天系统自带的48个令,加上成就等,最多算60个令
4、假设R每天买40个令

那么每日有R的0.5万人*(40令+60令)+非R的2万人*60令=170万令,往多里算,200万个令,就是200万次战斗,意味着200万个战报。

现在算一下每个战报的大小。我没做过游戏设计,所以这里的结构可能和真实的差别比较大。
玩家ID,算GUID好了,char(36),NPC的ID,一种是也使用GUID,另一种是采用副本+出场顺序,如董卓势力-虎牢关之战的吕布,是副本3的21个NPC,那么可以用003-021来表示,最多7个字节。我们假设系统设计也用了GUID吧。
这是战报头,所以还要加一个唯一ID,结构如下:大小一共是36*3+8+4+4+10*4=164个字节
ID: char(36)
PlayerID: char(36)
NPCID:char(36)
时间戳:PlayTime: DateTime,算8个字节好了。
我方阵型:int,1代表鱼鳞,2代表锋矢等。最多10个阵型。
敌方阵型:int,同上。
我方1号位将领ID:int
我方2号位将领ID:int
我方3号位将领ID:int
我方4号位将领ID:int
我方5号位将领ID:int
敌方1号位将领ID:int
敌方2号位将领ID:int
敌方3号位将领ID:int
敌方4号位将领ID:int
敌方5号位将领ID:int

对于战报Details结构,每方有5人,我方1号攻击,敌方最多5人都有反应(中毒、全攻,兵力增减等),同时我方最多有5人有反应(鼓舞、天命,兵力增减等),然后敌方1号攻击,我方最多有5人有反应,敌方亦最多有5人都有反应。然后我方2号攻击,敌方2号攻击,直到我方5号攻击,敌方5号攻击,第一回合结束,目前系统规定最多有50回合。
所以,Details的记录,应该是这样:
ID: 这个和战报头的ID对应
RecordID:int,代表第几回合
RecordID2: int,代表该回合中,这10人的彼此攻击序号。1代表我方1号位,2代表敌方1号位,3代表我方2号位,直到9代表我方5号位,10代表敌方5号位
AttackType: int,代表攻击方式。如1代表普攻,2代表鼓舞,3代表天命等。
AttackType2: int,代表攻击效果。如1代表暴击,2代表反击、3代表王妹妹的无视状态等。
Play1Type: int,代表受AttackType影响下,我方1号位的状态(如士气增加)
Play1Value: int,代表受AttackType影响下,我方1号位的兵力变化,如华佗治疗,增加了3000人。
Play2Type:同上
Play2Value:同上
。。。
Play5Type:同上
Play5Value:同上
然后是NPC放的
NPC1Type:同上
NPC1Value:同上
。。。
NPC5Type:同上
NPC5Value:同上

这样,战报记录Details结构应该是这个样子,一共是25个列,每行长度为36+24*4=132个字节。
ID        RecordID        RecordID2        AttackType        AttackType2        Play1Type        Play1Value        Play2Type        Play2Value        Play3Type        Play3Value        Play4Type        Play4Value        Play5Type        Play5Value        NPC1Type        NPC1Value        NPC2Type        NPC2Value        NPC3Type        NPC3Value        NPC4Type        NPC4Value        NPC5Type        NPC5Value

每回合有10行,最多50回合,那么是500行,记录长度最多为132*500=66000字节,64K多点。
回到开头,每天有200万个战报,那么每天的战报记录长度就是战报头:164*200万+战报明细:200万*64K=1640*2000K+2000K*64K=3280MB+128000MB=131280MB,大概130GB大小。

因为战报不需要有检索的操作,即,没有这种场景:我要看12345号战报的第三回合的2号位的操作。所以,这些记录完全可以压缩起来,而文本文件的压缩率一般在80%,所以,64K的战报,压缩后大概13K(战报头不压缩,供检索用)。而所有战报的大小,就是130*20%=26GB。一年是26*365=9490GB,大概10个T。

现在硬盘贼便宜,不用上存储,只用IDE硬盘好了,一个1T的小硬盘大概400多块(算500块),一年的战报用10块硬盘就装下了,冗余一下(1个存储,加2个备份),30块硬盘足够了,一共1万5千块。

重新强调一下,因为战报的非检索需求,所以战报详细信息是以文本形式存放的,而不是放在DBMS里面,战报头可以考虑放到数据库中。

posted on 2014-07-06 10:43  40岁大叔  阅读(315)  评论(0编辑  收藏  举报

导航