1.1 摘要
内存数据库适用于实时性访问要求很高的业务应用系统,尤其是实时数据直播报类系统,如篮球比赛图文直播室,足球比赛图文直播室等各类实时播放类的体育赛事。本文以NBA篮球比赛直播室后台内存数据的存储设计为业务切入点,以Memcached内存数据库为平台,详细介绍了内存数据库在实时业务应用的典型应用。
1.2 业务规则
NBA篮球比赛分为主客场两支球队,允许各队同时5名球员上场比赛,允许球员替换上场;分为上下半场,各两节,每节12分钟,全场48分钟;常规时间内比分相同则进入加时,加时赛每节5分钟,如加时后,比分仍相同则进入下一个加时,直至分出胜负。详细比赛规则请参见度娘。
1.3 功能需求
NBA篮球图文直播室实现的功能主要包括实时数据、文字直播、技术统计、在线评球四大功能。实时数据包括实时比分、单节比分、当前场上队员、本节犯规次数、剩余暂停次数信息。文字直播是比赛实况和互动信息的实时播报。技术统计是两队参赛队员各项技术参数的统计和整个球队各项技术参数的汇总统计。如下图所示:
详细功能如下表所示:
序号 |
模块 |
功能 |
说明 |
1 |
实时数据 |
实时比分 |
两队实时总比分 |
2 |
单节比分 |
两队当前节比分 |
|
3 |
场上队员 |
两队当前场上队员 |
|
4 |
本节犯规 |
本节犯规次数,满5次罚球,清0 |
|
5 |
剩余暂停 |
剩余长短暂停数 |
|
6 |
文字直播 |
文字直播 |
直播员实时更新的赛况信息和互动信息 |
7 |
技术统计 |
出场时间 |
每个球员的出场比赛时间 |
8 |
投篮(中-投) |
每个球员两分球投篮次数和投中次数 |
|
9 |
三分(中-投) |
每个球员三分球投篮次数和投中次数 |
|
10 |
罚球(中-投) |
每个球员罚篮次数和投中次数 |
|
11 |
前篮板 |
每个球员前场篮板个数 |
|
12 |
后篮板 |
每个球员后场蓝本个数 |
|
13 |
总篮板 |
每个球员总篮板个数 |
|
14 |
助攻 |
每个球员的助攻次数 |
|
15 |
抢断 |
每个球员的抢断次数 |
|
16 |
盖帽 |
每个球员的盖帽次数 |
|
17 |
失误 |
每个球员的失误次数 |
|
18 |
犯规 |
每个球员的犯规次数 |
|
19 |
得分 |
每个球员的得分数 |
|
20 |
在线评球 |
会员评球 |
注册会员的在线评论信息 |
21 |
游客评球 |
游客身份的在线评论信息 |
1.4 存储设计
Memcached提供Key-value结构的数据存储,这也是当前主流内存数据库的存储方式,当前版本并不支持结构化数据的存储,本文只针对Key-Value存储结构的内存数据库进行设计,其他模式单独讨论,所以NBA篮球直播室后台数据存储设计最主要的内容就是key的设计。
1.4.1 命名规则
主队使用关键字HOST,客队使用关键字GUEST,所有关键字同意采用大写字母表示。由于双方数据项完全相同,所以本文只列出主队的关键字,客队数据项的关键之只需要替换HOST关键字即可。
1.4.1.1 实时数据
1.4.1.2 文字直播
1.4.1.3 技术统计
设计球员技术统计数据时,球员信息的表达有两种方案:
一是采用球衣号码作为关键字,这种方案的好处是关键字较短,按照NBA篮球比赛规则,球衣号码范围是0-99,所以只需要两位即可。同时考虑到NBA关于单场 比赛球员报名人数的限制,所以在此数据的最大存储量是15。
二是采用球员姓名作为关键字,这种方案的好处是球员数据和球员姓名不需要进行二次匹配,缺点是球员姓名过长,导致存储空间的增加。这里采用球衣号码作为 球员标识。
汇总技术统计采用后台程序自动计算的方式进行,直播员只需更新每个球员的当前数据即可。
1.4.2 过期管理
所有数据都采用过期设置,考虑到一场篮球比赛出现加时及其他各类情况,以及比赛当天赛事收关注度比较高的实际业务需求,过期周期设置为24小时。
1.4.3 持久管理
实时数据最终值除犯规次数和剩余暂停数外,和技术统计数据一起存入关系型数据库。文字直播数据和评论信息存入非关系型数据库。