本发明涉及网络信息处理领域,更具体地说,涉及一种高效率低延迟上报读取用户在线播放信息的方法。
背景技术:
近年来,随着网络设备的迭代,网络质量进一步提高,人们可以在互联网上做更多的事情。短视频,流媒体等相关服务越来越多,越来越流行,已经深入人们的生活当中。
许多公司都会提供流媒体相关的服务给大众,同时也会投入大量的人力物力来开发该服务系统。其中不可或缺的一部分就是实时上报在线用户的播放情况,提供准确的用户播放信息,用于及时处理系统问题,分析用户行为等工作。
随着用户数量的不断增加,每时每刻服务器都有大量的用户数据需要提交到数据库,给整个系统的性能带来巨大压力,甚至有可能导致系统奔溃,使得服务不可用。
运营的网络电视直播系统中,每天都有大量的用户在线播放网络电视,每时每刻都有巨量的数据需要提交并保存。所以一套高效,低延迟,准确的在线用户信息提交方法策略是十分有必要的。
技术实现要素:
本发明要解决的技术问题在于,针对现有技术的上述缺陷,提供一种高效率低延迟上报读取用户在线播放信息的方法。
本发明解决其技术问题所采用的技术方案是:构造一种高效率低延迟上报读取用户在线播放信息的方法,包括以下步骤:
s1、用户在线播放的信息保存到系统的专用缓冲区;
s2、当所述专用缓冲区中数据达到设定规模,或到达预先设定的提交时间时,批量将所有数据提交到redis数据库。
优选地,还包括步骤:
s3、当用户开始播放节目,出现一条全新的播放记录需要添加时;
s3.1、先使用redis中的hash结构来保存每条播放记录的各项数据(play:pidxxx);
s3.2、再使用redis中的有序集合结构保存所述s3.1中添加的新数据的唯一标识号。
优选地,所述s3.2还包括:保存数据添加的时间(notic:plays:);用于通知系统用户开始播放节目,数据已经更新完成。
优选地,还包括步骤:
s4、当用户结束播放节目时,最后一次更新该播放记录。
根据权利要求4所述的高效率低延迟上报读取用户在线播放信息的方法,其特征在于,所述步骤s4包括:
s4.1、更新保存对应播放记录的hash结构;
s4.2、将该条播放记录保存至另外一个hash结构(cache:vidxxx),使用用户标识作为键值,作为该用户上一次播放的缓冲数据,并设置超时时间;
s4.3、将s4.2中的数据键值和当前时间保存至redis的有序集合中(cache:plays:),来记录s4.2中每条缓存数据的最后更新时间
s4.4、通知系统用户播放已断开,数据已经更新,可以随时读取,使用有序集合play:pidxxx来完成,参考用户开始播放时的第一步。
优选地,所述步骤s4.3中,系统周期性的检查这些数据的更新时间,将超过有效期时间的数据,批量读取出来,转化成历史用户记录,并删除cache:plays:以及这些超时的数据。
优选地,还包括步骤:
s5、周期性的将持续播放的用户信息批量的更新到数据库,并检查用于通知系统用户开始结束播放的结构notice:plays:,缓存上一次播放记录的结构cache:plays:的数据规模,剔除设定时间范围和设定规模内的数据,防止数据记录过多缓存数据。
优选地,所述步骤s3中:
s3.3、周期性的尝试,从负责通知开始结束播放的有序集合notice:plays:结构中弹出多条数据,相对应的redis命令是zpopmin(key,1000);
s3.4、使用s3.3中读到的数据,作为键值来读取保存所有播放记录的结构play:pidxxx,判断记录时播放开始还是结束。
优选地,当该条数据是播放结束,立即从数据库redis中删除该记录。
优选地,还包括步骤s6:
s6.1、周期批量的尝试读取超过设定时长记录缓存上次播放记录时间和标识的结构cache:plays:;
s6.2、读取并删除s6.1中读取的数据,将读到的数据转变为历史播放数据另外存储。
实施本发明的高效率低延迟上报读取用户在线播放信息的方法,具有以下有益效果:redis数据库能将用户的播放相关数据较好的管理,在播放服务内部先进行缓存在线用户的信息,在一定的条件下批量上报到数据库,并数据库替换掉目前使用的mysql,采用redis来保存数据,并且采用特殊的提交办法和保存方式,当遇到大量的在线播放数据需要提交到数据库时,更加高效的同时,保留低延时,准确的特性。由于redis数据库本身的特性,对于这种具有唯一键的数据提交效率会远远高于mysql。
附图说明
下面将结合附图及实施例对本发明作进一步说明,附图中:
图1是本发明实施例中的高效率低延迟上报读取用户在线播放信息的方法中用户开始播放、结束播放、提交数据的过程流程图;
图2是如何使用和从数据库redis中读取数据的流程示意图;
图3是在线记录如何转变为离线记录的流程示意图。
具体实施方式
为了对本发明的技术特征、目的和效果有更加清楚的理解,现对照附图详细说明本发明的具体实施方式。
结合图1所示,本发明一个优选实施例中的高效率低延迟上报读取用户在线播放信息的方法包括以下步骤:
s1、用户在线播放的信息保存到系统专用缓冲区,专用缓冲区由系统程序本身的提供;
s2、当专用缓冲区中数据达到设定规模,或到达预先设定的提交时间时,批量将所有数据提交到redis数据库。
redis数据库能将用户的播放相关数据较好的管理,在播放服务内部先进行缓存在线用户的信息,在一定的条件下批量上报到数据库,并数据库替换掉目前使用的mysql,采用redis来保存数据,并且采用特殊的提交办法和保存方式,当遇到大量的在线播放数据需要提交到数据库时,更加高效的同时,保留低延时,准确的特性。由于redis数据库本身的特性,对于这种具有唯一键的数据提交效率会远远高于mysql。
还包括步骤:s3、当用户开始播放节目,出现一条全新的播放记录需要添加时;
s3.1、先使用redis中的hash结构来保存每条播放记录的各项数据(play:pidxxx);
s3.2、再使用redis中的有序集合结构保存所述s3.1中添加的新数据的唯一标识号。
进一步地,所述s3.2还包括:保存数据添加的时间(notic:plays:);用于通知系统用户开始播放节目,数据已经更新完成。
还包括步骤:s4、当用户结束播放节目时,最后一次更新播放记录。
所述步骤s4包括:
s4.1、更新保存对应播放记录的hash结构;
s4.2、将该条播放记录保存至另外一个hash结构(cache:vidxxx),使用用户标识作为键值,作为该用户上一次播放的缓冲数据,并设置超时时间。这样做的好处在于,当客户端由于某些网络不稳定的因素导致频繁的断开播放,重新播放时,理论上会产生一个节目的多条数据;缓存上一次的播放记录的好处在于,当用户断开时每次更新都会累加到上一次播放的数据上,这样在一定时间内的同一个节目,每个用户只会出现一条记录,不会产生多条短记录,给整个系统降低了大量这种数据,并且消除了由于网络等非用户行为的断线重连后带来的,数据不一致和记录不准确的问题。
s4.3、将s4.2中的数据键值和当前时间保存至redis的有序集合中(cache:plays:),来记录s4.2中每条缓存数据的最后更新时间。优选地,数据键值为用户标识。
进一步地,所述步骤s4.3中,系统的其他模块周期性的检查这些数据的更新时间,将超过有效期时间的数据,批量读取出来,转化成历史用户记录,并删除cache:plays:以及这些超时的数据。
s4.4、通知系统用户播放已断开,数据已经更新,可以随时读取,使用有序集合play:pidxxx来完成,参考用户开始播放时的第一步。
进一步地,还包括步骤:
s5、周期性的将持续播放的用户信息批量的更新到数据库,并检查用于通知系统用户开始结束播放的结构notice:plays:,缓存上一次播放记录的结构cache:plays:的数据规模,剔除设定时间范围和设定规模内的数据,防止数据记录过多缓存数据。
参考图1所示,展示了上面提到的用户开始播放,结束播放,提交数据的过程。
从上面说明的过程中可以看到,本方法只是在用户开始播放,和结束播放时才会使用通知系统的结构,其他时候是不通知的;这做大大提高了系统系统的效率,其他模块只需要知道用户是否正在播放就可以了,需要得到进一步详细的播放数据,再去redis中读取即可。
结合图2所示,以下是如何使用和从数据库redis中读取上面提到的数据,所述步骤s3中:
s3.3、周期性的尝试,从负责通知开始结束播放的有序集合notice:plays:结构中弹出多条数据,相对应的redis命令是zpopmin(key,1000);批量操作的好处是一次读取操作,完成多条数据处理;
s3.4、使用s3.3中读到的数据,作为键值来读取保存所有播放记录的结构play:pidxxx,判断记录时播放开始还是结束。
当该条数据是播放结束,立即从数据库redis中删除该记录。
当记录时开始播放时,处理保存该记录。
以上过程系统的其他模块就可以轻松高效低延时的知道用户是否正在播放。
下面说明在线记录如何转变为离线记录,还包括步骤s6:
s6.1、周期批量的尝试读取超过设定时长记录缓存上次播放记录时间和标识的结构cache:plays:;
s6.2、读取并删除s6.1中读取的数据,将读到的数据转变为历史播放数据另外存储。
具有以下有益效果:
1)支持海量的在线用户实际效果提升10倍有余;
2)高效率的通知系统用户在线情况;
3)不依赖整个系统中其他模块,也能正常工作,对数据库有保护,自动维护数据;
4)用户在线播放数据延时很低,准确度高,提升运维人员日常工作的效率;
5)合并了大量时间短小,并相同节目相同用户的记录,有效降低了历史播放记录的数据规模,实际测试约降低5倍的历史记录;大大提高了处理历史播放记录模块的效率等等。
可以理解地,上述各技术特征可以任意组合使用而不受限制。
以上所述仅为本发明的实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。