电竞数据 分发平台的架构设计
发布时间：2022-12-13 10:47:01 所属栏目：大数据 来源：
导读： 电竞大数据时代，数据对比赛的观赏性和专业性都起到了至关重要的作用。同样的，这也对电竞数据的丰富性与实时性提出了越来越高的要求。
电竞数据的丰富性从受众角度来看，可分为赛事、战队和玩家数据；从
电竞数据的丰富性从受众角度来看，可分为赛事、战队和玩家数据；从
|
电竞大数据时代，数据对比赛的观赏性和专业性都起到了至关重要的作用。同样的，这也对电竞数据的丰富性与实时性提出了越来越高的要求。 电竞数据的丰富性从受众角度来看，可分为赛事、战队和玩家数据；从游戏角度来看，维度可由英雄、战斗、道具以及技能等组成；电竞数据的实时性包括赛前两支战队的历史交战记录、赛中的实时比分、胜率预测、赛后比赛分析和英雄对比等。 因此多维度的数据支持，TB到PB级别的海量数据存储与实时分析都对底层系统的架构设计有着更高的要求，亦带来了更严峻的挑战。 项目发展初期，依照MVP理论（最小化可行产品）。系统主要有两个模块：与Slave。 模块功能如下： Slave模块功能如下： 系统上线初期运行相对稳定，各维度的数据都可快速拉取。然而随着数据量的增多，数据与系统的可维护性问题却日益突出： 吸取1.0系统的经验，在2.0架构设计（架构图如图3）中，我们从维护性、扩展性和稳定性三个方面来考虑新数据系统架构应该具备的基本特性： 例如，在数据系统中，比赛数据的以+的方式构建，因为DOTA2的是顺序增大的（数值自增量不唯一），每个前加入一致性哈希算法算出的，可以防止在分布式存储中出现单机热点的问题，提升整个存储系统的数据负载均衡能力，做到更好的分片()，保障后续的扩展性。 时间戳的使用方便我们在聚合数据时对同一个和的数据重复写入，HBase/内部有自定的GC策略，对于过期的时间戳数据会做清理，读取时取最新时间节点的数据即可。 这里大家可能会有个疑问，与HBase只能做一级索引，加上之后，是无法使用的方式批量读或者根据时间为维度进行批量查询的。在使用与HBase的过程中，二级索引需要业务上自定义。在实际场景里，我们的在处理每个比赛数据时，同时会对时间戳-构建一次索引并存入MySQL，当需要基于时间批量查询时，先查询索引表拉取的列表，再获取对应的数据列表。 在数据读写上，/HBase与MySQL也有很大的不同。一般MySQL使用查询缓存，更新时缓存会失效，另外查询缓存是依赖全局锁保护，缓存大量数据时，如果查询缓存失效，会导致表锁死。 系统解耦 上文我们提到1.0架构中使用In-的消息队列做数据传递，由于内存中队列数据没有持久化存储并与模块强耦合，节点更新或者异常Panic后会导致数据丢失，且恢复时间冗长。因此，在2.0架构中采用了第三方的消息队列作为消息总线，保障系统“上下游”节点解耦，可多次迭代更新，历史消息变得可追踪，基于云平台消息堆积也变得可视化（如图10）。 链路的稳定性 全球链路上，我们使用CDN动态加速保证访问的稳定性。同时利用多云厂商CDN做备份容灾，做到秒级切换。 在调度能力和恢复能力上，我们搭建了自己的灰度系统，将不同维度的数据请求调度到不同的数据API，减少不同维度数据请求量对系统的影响；借助灰度系统，API服务更新的风险和异常时的影响面也被有效控制。依赖云平台可用区的特性，灰度系统也能方便地实现后端API服务跨可用区，做到物理架构上的容灾。 另外it架构设计研究组大数据时代的it架构设计，为保证内部跨洋访问链路的稳定性，我们在阿里云的北美机房搭建数据代理层，利用海外专线来提升访问速度。 数据高可用性 接入分布式存储系统后，对外数据API层也根据扩展的数据维度进行拆分，由多个数据API对外提供服务，例如比赛数据和联赛赛程等数据访问量大，应该与英雄、个人及道具数据分开，防止比赛/赛事接口异常影响所有数据不可访问。 针对热点数据，内部Cache层会做定时写入缓存的操作，数据的更新也会触发Cache的重写，保障赛事期间的数据可用。 （编辑：天瑞地安资讯网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