一种数据处理方法、装置及终端的利记博彩app

文档序号:7998655阅读:136来源:国知局
一种数据处理方法、装置及终端的利记博彩app
【专利摘要】本发明公开了一种数据处理方法、装置及终端,其中,该方法包括:接收数据交互请求,根据用户相关度关系获得与请求用户对应的应答用户数据队列,将应答用户数据队列以应答用户信息进行排序标识;将所述应答用户数据队列转换为请求用户数据队列,将请求用户数据队列以请求用户信息进行排序标识;将请求用户数据队列推送给用户终端。采用本发明,既能满足数据有效性,又能缓解系统资源占用和网络开销增大的问题。
【专利说明】一种数据处理方法、装置及终端

【技术领域】
[0001] 本发明涉及互联网数据交互的处理技术,尤其涉及一种数据处理方法、装置及终 端。

【背景技术】
[0002] 随着互联网技术的普及,人们获得有效数据的方式,已经由传统的媒体如报纸,期 刊等转到互联网媒体,互联网中存在信息量巨大的数据,用户可以根据自身需求直接从互 联网中获取大量数据,也可以通过数据共享的方式获得数据。互联网技术兴起后出现了大 量社交应用类的工具,这些社交应用类的工具就是为了方便用户间数据共享来设计的,虽 然提供了多种数据共享途径,但是也存在问题,诸如,数据共享是能获得更多的数据,但是 哪些是用户需要的有效数据未可知;数据共享是基于数据交互存在的,信息量巨大的数据 在数据交互时必定导致系统资源占用,如接收端接收数据时的缓存占用,交互时网络带宽 占用导致网络开销增大的问题。
[0003] 目前,为了解决上述问题,采用的方案主要有两种数据处理方案,对数据进行处理 来获得有效数据,以减少数据交互时的数据量,分别阐述如下:
[0004] 方案一:对于数据交互时传输的数据,采用存储量固定的数据格式,比如可以设置 最多存储的数据量上限,数据按照先进先出的方式进行处理。这个方案存在的问题是:设定 数据量上限的数据格式,没法完整的表述所有的数据,因为超过数据量上限就不支持了,因 此,这种处理方案只是针对局部数据的,无法针对所有的全量数据,数据量虽然小了,对系 统资源占用和网络开销增大的问题有所缓解,但是由于不是针对全量数据,分析不准确,会 导致从全量数据中得到有效数据的概率大大降低。
[0005] 方案二:对于数据交互时传输的数据,不限定具体的数据格式,区别于上述方案一 是针对局部数据进行处理,本方案是针对全量数据进行处理,以获得有效数据。这个方案存 在的问题是:虽然没有设定数据量上限,针对全量数据,可以完整的表述所有的数据,针对 全量数据处理,分析准确,得到有效数据的概率大大提高,但是,交互时获得全量数据的过 程,由于数据量巨大,没法缓解系统资源占用和网络开销增大的问题。
[0006] 综上所述,无论采用哪种现有方案,都没法既能满足数据有效性,又能缓解系统资 源占用和网络开销增大的问题。


【发明内容】

