zoukankan      html  css  js  c++  java
  • 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里面,战报头可以考虑放到数据库中。

  • 相关阅读:
    ASP.NET Core 中的路由约束
    专治拖延症,好方法
    虚拟机hadoop集群搭建
    python爬虫+词云图,爬取网易云音乐评论
    gp数据库运维
    kafka和springboot整合应用
    kafka配置监控和消费者测试
    集群运维ansible
    SpringBoot和微服务
    python每天定时发送短信脚本
  • 原文地址:https://www.cnblogs.com/charju/p/3826867.html
Copyright © 2011-2022 走看看