CN103051511B - 一种消息数据的处理方法及装置 - Google Patents

一种消息数据的处理方法及装置 Download PDF

Info

Publication number
CN103051511B
CN103051511B CN201110306094.1A CN201110306094A CN103051511B CN 103051511 B CN103051511 B CN 103051511B CN 201110306094 A CN201110306094 A CN 201110306094A CN 103051511 B CN103051511 B CN 103051511B
Authority
CN
China
Prior art keywords
message
queue
message data
data
feed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201110306094.1A
Other languages
English (en)
Other versions
CN103051511A (zh
Inventor
马天笑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
YOUMENG TONGXIN (BEIJING) TECHNOLOGY Co.,Ltd.
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201110306094.1A priority Critical patent/CN103051511B/zh
Publication of CN103051511A publication Critical patent/CN103051511A/zh
Priority to HK13106362.2A priority patent/HK1179436A1/zh
Application granted granted Critical
Publication of CN103051511B publication Critical patent/CN103051511B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

本申请提供了一种消息数据的处理方法及装置,以解决现有的消息数据排序过程中浪费计算资源的问题。本申请借助于每个消息队列(如Feed队列)都是有序队列(如已经按照时间排好序)的特点,只对满足用户请求(即用户确实需要)的那部分数据进行排序,而不需要每次都对所有参与排序的消息队列进行排序,从而提高了计算资源的利用,进而提升了用户查询消息数据时的响应时间。

Description

一种消息数据的处理方法及装置
技术领域
本申请涉及网络数据处理技术,特别是涉及一种消息数据的处理方法及装置。
背景技术
消息数据是一种数据格式,用于向用户提供频繁更新的内容,例如Feed数据就是一种消息数据。下面将以Feed数据为例进行说明。
对于Feed的应用,可以理解为是一种信息传输方式,与所熟悉的电子邮件、万维网(WWW)、即时消息传送(IM)并列。通过Feed这种信息传输方式,可以在同样的时间内让用户浏览更大量的信息。
在应用Feed的典型场景中,用户在应用***中产生的一些内容,如用户发表的一篇微博,这些用户产生的内容会被应用***推送给用户的好友或者粉丝,并在用户的好友及其粉丝的个人微博中展示出来,这些被展示出来的内容即是一种Feed数据。
通常,应用***为了维护***中数据量庞大的Feed数据,会为每个用户设置对应的Feed队列(也可以称为Feed列表),Feed队列既用于存储这个用户通过应用***向其他用户发布的信息,又用于存储该用户从其他用户接收的信息,即其他用户发布给该用户的信息。
当某用户A希望浏览Feed数据,如登录微博时,向应用***发送查询Feed数据的请求。应用***为了获取该用户可以看到的所有Feed数据,有时需要对多个不同Feed队列中的Feed数据按照时间进行排序。其中所述多个不同的Feed队列既包含用户自己的Feed队列,也包含与用户A相关的其他多个用户的不同Feed队列,如微博中用户A所关注的热门用户的Feed队列。排序后,再将所有的Feed数据按照时间倒序呈现给用户A,即优先展示最新的Feed数据,时间比较久的那些Feed数据则放到后面进行展示。
现有的技术中,常用的排序办法是将需要排序的所有Feed队列全部放到一个集合中,并对这个集合中的Feed数据按照时间进行排序。由于用户一般只关注最近一段时间内的Feed数据,对于离用户登录时间比较久远的Feed数据,用户不太会关注,所以***会选择返回用户请求的那一页的Feed数据。通常只有在用户翻动页面时,***才会将后续的Feed数据返回展示。
但是,按照上述排序方法,每次用户请求的时候都要对需要排序的所有Feed队列进行一次按时间的排序,这对计算资源造成了很大的浪费。而且,对所有Feed数据排序的过程也会影响请求的响应时间,造成用户的等待,影响用户体验。同理,对于类似Feed数据的其他消息数据,也存在同样的问题。
发明内容
本申请提供了一种消息数据的处理方法及装置,以解决现有的消息数据排序过程中浪费计算资源的问题。
为了解决上述问题,本申请公开了一种消息数据的处理方法,包括:
为对应用户账户创建消息队列,并将用户发布和接收的消息数据放入对应的消息队列中;
接收针对某个用户账户的消息数据查询请求,并执行以下步骤:
步骤1,依据所述消息数据查询请求获取需进行排序的多个有序消息队列,所述需进行排序的多个有序消息队列包含该用户账户的消息队列,以及与该用户账户关联的热门用户账户的消息队列;
步骤2,从每个有序消息队列中分别按序读取一个消息数据,并将所读取的多个消息数据放入排序集合;
步骤3,对所述排序集合中的所有消息数据进行排序,得到排序结果,并从所述排序结果中选择一个消息数据输出;
步骤4,从所述输出的消息数据所属的消息队列中再按序读取一个消息数据,并将所读取的消息数据放入所述排序集合;
重复步骤3和步骤4,直到输出的所有消息数据满足所述请求要求。
优选的,在循环截止之前还包括:当需进行排序的多个有序消息队列中,只有一个消息队列不为空时,重复将所述不为空的消息队列中的消息数据按序读取并输出,直到输出的所有消息数据个数满足所述请求要求的数量为止。
优选的,所述有序消息队列中的消息数据是按照时间倒序排列;所述从消息队列中按序读取一个消息数据包括:从消息队列中按照时间倒序读取第一个消息数据;
所述对排序集合中的所有消息数据进行排序包括:对排序集合中的所有消息数据按照时间倒序进行排序;
所述从排序结果中选择一个消息数据输出包括:从按照时间倒序的排序结果中选择第一个消息数据输出。
优选的,所述排序集合的大小等于需进行排序的有序消息队列的个数。
优选的,所述方法还包括:将输出的所有消息数据进行展示。
本申请还提供了一种消息数据的处理装置,包括:
队列创建模块,用于为对应用户账户创建消息队列,并将用户发布和接收的消息数据放入对应的消息队列中;
队列获取模块,用于接收针对某个用户账户的消息数据查询请求,并依据所述消息数据查询请求获取需进行排序的多个有序消息队列,所述需进行排序的多个有序消息队列包含该用户账户的消息队列,以及与该用户账户关联的热门用户账户的消息队列;
消息数据读取模块,用于从每个有序消息队列中分别按序读取一个消息数据,并将所读取的多个消息数据放入排序集合;
排序输出模块,用于对所述排序集合中的所有消息数据进行排序,得到排序结果,并从所述排序结果中选择一个消息数据输出;
循环调用模块,用于重复调用所述消息数据读取模块和排序输出模块,从所述输出的消息数据所属的消息队列中再按序读取一个消息数据,并将所读取的消息数据放入所述排序集合进行排序输出,直到输出的所有消息数据满足所述请求要求。
优选的,所述装置还包括:特殊处理模块,用于当需进行排序的多个有序消息队列中,只有一个消息队列不为空时,重复将所述不为空的消息队列中的消息数据按序读取并输出,直到输出的所有消息数据个数满足所述请求要求的数量为止。
优选的,所述有序消息队列中的消息数据是按照时间倒序排列;所述消息数据读取模块是从每个有序消息队列中分别按照时间倒序读取第一个消息数据;
所述排序输出模块是对排序集合中的所有消息数据按照时间倒序进行排序,得到排序结果,并从所述排序结果中选择第一个消息数据输出。
优选的,所述排序集合的大小等于需进行排序的有序消息队列的个数。
优选的,所述装置还包括:展示模块,用于将输出的所有消息数据进行展示。
与现有技术相比,本申请包括以下优点:
本申请借助于每个消息队列(如Feed队列)都是有序队列(如已经按照时间排好序)的特点,只对满足用户请求(即用户确实需要)的那部分数据进行排序,而不需要每次都对所有参与排序的消息队列进行排序,从而提高了计算资源的利用,进而提升了用户查询消息数据时的响应时间。
附图说明
图1是本申请实施例所述将多个Feed队列合并排序的示意图;
图2是本申请实施例所述一种消息数据的处理方法流程图;
图3是本申请例1中对两个Feed队列进行合并排序的示意图;
图4是本申请例2中对三个Feed队列进行合并排序的示意图;
图5是本申请实施例所述一种消息数据的处理装置结构图;
图6是本申请另一实施例所述一种消息数据的处理装置结构图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
在消息数据的应用***(以下简称为***)中,为了获取一个用户可以看到的消息数据,有时需要对多个不同的消息队列进行排序。以Feed数据为例,具体的一种应用场景如下:
在微博网站、交友互动平台等Feed应用***中,每个用户都有自己的Feed队列。对于普通用户,由于其好友的数量有限,所以普通用户发布和接收的Feed数据量也不会太大,因此,***通常为普通用户设置一个Feed队列,用来存储该用户发布和接收的Feed数据,即:每当该用户发布一条Feed数据,或从其好友处接收一条Feed数据,***都会将这些Feed数据拷贝到该用户的Feed队列中。这样,如果获取该用户可以看到的所有Feed数据,直接读取该用户的Feed队列即可。
但是,对于热门用户而言,其粉丝数是非常多的,可能有几十万甚至上百万,如果将热门用户发布的一条Feed数据拷贝到每个粉丝的Feed队列中,将耗费非常多的工作量和时间,给***带来很大的压力。为解决此问题,***通常为热门用户设置两个Feed队列,一个用于存储热门用户自己发布的Feed数据,另一个用于存储热门用户从其他用户(如好友)接收的Feed数据。这样,当获取一个用户可以看到的所有Feed数据时,就需要对该用户的Feed队列和该用户所关注的热门用户的Feed队列(存储接收的Feed数据的队列)进行排序。
本申请提出一种消息数据的处理方法及装置,可以对多个不同的消息队列进行排序,并将排序后的消息数据呈现给用户。例如,参照图1所示,可以将用户A的Feed队列、用户B的Feed队列、用户C的Feed队列和用户D的Feed队列进行合并,并对合并后的Feed数据进行排序,然后将要呈现给用户的Feed数据输出。
下面通过实施例对本申请所述方法的实现流程进行详细说明。
参照图2,其为本申请实施例所述一种消息数据的处理方法流程图。仍以Feed数据为例,流程如下:
步骤S1,为对应用户账户创建消息队列,并将用户发布和接收的消息数据放入对应的消息队列中;
如前所述,在消息数据的应用***中,每个用户都有自己的消息队列,也即:***会为每个注册的用户账户创建一个或多个空消息队列。如果是普通用户,则创建一个空消息队列,该用户每发布一条消息数据以及每接收一条消息数据,都会放入这个空消息队列。但是对于拥有大量好友或粉丝的热门用户,***会对于该热门用户的账户创建两个空消息队列,其中一个空消息队列用于存放该热门用户发布的每一条消息数据,而另一个空消息队列用于存放该热门用户接收到的每一条消息数据。
步骤S2,接收针对某个用户账户的消息数据查询请求,并执行以下步骤:
步骤1,依据所述消息数据查询请求获取需进行排序的多个有序消息队列,所述需进行排序的多个有序消息队列包含该用户账户的消息队列,以及与该用户账户关联的热门用户账户的消息队列;
在微博网站、交友互动平台等Feed应用***中,一个用户的所有好友都可称为该用户的关联用户。在这些关联用户中,有些是普通用户,有些是热门用户。如果请求查询某一个用户的Feed数据,而该用户的好友中包含了热门用户,则用于进行排序的Feed队列不仅包含该用户自己的Feed队列,还包含该用户的好友中热门用户的Feed队列(主要是存放发布的Feed数据的那个队列)。
例如,某用户A为普通用户,其关注的热门用户有用户B和用户C。当用户A向***请求展示可以看到的Feed数据时,***会根据该请求获取用户A的Feed队列A、用户A关注的热门用户B的Feed队列B和热门用户C的Feed队列C。
其中,所述的每个Feed队列都可以是一个有序的队列。根据实际应用的不同,所述“有序”可以是按照时间顺序,或按照数据大小的顺序,或按照数据标识的顺序,等等排序方式进行排序。总之,所述Feed队列是一个有序的队列,即Feed队列中的所有Feed元素已按照某种方式排好了序。
对于微博网站、交友互动平台等Feed应用***,由于用户一般只关注最近一段时间内的Feed,所以***中每个Feed队列中的元素都可按照时间倒序进行排列,即将发布时间最新的Feed元素排在队列的最前端。
步骤2,从每个有序消息队列中分别按序读取一个消息数据,并将所读取的多个消息数据放入排序集合;
仍以Feed应用***为例,所述排序集合用于对多个Feed队列的Feed数据进行合并和排序,排序集合的大小等于需进行排序的有序Feed队列的个数。例如,需进行排序的有序Feed队列共有3个,则对应的排序集合能存放3个Feed数据。
由于每个Feed队列都是有序的,所以从队列中顺次读取的Feed数据也是有序的。如果Feed队列是按照时间倒序排序,那么读取时就可以从Feed队列中按照时间倒序读取第一个Feed数据,所述第一个Feed数据是指排在队列最前端的Feed数据,也是发布时间最新的Feed数据。
当然,在其他应用中,针对所述按照时间倒序排列的Feed队列,也可以从队尾开始读取Feed数据,这时读取出来的Feed数据就是发布时间最早的Feed数据。也就是说,上述“按序读取”的顺序不一定必须与“有序Feed队列”中Feed数据的排列顺序一致。
步骤3,对所述排序集合中的所有消息数据进行排序,得到排序结果,并从所述排序结果中选择一个消息数据输出;
仍以Feed应用***为例,由于排序集合中的Feed数据来自不同的Feed队列,并无顺序,需要进行排序后才能选出符合应用要求的Feed数据输出。在对排序集合中的所有Feed数据进行排序时,需按照应用要求选择排序方式,排序方式不一定必须与上述步骤1中“有序Feed队列”中Feed数据的排列顺序一致,但要与上述步骤2中“按序读取”的顺序保持一致。
例如,如果应用要求输出最近一段时间内的Feed,则上述步骤2中“按序读取”是按照时间倒序读取队列中的Feed,并且在步骤3中,排序集合中的所有Feed数据也是按照时间倒序排序,并选择排序结果中的第一个Feed数据输出,即输出排序结果中发布时间最新的Feed数据。
步骤4,从所述输出的消息数据所属的Feed队列中再按序读取一个消息数据,并将所读取的消息数据放入所述排序集合;
步骤S3,重复步骤3和步骤4,直到输出的所有消息数据满足所述请求要求。
其中,所述请求要求可以是数量上的,如当前屏幕显示数量等;也可以是时间上的,如当天,本周的消息数据等,或者数量、时间等各种条件的组合。
例如,步骤3输出的Feed数据属于Feed队列A,则继续从Feed队列A按序读取一个Feed数据再放入所述排序集合,再次与排序集合中原来存放的Feed队列B和Feed队列C的Feed数据一起进行排序。按照此方式重复循环,直到输出的所有Feed数据个数满足所述请求要求的数量为止,如***设置每一页展示的Feed数据个数为10个,当用户请求获取第一页的输出结果时,排序集合输出10个Feed数据即停止所述循环;当用户点击“下一页”继续请求获取第二页的输出结果时,***再从步骤1开始执行。
需要注意的是,上述循环执行过程中,步骤3中每次的排序方式需一致,步骤4中每次按序读取Feed数据的顺序需一致。
可选的,如果所述请求为Feed数据查询请求,***还可以将满足请求个数的所有Feed数据展示在用户客户端上,供用户浏览。当然,根据实际应用的不同,还可以对输出的Feed数据进行其他后续处理,如进行统计分析或传送给其他应用***等。
下面通过两个例子对上述流程进行解释说明。
例1:
参照图3,是本申请例1中对两个Feed队列进行合并排序的示意图。
假设用户A为普通用户,用户A关注热门用户B,当用户A向Feed应用***发送查询请求,请求获取用户A可以看到的第一页的Feed数据时,***首先获取用户A的Feed队列,以及用户A关注的热门用户B的Feed队列,并对这两个Feed队列进行以下处理:
S1,分别从用户A的Feed队列和用户B的Feed队列中各取出第一个Feed数据,然后将这两个Feed数据放入到排序集合中;
例如,分别读取A0和B0放入排序集合;
S2,对放入到排序集合中的两个Feed数据进行排序,得到按照时间倒序排列的一个结果;
假设按照时间倒序排列的结果是:B0、A0;
S3,对外输出结果,当从排序集合中取出了一个排在最前面的Feed数据之后,会从这个Feed数据所属的那个Feed队列中再取出下一个Feed数据放到排序集合中,并重新对这个排序集合中的所有Feed数据进行排序;
例如,将B0输出,然后再从用户B的Feed队列中读取B1并放入排序集合,此时排序集合中的Feed数据为A0和B1,对A0和B1排序;
S4,排序集合不断地输出结果,不断重复S3中的动作,直到满足查询要求的Feed数量为止结束。
若输出A0,则重复S3,从用户A的Feed队列中读取A1并放入排序集合,此时排序集合中的Feed数据为A1和B1,对A1和B1排序,……,依此循环,直到满足查询要求的Feed数量为止结束。
以上是在两个用户Feed队列的场景下说明了本申请所述方法的执行步骤,对于超过两个用户Feed队列的情况,只需要扩大排序集合,使其大小等于需要进行归并排序的Feed队列数量就可以,具体参见例2。
例2:
参照图4,是本申请例2中对三个Feed队列进行合并排序的示意图。
S1,分别从用户A的Feed队列、用户B的Feed队列和用户C的Feed队列中各取出第一个Feed数据A0、B0和C0,然后将这三个Feed数据放入到排序集合中;
S2,对放入到排序集合中的三个Feed数据进行排序,得到按照时间倒序排列的一个结果;
假设按照时间倒序排列的结果是:C0、A0、B0;
S3,对外输出C0,并从C0所属的用户C的Feed队列中再取出下一个Feed数据C1放到排序集合中,并重新对这个排序集合中的所有Feed数据进行排序;
此时,排序集合中的Feed数据为A0、B0和C1;
S4,排序集合不断地输出结果,不断重复S3中的动作,直到满足查询要求的Feed数量为止结束。
若输出A0,则重复S3,从用户A的Feed队列中读取A1并放入排序集合,此时排序集合中的Feed数据为A1、B0和C1,……,依此循环,直到满足查询要求的Feed数量为止结束。
此外,基于例1和例2还需要说明的是,在上述循环截止之前,还可能存在以下特殊情况:
当需进行排序的多个有序Feed队列中,只有一个Feed队列不为空,其余Feed队列均为空(即Feed数据个数为零)时,重复将所述不为空的Feed队列中的Feed数据按序读取并输出,直到输出的所有Feed数据个数满足所述请求要求的数量为止。
例如,图3所示的两个Feed队列的排序过程中,会出现某个用户的Feed队列中没有更多Feed数据的情况。假设用户A的Feed队列比用户B的Feed队列短,且某一次查询中,执行过程中发现用户A的Feed队列已经被耗尽,这个时候,***会删除排序集合中的一个Feed数据,也就是说这个时候排序集合中就只剩下一个Feed数据了,后面的输出就没有排序的过程了,直接将用户B的Feed队列中的Feed数据对外输出。
同样,对于图4所示的三个Feed队列的排序过程,也会出现某个用户的Feed队列中没有更多Feed数据的情况。假设某一次查询中,发现用户A和用户B的Feed队列已经被耗尽,此时***会删除排序集合中的两个Feed数据,后面的输出就没有排序的过程了,直接将用户C的Feed队列中的Feed数据对外输出。但是,如果执行过程中只有用户A的Feed队列已经被耗尽,***会删除排序集合中的一个Feed数据,使得排序集合中只剩下两个Feed数据,此时排序集合还会按照前述的方法,对用户B的Feed队列和用户C的Feed队列中的Feed数据进行排序输出。
综上所述,本申请实施例所述的方法借助于每个消息队列都是有序队列(如已经按照时间排好序)的特点,只对满足用户请求(即用户确实需要)的那部分数据进行排序,而不需要每次都对所有参与排序的Feed队列进行排序,从而提高了计算资源的利用,进而提升了用户查询消息时的响应时间。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请所必须的。
基于上述方法实施例的说明,本申请还提供了相应的装置实施例,来实现上述方法实施例所述的内容。
参照图5,是本申请实施例所述一种消息数据的处理装置结构图。
所述Feed数据处理装置可以包括队列创建模块10、队列获取模块20、消息数据读取模块30、排序输出模块40和循环调用模块50,其中,
队列创建模块10,用于为对应用户账户创建消息队列,并将用户发布和接收的消息数据放入对应的消息队列中;
队列获取模块20,用于接收针对某个用户账户的消息数据查询请求,并依据所述消息数据查询请求获取需进行排序的多个有序消息队列,所述需进行排序的多个有序消息队列包含该用户账户的消息队列,以及与该用户账户关联的热门用户账户的消息队列;
消息数据读取模块30,用于从每个有序消息队列中分别按序读取一个消息数据,并将所读取的多个消息数据放入排序集合;
排序输出模块40,用于对所述排序集合中的所有消息数据进行排序,得到排序结果,并从所述排序结果中选择一个消息数据输出;
循环调用模块50,用于重复调用所述消息数据读取模块30和排序输出模块40,从所述输出的消息数据所属的消息队列中再按序读取一个消息数据,并将所读取的消息数据放入所述排序集合进行排序输出,直到输出的所有消息数据满足所述请求要求。
其中,所述排序集合的大小等于需进行排序的有序消息队列的个数。
可选的,所述有序消息队列中的消息数据是按照时间倒序排列;
而且,所述消息数据读取模块30是从每个有序消息队列中分别按照时间倒序读取第一个消息数据;
所述排序输出模块40是对排序集合中的所有消息数据按照时间倒序进行排序,得到排序结果,并从所述排序结果中选择第一个消息数据输出。
在本申请的另一装置实施例中,参照图6所示,所述消息数据处理装置还可以包括:
特殊处理模块60,用于当需进行排序的多个有序消息队列中,只有一个消息队列不为空时,重复将所述不为空的消息队列中的消息数据按序读取并输出,直到输出的所有消息数据个数满足所述请求要求的数量为止。
在本申请的另一装置实施例中,参照图6所示,所述消息数据处理装置还可以包括:
展示模块60,用于将输出的所有消息数据进行展示。
对于上述消息数据处理装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
以上对本申请所提供的一种消息数据的处理方法及装置,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种消息数据的处理方法,其特征在于,包括:
为对应用户账户创建消息队列,并将用户发布和接收的消息数据放入对应的消息队列中;
接收针对某个用户账户的消息数据查询请求,并执行以下步骤:
步骤1,依据所述消息数据查询请求获取需进行排序的多个有序消息队列,所述需进行排序的多个有序消息队列包含该用户账户的消息队列,以及与该用户账户关联的热门用户账户的消息队列;
步骤2,从每个有序消息队列中分别按序读取一个消息数据,并将所读取的多个消息数据放入排序集合;
步骤3,对所述排序集合中的所有消息数据进行排序,得到排序结果,并从所述排序结果中选择一个消息数据输出;
步骤4,从所述输出的消息数据所属的消息队列中再按序读取一个消息数据,并将所读取的消息数据放入所述排序集合;
重复步骤3和步骤4,直到输出的所有消息数据满足所述请求要求。
2.根据权利要求1所述的方法,其特征在于,在循环截止之前还包括:
当需进行排序的多个有序消息队列中,只有一个消息队列不为空时,重复将所述不为空的消息队列中的消息数据按序读取并输出,直到输出的所有消息数据个数满足所述请求要求的数量为止。
3.根据权利要求1或2所述的方法,其特征在于,所述有序消息队列中的消息数据是按照时间倒序排列;所述从消息队列中按序读取一个消息数据包括:从消息队列中按照时间倒序读取第一个消息数据;
所述对排序集合中的所有消息数据进行排序包括:对排序集合中的所有消息数据按照时间倒序进行排序;
所述从排序结果中选择一个消息数据输出包括:从按照时间倒序的排序结果中选择第一个消息数据输出。
4.根据权利要求1或2所述的方法,其特征在于:
所述排序集合的大小等于需进行排序的有序消息队列的个数。
5.根据权利要求1或2所述的方法,其特征在于,还包括:
将输出的所有消息数据进行展示。
6.一种消息数据的处理装置,其特征在于,包括:
队列创建模块,用于为对应用户账户创建消息队列,并将用户发布和接收的消息数据放入对应的消息队列中;
队列获取模块,用于接收针对某个用户账户的消息数据查询请求,并依据所述消息数据查询请求获取需进行排序的多个有序消息队列,所述需进行排序的多个有序消息队列包含该用户账户的消息队列,以及与该用户账户关联的热门用户账户的消息队列;
消息数据读取模块,用于从每个有序消息队列中分别按序读取一个消息数据,并将所读取的多个消息数据放入排序集合;
排序输出模块,用于对所述排序集合中的所有消息数据进行排序,得到排序结果,并从所述排序结果中选择一个消息数据输出;
循环调用模块,用于重复调用所述消息数据读取模块和排序输出模块,从所述输出的消息数据所属的消息队列中再按序读取一个消息数据,并将所读取的消息数据放入所述排序集合进行排序输出,直到输出的所有消息数据满足所述请求要求。
7.根据权利要求6所述的装置,其特征在于,还包括:
特殊处理模块,用于当需进行排序的多个有序消息队列中,只有一个消息队列不为空时,重复将所述不为空的消息队列中的消息数据按序读取并输出,直到输出的所有消息数据个数满足所述请求要求的数量为止。
8.根据权利要求6或7所述的装置,其特征在于,所述有序消息队列中的消息数据是按照时间倒序排列;所述消息数据读取模块是从每个有序消息队列中分别按照时间倒序读取第一个消息数据;
所述排序输出模块是对排序集合中的所有消息数据按照时间倒序进行排序,得到排序结果,并从所述排序结果中选择第一个消息数据输出。
9.根据权利要求6或7所述的装置,其特征在于:
所述排序集合的大小等于需进行排序的有序消息队列的个数。
10.根据权利要求6或7所述的装置,其特征在于,还包括:
展示模块,用于将输出的所有消息数据进行展示。
CN201110306094.1A 2011-10-11 2011-10-11 一种消息数据的处理方法及装置 Active CN103051511B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201110306094.1A CN103051511B (zh) 2011-10-11 2011-10-11 一种消息数据的处理方法及装置
HK13106362.2A HK1179436A1 (zh) 2011-10-11 2013-05-29 種消息數據的處理方法及裝置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201110306094.1A CN103051511B (zh) 2011-10-11 2011-10-11 一种消息数据的处理方法及装置

Publications (2)

Publication Number Publication Date
CN103051511A CN103051511A (zh) 2013-04-17
CN103051511B true CN103051511B (zh) 2015-10-07

Family

ID=48064016

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201110306094.1A Active CN103051511B (zh) 2011-10-11 2011-10-11 一种消息数据的处理方法及装置

Country Status (2)

Country Link
CN (1) CN103051511B (zh)
HK (1) HK1179436A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104125163B (zh) * 2013-04-25 2020-04-07 腾讯科技(深圳)有限公司 一种数据处理方法、装置及终端
CN104281605B (zh) * 2013-07-08 2017-12-26 北京齐尔布莱特科技有限公司 一种社交网站Feed流推送方法
CN106201432B (zh) * 2016-07-19 2019-08-06 网易(杭州)网络有限公司 目标对象的信息的处理方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101425093A (zh) * 2008-12-05 2009-05-06 腾讯科技(深圳)有限公司 基于社会性网络关系链的联系人动态内容聚合方法及***
CN101650741A (zh) * 2009-08-27 2010-02-17 中国电信股份有限公司 一种分布式全文检索的索引实时更新的方法和***
CN102045273A (zh) * 2010-12-28 2011-05-04 位涛 一种通过页面关注将互联网信息订阅到社交网络的方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8645377B2 (en) * 2010-01-15 2014-02-04 Microsoft Corporation Aggregating data from a work queue

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101425093A (zh) * 2008-12-05 2009-05-06 腾讯科技(深圳)有限公司 基于社会性网络关系链的联系人动态内容聚合方法及***
CN101650741A (zh) * 2009-08-27 2010-02-17 中国电信股份有限公司 一种分布式全文检索的索引实时更新的方法和***
CN102045273A (zh) * 2010-12-28 2011-05-04 位涛 一种通过页面关注将互联网信息订阅到社交网络的方法

Also Published As

Publication number Publication date
CN103051511A (zh) 2013-04-17
HK1179436A1 (zh) 2013-09-27

Similar Documents

Publication Publication Date Title
CN102426542B (zh) 数据中心资源管理***及作业调度方法
US9607049B2 (en) Systems and methods to build and utilize a search infrastructure
JP2019537131A (ja) 情報を提供するための方法及び装置
US9710557B2 (en) Partitioning a search space for distributed crawling
CN105451087A (zh) 弹幕信息的推送方法、终端、历史数据服务器及***
CN102780768A (zh) 一种大并发量请求的处理方法及处理***
CN103186834A (zh) 业务流程配置方法和装置
US9852183B2 (en) Information providing method and system
CN111695840B (zh) 一种实现流程控制的方法和装置
CN101324947A (zh) 一种自动化点餐和结算的方法及***
CN102279960A (zh) 一种包含用户元素的广告发布控制方法以及***
CN103051511B (zh) 一种消息数据的处理方法及装置
CN104216698A (zh) 一种注册网页方法及相关装置
CN103488655A (zh) 复合模型数据处理方法及***
CN111125518A (zh) 家电信息推荐的***及方法
CN107704357B (zh) 日志生成方法和装置
CN106372822A (zh) 业务对象预约时段处理方法及装置
CN100452704C (zh) 一种发布博客文章的方法和***
CN103544036A (zh) 页面加载方法、终端及***
CN103795758A (zh) 内容浏览、生成及交互方法,内容浏览终端、服务器及***
CN110188258B (zh) 使用爬虫获取外部数据的方法及装置
CN106817592B (zh) 首页推荐排期方法及装置
CN109035070A (zh) 一种基于物联网搜索的餐饮***
CN111309932B (zh) 评论数据的查询方法、装置、设备及存储介质
CN113965900B (zh) 流量资源动态扩容的方法、装置、计算设备及存储介质

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1179436

Country of ref document: HK

C14 Grant of patent or utility model
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: GR

Ref document number: 1179436

Country of ref document: HK

TR01 Transfer of patent right

Effective date of registration: 20201230

Address after: Room 701-26, 7th floor, 2 Haidian East 3rd Street, Haidian District, Beijing

Patentee after: YOUMENG TONGXIN (BEIJING) TECHNOLOGY Co.,Ltd.

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Patentee before: Alibaba Group Holding Ltd.

TR01 Transfer of patent right