[0007] 有鉴于此,本发明的主要目的在于提供一种数据处理方法、装置及终端,既能满足 数据有效性,又能缓解系统资源占用和网络开销增大的问题。
[0008] 为达到上述目的,本发明的技术方案是这样实现的:
[0009] 一种数据处理方法,该方法包括:
[0010] 接收数据交互请求,根据用户相关度关系获得与请求用户对应的应答用户数据队 列,将应答用户数据队列以应答用户信息进行排序标识; toon] 将所述应答用户数据队列转换为请求用户数据队列,将请求用户数据队列以请求 用户信息进行排序标识;
[0012] 将请求用户数据队列推送给用户终端。
[0013] 其中,该方法还包括:所述将请求用户数据队列推送给用户终端之前,将接收的时 间戳封装到所述请求用户数据队列中的对应请求用户信息中;所述时间戳标识请求用户成 功登录的时间。
[0014] 其中,该方法还包括:将请求用户数据队列推送给用户终端之前,从所述请求用户 数据队列中删除无效数据。
[0015] 其中,所述从所述请求用户数据队列中删除无效数据具体包括:对所述请求用户 数据队列进行定期扫描或定时扫描,当所述时间戳超过预设时间上限仍没有更新时,将对 应请求用户信息判定为无效数据,从所述请求用户数据队列中删除对应请求用户信息。
[0016] 一种数据处理方法,该方法包括:
[0017] 触发数据交互请求来获取请求用户数据队列;所述请求用户数据队列以请求用户 信息进行排序标识。
[0018] 其中,所述触发数据交互请求具体包括:由请求用户采用用户账号成功登录来触 发所述数据交互请求。
[0019] 其中,该方法还包括:在所述数据交互请求中携带有时间戳,所述时间戳标识请求 用户成功登录的时间。
[0020] 其中,该方法还包括:所述获取请求用户数据队列之后,显示所述请求用户数据队 列,所述请求用户数据队列包括所述时间戳。
[0021] 一种数据处理装置,该装置包括:
[0022] 获取及排序单元,用于接收数据交互请求,根据用户相关度关系获得与请求用户 对应的应答用户数据队列,将应答用户数据队列以应答用户信息进行排序标识;
[0023] 转换及排序单元,用于将所述应答用户数据队列转换为请求用户数据队列,将请 求用户数据队列以请求用户信息进行排序标识;
[0024] 推送单元,用于将请求用户数据队列推送给用户终端。
[0025] 其中,该装置还包括:封装单元,用于将时间戳封装到所述请求用户数据队列中的 对应请求用户信息中;所述时间戳标识请求用户成功登录的时间。
[0026] 其中,该装置还包括:数据删除单元,用于从所述请求用户数据队列中删除无效数 据。
[0027] 其中,所述数据删除单元,进一步用于对所述请求用户数据队列进行定期扫描或 定时扫描,当所述时间戳超过预设时间上限仍没有更新时,将对应请求用户信息判定为无 效数据,从所述请求用户数据队列中删除对应请求用户信息。
[0028] 其中,该装置位于后台服务器侧。
[0029] 一种数据处理终端,该终端包括:
[0030] 数据请求单元,用于触发数据交互请求;
[0031] 数据获取单元,用于获取请求用户数据队列;所述请求用户数据队列以请求用户 信息进行排序标识。
[0032] 其中,所述数据请求单元,进一步用于由请求用户采用用户账号成功登录来触发 所述数据交互请求。
[0033] 其中,该终端还包括:数据发送单元,用于将时间戳携带在所述数据交互请求中发 送给服务器;所述时间戳标识请求用户成功登录的时间。
[0034] 其中,该终端还包括:数据显示单元,用于显示所述请求用户数据队列,所述请求 用户数据队列包括所述时间戳。
[0035] 本发明的方法是接收数据交互请求,根据用户相关度关系获得与请求用户对应的 应答用户数据队列,将应答用户数据队列以应答用户信息进行排序标识;将应答用户数据 队列转换为请求用户数据队列,将请求用户数据队列以请求用户信息进行排序标识;将请 求用户数据队列推送给用户终端。
[0036] 采用本发明,由于是根据用户相关度关系获取与请求用户对应的应答用户的数据 队列,因此,处理得到的数据既不会有遗漏,又是和请求用户最相关的有效数据,从而既能 满足数据有效性,又能缓解系统资源占用和网络开销增大的问题。

【专利附图】

【附图说明】
[0037] 图1为本发明方法实施例一的实现流程示意图;
[0038] 图2为本发明方法实施例二的实现流程示意图;
[0039] 图3为本发明装置实施例的组成结构示意图;
[0040] 图4为本发明终端实施例的组成结构示意图;
[0041] 图5为本发明应用实例一的数据交互示意图;
[0042] 图6为本发明应用实例二的数据交互示意图。

【具体实施方式】
[0043] 本发明的基本思想是:接收数据交互请求,根据用户相关度关系获得与请求用户 对应的应答用户数据队列,将应答用户数据队列以应答用户信息进行排序标识;将应答用 户数据队列转换为请求用户数据队列,将请求用户数据队列以请求用户信息进行排序标 识;将请求用户数据队列推送给用户终端。
[0044] 下面结合附图对技术方案的实施作进一步的详细描述。
[0045] 方法实施例一:本发明的数据处理方法,如图1所示,该方法包括以下步骤:
[0046] 步骤101、接收数据交互请求,根据用户相关度关系获得与请求用户对应的应答用 户数据队列,将应答用户数据队列以应答用户信息进行排序标识。
[0047] 这里,数据交互请求由请求用户采用用户账号成功登录后触发。
[0048] 这里,该应答用户数据队列的数据结构为:以应答用户信息进行排序标识,该应答 用户数据队列的具体结构形式,在后续方法实施例有具体描述。
[0049] 步骤102、将应答用户数据队列转换为请求用户数据队列,将请求用户数据队列以 请求用户信息进行排序标识。
[0050] 这里,请求用户数据队列存储在数据库中,数据库可以为Redis,Redis为高性能 的key-value数据库,是开源的内存数据库,Redis是其名称。
[0051] 这里,请求用户数据队列以用户帐号进行指示,即:请求用户数据队列为:以用户 帐号指示的包含请求用户信息的队列,且请求用户信息中包括时间戳,时间戳也可以单独 表示,不加入对应请求用户信息中。也就是说,所述时间戳在所述请求用户数据队列的封装 方式有两种:一:将所述请求用户成功登录的时间以时间戳的形式直接加入请求用户数据 队列中的对应请求用户信息中;或者,将所述请求用户成功登录的时间以时间戳的形式加 入请求用户数据队列,与对应请求用户信息分别表示在数据队列中。请求用户数据队列的 具体结构形式,在后续方法实施例有具体描述。
[0052] 步骤103、将请求用户数据队列推送给用户终端。
[0053] 这里,将请求用户数据队列推送给用户终端之前,将时间戳封装到请求用户数据 队列中的对应请求用户信息中;时间戳标识请求用户成功登录的时间。
[0054] 这里,将请求用户数据队列推送给用户终端之前,从请求用户数据队列中删除无 效数据。
[0055] 这里,所述从请求用户数据队列中删除无效数据具体为:对请求用户数据队列进 行定期扫描或定时扫描,当时间戳超过预设时间上限仍没有更新时,将对应请求用户信息 判定为无效数据,从请求用户数据队列中删除对应请求用户信息。
[0056] 这里,定期扫描为:周期性的定期扫描,是按照预设的频率来进行扫描,比如一天, 一周等来扫描;而定时扫描是按照预设的时间点进行扫描,比如9点,10点等来扫描。
[0057] 方法实施例二:本发明的数据处理方法,如图2所示,该方法包括以下步骤:
[0058] 步骤201、触发数据交互请求,请求根据用户相关度关系返回与请求用户对应的应 答用户数据队列;应答用户数据队列以应答用户信息进行排序标识。
[0059] 这里,所述请求根据用户相关度关系返回与请求用户对应的应答用户数据队列具 体包括:由请求用户采用用户账号成功登录后触发所述请求。
[0060] 步骤202、获取对应答用户数据队列转换后得到的请求用户数据队列;请求用户 数据队列以请求用户信息进行排序标识。
[0061] 这里,所述获取对所述应答用户数据队列转换后得到的请求用户数据队列之前, 将时间戳携带在数据交互请求中发送给服务器;所述时间戳标识请求用户成功登录的时 间。
[0062] 这里,所述获取对所述应答用户数据队列转换后得到的请求用户数据队列之后, 显示所述请求用户数据队列,所述请求用户数据队列包括所述时间戳。
[0063] 装置实施例:本发明的数据处理装置,位于后台服务器侧,如图3所示,该装置包 括:
[0064] 获取及排序单元,用于接收数据交互请求,根据用户相关度关系获得与请求用户 对应的应答用户数据队列,将应答用户数据队列以应答用户信息进行排序标识;
[0065] 转换及排序单元,用于将所述应答用户数据队列转换为请求用户数据队列,将请 求用户数据队列以请求用户信息进行排序标识;
[0066] 推送单元,用于将请求用户数据队列推送给用户终端。
[0067] 这里,该装置还包括:封装单元,用于将时间戳封装到所述请求用户数据队列中的 对应请求用户信息中;所述时间戳标识请求用户成功登录的时间。
[0068] 这里,该装置还包括:数据删除单元,用于从所述请求用户数据队列中删除无效数 据。
[0069] 这里,所述数据删除单元,进一步用于对所述请求用户数据队列进行定期扫描或 定时扫描,当所述时间戳超过预设时间上限仍没有更新时,将对应请求用户信息判定为无 效数据,从所述请求用户数据队列中删除对应请求用户信息。
[0070] 这里,该装置还包括:数据存储单元,用于存储所述请求用户数据队列。
[0071] 进一步的,所述获取及排序单元、所述转换及排序单元、所述封装单元、所述数据 删除单元不仅可以如上述描述在该装置中分开独立设置,还可以合并设置到该装置内的一 个数据处理执行单元中。
[0072] 所述数据存储单元,数据存储单元可以采用一主模块和多个从模块配合工作的逻 辑结构;其中,从模块用于执行并发处理的读操作,并将收到的、用户采用用户帐号成功登 录触发数据交互请求后获取的请求用户信息读入所述主模块。主模块用于对来自于多个所 述从模块的所述请求用户信息进行去重复处理后存储,将去重复处理后的信息提供给数据 处理执行单元进行数据处理,存储数据处理后获得的所述请求用户数据队列。从模块进一 步用于以批处理的方式,收到用户采用用户帐号成功登录触发数据交互请求后获取的请求 用户信息。
[0073] 终端实施例:本发明的数据处理终端,位于前端用户终端侧,如图4所示,该终端 包括:
[0074] 数据请求单元,用于触发数据交互请求,请求根据用户相关度关系返回与请求用 户对应的应答用户数据队列;所述应答用户数据队列以应答用户信息进行排序标识;
[0075] 数据获取单元,用于获取对所述应答用户数据队列转换后得到的请求用户数据队 列;所述请求用户数据队列以请求用户信息进行排序标识。
[0076] 这里,所述数据请求单元,进一步用于由请求用户采用用户账号成功登录来触发 所述数据交互请求。
[0077] 这里,该终端还包括:数据发送单元,用于将时间戳携带在所述数据交互请求中发 送给服务器;所述时间戳标识请求用户成功登录的时间。
[0078] 这里,该终端还包括:数据显示单元,用于显示所述请求用户数据队列,所述请求 用户数据队列包括所述时间戳。
[0079] 这里需要指出的是,本发明适用于所有数据交互场景,包括应用各种社交应用类 的工具的情况,不限于微博的数据交互场景。
[0080] 应用实例一:为本发明数据交互及数据处理的一应用实例,社交应用类的工具为 微博时的数据交互应用场景。本实例基于本发明分别位于用户终端侧和服务器侧的上述装 置中的单元进行数据交互及数据处理。
[0081] 这里,在本实例具体的微博应用中,具体的,通过用户成功登录后的上线命令触发 数据交互请求,请求用户为粉丝,应答用户为偶像,用户相关度关系为:粉丝与偶像间的收 听与被收听关系,有效数据为粉丝是否为活跃度用户,活跃度并不是以即时在线或离线的 状态来界定,而是以粉丝和偶像间相互收听与被收听的关注度关系来界定,比如,一个粉丝 虽然在线,但是与偶像间即时没有相互收听与被收听的关注度关系,那这个粉丝就不算活 跃,不属于有效数据,以此类推,不做赘述。其中,就偶像和粉丝而言,A收听了 B,则A是B 的粉丝,B是A的偶像。本实施例中以A表示粉丝用户,B表示偶像用户。就活跃度而言, 如果A在30分钟内发表过微博或拉取过首页,则认为A活跃,在线状态,反之则认为A不活 跃,离线状态。
[0082] 如图5所示,本实例的流程包括以下内容:
[0083] 1、通过用户Uin的上线命令触发数据交互请求。
[0084] 2、收到上线命令后,拉取粉丝A的偶像链B的数据队列:偶像链A(idoll, idol2,···)〇
[0085] 3、对以B进行排序标识的数据队列:A(idoll,id〇12, · · ·)进行数据格式转换,得 到以A进行排序标识的数据队列:粉丝链Idoll (A),Id〇12(A),...。
[0086] 4、将粉丝链 Idoll (time, A), Idol2 (time, A),· · ·存储到包含 Redis 类型数据库 的数据存储单元。
[0087] 这里,每个粉丝A多了一个时间戳time,用于标识A的上线时间。
[0088] 5、对Redis类型数据库中的粉丝进行周期性扫描,如果粉丝的时间戳超过30分钟 没有更新,则删除该粉丝。
[0089] 以下以微博应用场景,对比本发明和现有技术,以体现本发明的优越性。
[0090] 现有技术的微博应用场景下,采用的处理方案有两种:
[0091] 处理方案一:数据交互时传输的数据,采用存储量固定的数据格式,数据量上限 为:存储最近的1万粉丝。该方案存在的问题是:数据在存储上有所限制,限定只存储1万 个粉丝,多出来粉丝,按照先进先出的方法进行淘汰,一方面,长度会受限,只能存储1万个 在线粉丝,而实际中很多用户的在线粉丝会超出100万,可见,设置数据量上限后,只能针 对局部数据处理,虽然数据交互时的数据量减少了,但是有效数据也会随之减少;另一方 面,数据有效性很低,最近的1万个粉丝不一定都在线,而很多在线粉丝又不在这1万个里 面,不能真实反映用户活跃度。
[0092] 处理方案二:数据交互时传输的数据,不限定具体的数据格式,针对全量数据,即 拉取全量粉丝然后处理出在线粉丝。具体的,首先将一个用户的全量粉丝拉取出来,然后根 据这些粉丝的状态处理出在线的粉丝。该方案存在的问题是:针对全量数据,数据量大,则 有效数据也有更多选择,会更加精确,但是,一方面,通信和计算开销过大,因为很多用户的 粉丝多达百万甚至千万,拉取全量粉丝会导致很大的网络开销,拉取完后再处理出在线粉 丝又会导致很大的计算开销,对系统资源,如缓存占用大,加重CPU的负载;另一方面,延迟 太大,因为全量粉丝数据量很大,拉取和处理需要一定时间,导致延迟很大。
[0093] 综上所述,采用处理方案一和处理方案二,无法既能满足数据有效性,又能缓解系 统资源占用和网络开销增大的问题,因为它们都是基于单向数据来处理的,所谓单向数据 是指仅仅针对用户的粉丝来展开的数据,不考虑相关度,得到的粉丝会有很多。而本发明可 以理解为基于双向数据来处理,所谓双向数据是指根据用户相关度关系来处理,具体到微 博应用为:粉丝与偶像间的收听与被收听关系,因为是相关度来看,所以得到的数据相比现 有技术就会少很多,而且基于相关度来看的粉丝成为有效数据的概率更高,除了交互数据 量减小,有效数据的概率更高,由于能尽快得到有效数据,因此,交互的延时也小。
[0094] 应用实例二:社交应用类的工具为微博时的数据交互应用场景。
[0095] 如图6所示,图6为数据处理执行单元和数据存储单元间的交互示意图。本实例 中,数据存储单元为一主多从的逻辑结构,即一个主模块和多个从模块构成的逻辑结构,且 采用Redis的数据库。
[0096] 数据存储单元存储数据的时候,采用现有Redis的有序集合,简称Zset,由于有序 集合自身的特点,使得两个问题得到了高效解决:一:在线粉丝的自动去重复处理,多个从 模块并行处理,会将读入的数据都传输给主模块,这样数据传输效率会高,而且多个从模块 间保存的同样的数据可以互相备份,如果任一个出现问题,都确保数据不会丢失,提高安全 性,但是由于多个从模块读入的数据会有所重复,因此,需要主模块进行去重复处理,在微 博应用场景下,,重复粉丝只保留一个;二:一个用户的所有在线粉丝自动按照上线时间进 行排序,很容易得到时间戳。
[0097] 在数据存储单元存储数据时,数据格式也称为存储结构的逻辑表示为:
[0098] Uin : {(timel, Fanl), (time2, Fan2), (time3, Fan3), . . . }
[0099] 其中,Uin表示用户的用户帐号,后面跟着该用户的在线粉丝链,每个在线粉丝用 一对元组(time, Fan)来表示,time表示上线时的时间戳,Fan表示该粉丝的用户帐号。 [0100] 数据处理执行单元从数据存储单元获得待处理数据实现处理。
[0101] 这里需要指出的是:图6的逻辑结构为2层架构,即逻辑层(数据处理执行单元) 与存储层(数据存储单元),两层通过网络相连。分为2层降低了系统的耦合性,使得逻辑 与存储可以独立维护。逻辑层(数据处理执行单元)与存储层(数据存储单元)也可以集 成在一起。
[0102] 逻辑层(数据处理执行单元)与存储层(数据存储单元)采用流水线,应用程序 编程接口(API, Application Programming Interface)进行通信,使得多个粉丝通过批处 理方式可以一次添加完成,而不需要一次次分别添加,因此大大提高了操作效率并降低了 整体延时。
[0103] 存储层(数据存储单元)采用一主多从,即一个主(Master)多个从(slave)的逻 辑结构,数据存储单元的主模块承担写操作,数据存储单元的从模块承担读操作。一主多从 结构适应了业务的多读少写的特点,提高了系统的整体性能。
[0104] 以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。
【权利要求】
1. 一种数据处理方法,其特征在于,该方法包括: 接收数据交互请求,根据用户相关度关系获得与请求用户对应的应答用户数据队列, 将应答用户数据队列以应答用户信息进行排序标识; 将所述应答用户数据队列转换为请求用户数据队列,将请求用户数据队列以请求用户 信息进行排序标识; 将请求用户数据队列推送给用户终端。
2. 根据权利要求1所述的方法,其特征在于,该方法还包括:所述将请求用户数据队列 推送给用户终端之前,将接收的时间戳封装到所述请求用户数据队列中的对应请求用户信 息中;所述时间戳标识请求用户成功登录的时间。
3. 根据权利要求2所述的方法,其特征在于,该方法还包括:将请求用户数据队列推送 给用户终端之前,从所述请求用户数据队列中删除无效数据。
4. 根据权利要求3所述的方法,其特征在于,所述从所述请求用户数据队列中删除无 效数据具体包括:对所述请求用户数据队列进行定期扫描或定时扫描,当所述时间戳超过 预设时间上限仍没有更新时,将对应请求用户信息判定为无效数据,从所述请求用户数据 队列中删除对应请求用户信息。
5. -种数据处理方法,其特征在于,该方法包括: 触发数据交互请求来获取请求用户数据队列;所述请求用户数据队列以请求用户信息 进行排序标识。
6. 根据权利要求5所述的方法,其特征在于,所述触发数据交互请求具体包括:由请求 用户采用用户账号成功登录来触发所述数据交互请求。
7. 根据权利要求5或6所述的方法,其特征在于,该方法还包括:在所述数据交互请求 中携带有时间戳,所述时间戳标识请求用户成功登录的时间。
8. 根据权利要求7所述的方法,其特征在于,该方法还包括:所述获取请求用户数据队 列之后,显示所述请求用户数据队列,所述请求用户数据队列包括所述时间戳。
9. 一种数据处理装置,其特征在于,该装置包括: 获取及排序单元,用于接收数据交互请求,根据用户相关度关系获得与请求用户对应 的应答用户数据队列,将应答用户数据队列以应答用户信息进行排序标识; 转换及排序单元,用于将所述应答用户数据队列转换为请求用户数据队列,将请求用 户数据队列以请求用户信息进行排序标识; 推送单元,用于将请求用户数据队列推送给用户终端。
10. 根据权利要求9所述的装置,其特征在于,该装置还包括:封装单元,用于将时间戳 封装到所述请求用户数据队列中的对应请求用户信息中;所述时间戳标识请求用户成功登 录的时间。
11. 根据权利要求10所述的装置,其特征在于,该装置还包括:数据删除单元,用于从 所述请求用户数据队列中删除无效数据。
12. 根据权利要求11所述的装置,其特征在于,所述数据删除单元,进一步用于对所述 请求用户数据队列进行定期扫描或定时扫描,当所述时间戳超过预设时间上限仍没有更新 时,将对应请求用户信息判定为无效数据,从所述请求用户数据队列中删除对应请求用户 信息。
13. 根据权利要求9至12任一项所述的装置,其特征在于,该装置位于后台服务器侧。
14. 一种数据处理终端,其特征在于,该终端包括: 数据请求单元,用于触发数据交互请求; 数据获取单元,用于获取请求用户数据队列;所述请求用户数据队列以请求用户信息 进行排序标识。
15. 根据权利要求14所述的终端,其特征在于,所述数据请求单元,进一步用于由请求 用户采用用户账号成功登录来触发所述数据交互请求。
16. 根据权利要求15所述的终端,其特征在于,该终端还包括:数据发送单元,用于将 时间戳携带在所述数据交互请求中发送给服务器;所述时间戳标识请求用户成功登录的时 间。
17. 根据权利要求16所述的终端,其特征在于,该终端还包括:数据显示单元,用于显 示所述请求用户数据队列,所述请求用户数据队列包括所述时间戳。
【文档编号】H04L29/06GK104125163SQ201310148437
【公开日】2014年10月29日 申请日期:2013年4月25日 优先权日:2013年4月25日
【发明者】刘啸南, 熊欢 申请人:腾讯科技(深圳)有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1