CN103944799A - 消息处理方法及*** - Google Patents

Abstract

本申请公开了消息处理方法及***，其中，所述方法包括：获取当前用户的用户标识信息；根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息；所述非***消息为以点对点的方式发送给当前用户的消息；获取公共存储区保存的发送给该当前用户的***消息，并提取各条***消息对应的发送时间；所述***消息为以群发的方式发送给当前用户的消息；根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合，根据聚合的结果返回发送给当前用户的消息的信息。通过本申请，实现了非***消息与***消息的统一展现，避免了因数据不准确而给用户造成的干扰。

Description

消息处理方法及***

技术领域

本申请涉及数据处理技术领域，特别是涉及消息处理方法及***。

背景技术

在一些大型的购物类等网站中，网站管理员通常需要向用户发送一些消息，例如通知用户升级的消息、购买了某商品的消息、在一段时间内购买了多少件商品的统计消息，等等。最初这些消息通常是以点对点形式向目标用户发布的私有消息、通知、提醒等，这种消息由于具有个性化用户通知的特点，因此，被称为非***消息，在存储层中是一对一存储在关系型数据库中。

但是，在向用户发送消息的过程中，经常会存在一些需要发送给多个用户甚至是全部用户的消息，例如，某大型的商品促销消息等等，这类消息属于全局型的消息。虽然也可以采用点对点的形式向用户发送非***消息，但是现在大型互联网公司的用户群体一般都在百万、千万级以上级别，当向大规模用户发送点对点的非***消息时，数据的送达延时会非常大，无法满足互联网快速的业务发展现状；同时，如果数据内容重复，则会产生大量的冗余数据，非常占用***资源。

由此，***消息便应运而生了。所谓***消息，就是网站管理者以信息广播形式向目标用户发布的公开的消息、公告、通知、提示等。这种***消息具有群发性、高可达性等消息特性。并且，只需要在数据层的公共存储区中存储一份，不需要一对一存储在各个用户的关系型数据库中，还可对其展现进行统一地管理。

当然，虽然***消息具有很多优点，但是，非***消息也是不可替代的，对于同一用户而言，可能既会收到***消息也会收到非***消息。但是，由于两者消息的存储方式等存在差异，导致用户数据不准确，给用户造成干扰，因此，如何在用户层进行消息处理和展现，是需要解决的技术问题。

发明内容

本申请提供了消息处理方法及***，提供了在非***消息与***消息并存的情况下，消息展现过程的处理方案，实现了非***消息与***消息的统一展现，避免了因数据不准确而给用户造成的干扰。

本申请提供了如下方案：

一种消息处理方法，包括：

获取当前用户的用户标识信息；

根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息；所述非***消息为以点对点的方式发送给当前用户的消息；

获取公共存储区保存的发送给该当前用户的***消息，并提取各条***消息对应的发送时间；所述***消息为以群发的方式发送给当前用户的消息；

根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合，根据聚合的结果返回发送给当前用户的消息的信息。

一种消息处理***，包括：

用户标识信息获取单元，用于获取当前用户的用户标识信息；

非***消息相关信息获取单元，用于根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息；所述非***消息为以点对点的方式发送给当前用户的消息；

***消息相关信息获取单元，用于获取公共存储区保存的发送给该当前用户的***消息，并提取各条***消息对应的发送时间；所述***消息为以群发的方式发送给当前用户的消息；

消息聚合单元，用于根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合，根据聚合的结果返回发送给当前用户的消息的信息。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请，在需要向用户展现与***发送的消息相关的信息时，一方面，可以根据用户标识信息获取到发送给该用户的非***消息的相关信息；另一方面，可以从公共存储区中获取到发送给该用户的***消息的信息，并从中提取出每条***消息的发送时间，这样，就可以根据这些信息对非***信息以及***消息进行聚合，并根据聚合后的结果返回用于展现发送给当前用户的消息的相关数据，以便在客户端对发送给当前用户的消息的情况进行展现，避免因数据不准确而给用户造成的干扰。可见，本申请实施例提供了在非***消息与***消息并存的情况下，消息展现过程的处理方案，实现了非***消息与***消息的统一展现。

具体在进行非***消息与***消息的聚合时，可以分别统计出当前用户未读的非***消息的数量，以及当前用户未读的***消息的数量，并根据这两方面的信息统计出当前用户未读的消息总数，以便客户端将该消息总数展现给用户。

或者，也可以分别获取到最近发送给当前用户的一条非***消息，以及最近发送给当前用户的一条***消息，然后比对这两条消息的发送时间，将发送时间距离当前时刻较近者确定为最近发送给当前用户的一条消息，并返回，以便客户端将其展现给用户。

再者，还可以根据发送给当前用户的各条非***消息以及***消息各自对应的发送时间，将非***消息以及***消息放在一起进行统一的排序，以便客户端按照此顺序进行各条消息的展现。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的另一方法的流程图；

图3是本申请实施例提供的第一***的示意图；

图4是本申请实施例提供的第二***的示意图；

图5是本申请实施例提供的第三***的示意图；

图6是本申请实施例提供的第四***的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

首先需要说明的是，在本申请实施例中，发送给用户的***消息是保存在数据层的公共存储区，所谓的公共存储区可以是一种Key/Value结构数据的解决方案，它默认支持基于内存和文件的两种存储方式，分别和通常所说的缓存和持久化存储对应。

对于非***消息与***消息而言，消息的存储格式会有所不同，例如，非***消息的存储格式一般如表1所示，括号中的内容为对对应字段的解释：

表1

***消息的存储格式一般如表2所示，括号中的内容为对对应字段的解释：

表2

从表1及表2可以看出，无论是***消息还是非***消息，其存储格式中都包括消息ID、发件人ID、消息主题及消息内容字段，但也存在不同之处。首先，对于非***消息而言，由于具有个性化的特点，一般来说都是发送给某特定的用户，因此，在消息中一般要携带收件人ID字段，而***消息一般是具有群发的特点，可以默认发送给所有用户，或者某用户群体等等，因此，一般不会有收件人ID字段。其次，同样由于非***消息的接收方是某特定的用户，该用户是否读取了某消息，是否删除了某消息等都是可以确定的，因此，非***消息会带有消息状态字段，用于指明消息是未读、已读或者删除；但是，***消息是发送给多个用户的，其中某个用户的读取行为并不能代表其他用户，对于某消息而言，可能用户甲已经读取，但是用户乙却尚未读取，等等，因此，无法确定某条***消息当前处于未读或者已读状态，其存储格式中也就不会带有消息状态字段。最后，对于***消息而言，一般会带有发送时间字段，而非***消息则不带有该字段，当然，***中仍然会通过其他的方式来记录每条非***消息的发送时间。

可见，非***消息与***消息在存储格式上具有比较明显的差异，本申请实施例的目的就是，在非***消息与***消息并存的情况下，将两种消息相聚合，统一地向用户提供发送给该用户的消息的相关信息。具体在提供这些相关信息时，一般有以下三个方面的内容：

第一，当前用户未读的消息条目数量是多少；

第二，最近发送给当前用户的一条消息是什么；

第三，在用户请求展现消息时，能够将发送给该当前用户的消息展现给当前用户。

在具体实现时，由于***消息与非***消息的存储方式不同，因此，在提供以上各种信息时，需要进行特殊的处理。下面就对本申请实施例提供的特殊处理方式进行详细地介绍。

首先，对于当前用户未读的消息条目数量这一信息，需要分别统计出未读的非***消息的数量，以及未读的***消息的数量。其中，对于非***消息而言，由于每条消息都带有消息状态字段，用以表明消息处于未读、已读或删除状态，因此，就可以直接在关系型数据库中做统计(count)计算，查询所有消息状态字段为“未读”的消息，并统计出未读非***消息的数量。或者，关于非***消息中的未读消息数量，会在公共存储区的缓存中为用户设置一计数器，***给用户发送一条非***消息，计数器就自加1；用户读取或删除一条非***消息，计数器就减1，因此，也可以通过查询该计数器的当前值来获取当前用户未读的非***消息的数量。

而***消息的存储方式不同，***消息队列中的消息是按照发送时间Send_Date顺序存储，每条消息都有唯一的发送时间。因此，统计未读消息数时，可以从公共存储区中读取当前用户上一次查询消息的时间信息，***返回此时间点到当前时间点为止的***消息列表。具体过程可以是：在用户每次查询***消息时，将用户当前访问的时间Tuser信息存储在公共存储区的高速缓存中；当用户再次请求时，***会根据***消息队列的时间Tqueue＝[T1，T2，T3…Tn-1，Tn](Tk＜Tk+1)与Tuser进行对比，找到离Tuser最近的时间点Tk，返回[Tk，Tk+1…Tn]的***消息队列。也即，将发送时间晚于上一次查询时间点的***消息，确定为该当前用户未读的***消息。

例如，假设在实际的产品中，可以在网站页面的最上方等处显示“消息”字样，并且该字样可以设置为可执行按钮等形式，作为用户查询消息的入口，用户可以通过点击该按钮，发起查询消息的请求。假设，某用户上次点击该按钮查询消息的时间是2012年12月1日，***就会将该时间记录在缓存中；该用户下次查询的时间是2012年12月20日，在此期间，***向该用户发送了5条***消息，于是统计出的该用户未读的***消息数量为5，也就是说，这5条***消息都是在2012年12月1日之后发送给该用户的，由于2012年12月1日时该用户查询过消息，因此，可以将该日期之前发送的***消息作为该用户已读的***消息，仅将该日期之后发送的***消息作为该用户的未读***消息。当然，在实际应用中，时间点的精度还可以精确到小时、分、秒等，具体可以根据实际的需要而定。

在统计出当前用户未读的非***消息的数量以及***消息的数量之后，就可以这两部分统计数据加和起来，作为该用户未读的消息的总条目数量返回给客户端。客户端可以将该数量信息显示在用户界面中。例如，如前述的例子，可以在网站页面的最上方等处显示“消息”字样，在此基础上，可以在该字样右上方等处可以显示有该用户未读消息的总条目数量信息。

下面结合图1对上述统计未读消息数量的聚合过程进行更为详细地介绍。

S101：接收到获取未读取消息数量的请求；

此时，一方面，通过以下步骤S102获取用户未读的非***消息的数量，另一方面，通过以下步骤S103-S104获取用户未读的***消息的数量。

S102：从持久化层(也即当前用户对应的关系型数据库)中读取当前用户未读的非***消息数量N1；具体可以根据统计消息状态为“未读”的非***消息数量来确定，或者，也可以读取公共存储区的缓存中为该用户设置的计数器的当前数值来确定；

S103：获取用户未读的***消息的数量：从公共存储区的缓存中读取该用户上次查询消息数据的时间点T1；

S104：从公共存储区的缓存中获取发送时间晚于T1的***消息，并统计这些***消息的数量N2；

S105：将当前时刻的时间点T2更新到公共存储区的缓存；

S106：计算N1与N2之和，得到当前用户未读的消息数量。

对于所谓的最近发送给当前用户的一条消息，也就是说，可以将最近发送给该用户的一条消息以在前台浮出等形式提醒给当前用户，引起该当前用户的注意。其中，如果仅存在非***消息，则很容易获取该信息。这是因为，***在公共存储区的缓存中给每个用户预留最近一条记录的存储区，每次给用户发送非***消息时就会更新缓存中的消息记录，这样读取的消息记录就是最近一条非***消息了。但是，在存在***消息的情况下，***发送一条新的***消息时，并不会主动刷新上千万用户的消息缓存区。因此，就需要在用户请求查询时聚合***消息和非***消息，得出最近发送给当前用户的一条消息。具体实现时，聚合的方法可以是：

步骤一：从缓冲区为该当前用户预留的存储区中读取非***消息的最近一条消息Munsys，以及发送时间Tunsys；

步骤二：从***消息队列读取用户未读消息列表中的最近一条消息Msys，以及发送时间Tsys；

步骤三：比较Tunsys与Tsys，如果Tunsys＞Tsys(也即Munsys的发送时间晚于Msys的发送时间)，则Munsys为最近发送给当前用户的消息；如果Tunsys＜Tsys(也即Munsys的发送时间早于Msys的发送时间)，则Msys为最近发送给当前用户的消息。

关于将发送给该当前用户的消息展现给当前用户，可以首先从该当前用户的关系型数据库中查找到发送给该用户的非***消息(可以包括已读的以及未读的)，并分别获取各条非***消息各自对应的发送时间；并且，还可以从公共存储区获取发送给当前用户的***消息(同样可以包括已读的以及未读的)，以及同样分别获取各条***消息对应的发送时间。然后，可以将各条非***消息以及***消息聚合在一起，并按照各自的发送时间进行排序(例如，发送时间越近的排序越靠前等等)，再按照排序后的顺序展现各条消息。

当然，在具体进行消息的展现时，可以为用户提供分类展现的操作入口，例如，首先可以提供一个“全部消息”的查看入口，用户从该入口进入之后，就可以将前述获取到的发送给该用户的全部非***消息以及全部***消息的标题等信息按照发送时间的顺序展现给当前用户。其中，由于能够获知哪些是未读的，因此，可以将其中保存的未读的非***消息或***消息进行与已读消息相区别的现实形式，例如，将未读的消息标题的字体加粗，等等。另外，还可以单独提供“未读”消息的查看入口，用户从该入口进入之后，可以仅将当前用户未读的消息以列表等形式展现给当前用户，同样可以按照各自的发送时间进行排序。另外，还可以有单独查看“***消息”的入口，或者“非***消息”的入口，非***消息的入口还可以进行进一步地细分，例如包括“我的成长”、“特权活动”等等，用户从不同的入口进入之后，都将与该入口的类别对应的消息以列表等形式向用户展现。

综上可见，本申请实施例相当于对非***消息以及***消息进行了聚合，然后再统一进行展现。具体而言，提供了一种消息处理方法，参见图2，该方法可以包括以下步骤：

S201：获取当前用户的用户标识信息；

在具体实现时，一般是在用户在***中注册，成为***的注册会员之后，***才会向用户发送非***消息或者***消息，并且在用户利用注册的用户名及密码等信息登录到***之后，才会向用户展现与这些消息相关的信息。在本申请实施例中，同样可以是在用户登录到***之后，再进行相应的消息处理操作。在用户登录到***之后，就可以根据用户的用户名等信息获取到用户标识信息，以便后续以此为依据获取当前用户的相关数据。需要说明的是，本申请实施例的执行主体可以是***服务器端运行的某程序，由于用户登录的过程也是登录到该***服务器端，因此，可以直接获取到用户的标识信息。

S202：根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息；所述非***消息为以点对点的方式发送给当前用户的消息；

在获取到用户标识信息之后，就可以首先根据该标识信息获取发送给该用户的非***消息的相关信息，这种相关信息也就是与后续的消息展现相关的信息。例如，可以根据用户标识信息查找该用户的关系型数据库，从中提取发送给用户的各条非***消息，同时还可以从中提取各条非***消息的发送时间、状态等信息，以便统计未读的非***消息的数量，或者用于后续对消息的排序等；或者，还可以根据用户标识信息查询公共存储区中为该当前用户设置的未读消息计数器，提取该计数器的值作为当前用户未读非***消息的数量，等等。另外，还可以是根据用户标识信息查询公共存储区中为该当前用户预留的最近一条消息的存储区中保存的信息，获取最近发送给当前用户的一条非***消息，并获取该条非***消息的发送时间，以用于后续确定用户最近接收到的一条消息是什么，等等。

S203：获取公共存储区保存的发送给该当前用户的***消息，并提取各条***消息对应的发送时间；所述***消息为以群发的方式发送给当前用户的消息；

在获取发送给该当前用户的非***消息的相关信息的同时，还可以获取公共存储区保存的发送给该当前用户的***消息，并提取出各条***消息对应的发送时间，以便为后续的聚合做准备。

需要说明的是，在实际应用中，***消息可能是发送给所有用户，但也可能是发送给某部分用户，对于这种仅发送给一部分用户的***消息而言，在公共存储区进行保存时，会同时保存接收者ID信息(一般会与用户的标识信息相对应)，因此，在从公共存储区获取发送给当前用户的***消息时，也可能会需要用到用户标识信息。这样，如果某***消息是发送给一部分用户，并且当前用户包括在这部分用户之中，则就可以根据用户标识信息获知此信息，然后将该***消息作为发送给该用户的***消息提取出来；显然，如果某***消息是发送给一部分用户，但是，当前用户并为包括在这部分用户之中，则就可以根据用户标识信息获知此信息，相应的，该***消息就不会作为发送给该用户的***消息被提取出来。与此同时，对于公共存储区中保存的未限定接收者ID的***消息而言，都可以作为发送给当前用户的***消息被提取出来。

S204：根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合，根据聚合的结果返回发送给当前用户的消息的信息。

在获取到非***消息与消息展现相关的信息以及***消息及其发送时间信息之后，就可以将非***消息与***消息进行聚合，然后返回聚合后的结果。例如，可以根据各条***消息的发送时间以及公共存储区中保存的该当前用户上次查询消息时的时间点，确定出当前用户未读的***消息，并统计出未读***消息的数量，这样就可以将该数量与之前获取到的未读非***消息的数量进行相加，得到当前用户未读的消息总数并返回。或者，还可以根据各条***消息的发送时间确定出最近发送的一条***消息，并将这条***消息的发送时间与之前获取到最近发送的一条非***消息的发送时间进行比较，将距离当前时刻较近者对应的消息确定为最近发送给该用户的一条消息；或者，还可以根据各条非***消息以及各条***消息的发送时间进行综合的排序，等等。

总之，在本申请实施例中，在需要向用户展现与***发送的消息相关的信息时，一方面，可以根据用户标识信息获取到发送给该用户的非***消息的相关信息；另一方面，可以从公共存储区中获取到发送给该用户的***消息的信息，并从中提取出每条***消息的发送时间，这样，就可以根据这些信息对非***信息以及***消息进行聚合，并根据聚合后的结果返回用于展现发送给当前用户的消息的相关数据，以便在客户端对发送给当前用户的消息的情况进行展现，避免因数据不准确而给用户造成的干扰。可见，本申请实施例提供了在非***消息与***消息并存的情况下，消息展现过程的处理方案，实现了非***消息与***消息的统一展现。

与本申请实施例提供的消息处理方法相对应，本申请实施例还提供了一种消息处理***，参见图3，该***可以包括：

用户标识信息获取单元301，用于获取当前用户的用户标识信息；

非***消息相关信息获取单元302，用于根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息；所述非***消息为以点对点的方式发送给当前用户的消息；

***消息相关信息获取单元303，用于获取公共存储区保存的发送给该当前用户的***消息，并提取各条***消息对应的发送时间；所述***消息为以群发的方式发送给当前用户的消息；

消息聚合单元304，用于根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合，根据聚合的结果返回发送给当前用户的消息的信息。

具体对非***消息与***消息进行聚合时，可以包括多个方面。其中一个方面可以是根据未读的非***消息的数量以及未读的***消息的数量，来统计用户未读的消息的总数量，并返回给客户端。为了统计未读的***消息的数量，可以根据各条***消息的发送时间与用户上次查询时刻对应的时间点，来确定出哪些消息是用户未读的***消息。为此，需要对用户每次查询时刻的时间点信息进行记录，相应的，参见图4，该***还可以包括：

时间点查询单元305，用于获取公共存储区记录的当前用户上次查询时刻的时间点；

所述非***消息相关信息获取单元302可以包括：

未读非***消息数量获取子单元3021，用于根据所述用户标识信息获取该当前用户的未读非***消息的数量；

所述消息聚合单元304可以包括：

未读***消息数量获取子单元3041，用将发送时间晚于所述上次查询时刻的时间点的***消息确定为该当前用户未读的***消息，并统计出当前用户的未读***消息的数量；

未读消息总数确定子单元3042，用于取所述当前用户的未读非***消息的数量与未读***消息的数量之和作为当前用户未读消息的条目总数，返回所述未读消息的条目总数。

其中，在实际应用中，获取未读非***消息的数量的实现方式可以有多种，在其中一种实现方式下，所述未读非***消息数量获取子单元3021包括：

数据库查询子单元，用于根据所述用户标识信息在对应的关系型数据库中获取该当前用户的非***消息的信息；

状态信息提取子单元，用于根据各条非***消息的状态字段信息，获取处于未读状态的非***消息；

数量统计子单元，用于通过统计处于未读状态的非***消息的数量，确定该当前用户的未读非***消息的数量。

或者，在另一种实现方式下，所述未读非***消息数量获取子单元3021可以包括：

计数器查询子单元，用于根据所述用户标识信息查询公共存储区中为该用户设置的未读消息计数器的值；

数量确定子单元，用于将所述未读消息计数器的值确定为该当前用户的未读非***消息的数量。

为了给后续统计未读***消息提供参考依据，该***还包括：

时间点保存单元，用于将当前时刻的时间点保存到所述公共存储区，该时间点可以覆盖之前保存的上一查询时刻的时间点信息。

另一方面，参见图5，所述非***消息相关信息获取单元302可以包括：

最近发送的非***消息获取子单元3022，用于根据公共存储区中为该当前用户预留的最近一条消息的存储区中保存的信息，获取最近发送给当前用户的一条非***消息，并获取该条非***消息的发送时间T1；

所述消息聚合单元304可以包括：

最近发送的***消息获取子单元3043，用于将发送时间距离当前时刻最近的***消息确定为最近发送给当前用户的一条***消息，并记录所述最近发送给当前用户的一条***消息的发送时间T2；

比较子单元3044，用于比较T1与T2，将距离当前时刻较近者对应的消息确定为最近发送给当前用户的一条消息，返回所述最近发送给当前用户的一条消息的提示信息。

再一方面，参见图6，所述非***消息相关信息获取单元302可以包括：

非***消息发送时间获取子单元3023，用于根据所述用户标识信息查询该当前用户的关系型数据库，获取发送给该当前用户的各条非***消息及各自对应的发送时间；

所述消息聚合单元304包括：

集合生成子单元3045，用于将各条非***消息以及各条***消息加入到同一消息集合中；

排序子单元3046，用于按照发送时间对所述消息集合中的各条消息进行排序，返回按照发送时间排序后的各条消息。

由于有些***消息是发送给指定的部分用户，因此，在这样的情况下，所述***消息相关信息获取单元303具体可以用于：

根据当前用户的用户标识信息，获取公共存储区保存的发送给该当前用户的***消息。

总之，在本申请实施例提供的上述消息处理***中，在需要向用户展现与***发送的消息相关的信息时，一方面可以根据用户标识信息获取到发送给该用户的非***消息的相关信息，另一方面可以从公共存储区中获取到发送给该用户的***消息的信息，并从中提取出每条***消息的发送时间，这样，就可以根据这些信息对非***信息以及***消息进行聚合，并根据聚合后的结果返回用于展现发送给当前用户的消息的相关数据，以便在客户端对发送给当前用户的消息的情况进行展现。可见，本申请实施例提供了在非***消息与***消息并存的情况下，消息展现过程的处理方案，实现了非***消息与***消息的统一展现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***或***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的***及***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的消息处理方法及***，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种消息处理方法，其特征在于，包括：

获取当前用户的用户标识信息；

根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息；所述非***消息为以点对点的方式发送给当前用户的消息；

获取公共存储区保存的发送给该当前用户的***消息，并提取各条***消息对应的发送时间；所述***消息为以群发的方式发送给当前用户的消息；

根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合，根据聚合的结果返回发送给当前用户的消息的信息。

2.根据权利要求1所述的方法，其特征在于，还包括：

获取公共存储区记录的当前用户上次查询时刻的时间点；

所述根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息包括：

根据所述用户标识信息获取该当前用户的未读非***消息的数量；

所述根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合包括：

将发送时间晚于所述上次查询时刻的时间点的***消息确定为该当前用户未读的***消息，并统计出当前用户的未读***消息的数量；

取所述当前用户的未读非***消息的数量与未读***消息的数量之和作为当前用户未读消息的条目总数，返回所述未读消息的条目总数。

3.根据权利要求2所述的方法，其特征在于，所述根据所述用户标识信息获取该当前用户的未读非***消息的数量包括：

根据所述用户标识信息在对应的关系型数据库中获取该当前用户的非***消息的信息；

根据各条非***消息的状态字段信息，获取处于未读状态的非***消息；

通过统计处于未读状态的非***消息的数量，确定该当前用户的未读非***消息的数量。

4.根据权利要求2所述的方法，其特征在于，所述根据所述用户标识信息获取该当前用户的未读非***消息的数量包括：

根据所述用户标识信息查询公共存储区中为该用户设置的未读消息计数器的值；

将所述未读消息计数器的值确定为该当前用户的未读非***消息的数量。

5.根据权利要求2所述的方法，其特征在于，还包括：

将当前时刻的时间点保存到所述公共存储区。

6.根据权利要求1所述的方法，其特征在于，所述根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息包括：

根据公共存储区中为该当前用户预留的最近一条消息的存储区中保存的信息，获取最近发送给当前用户的一条非***消息，并获取该条非***消息的发送时间T1；

所述根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合包括：

将发送时间距离当前时刻最近的***消息确定为最近发送给当前用户的一条***消息，并记录所述最近发送给当前用户的一条***消息的发送时间T2；

比较T1与T2，将距离当前时刻较近者对应的消息确定为最近发送给当前用户的一条消息，返回所述最近发送给当前用户的一条消息的提示信息。

7.根据权利要求1所述的方法，其特征在于，所述根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息包括：

根据所述用户标识信息查询该当前用户的关系型数据库，获取发送给该当前用户的各条非***消息及各自对应的发送时间；

所述根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合包括：

将各条非***消息以及各条***消息加入到同一消息集合中；

按照发送时间对所述消息集合中的各条消息进行排序，返回按照发送时间排序后的各条消息。

8.根据权利要求1至6任一项所述的方法，其特征在于，所述获取公共存储区保存的发送给该当前用户的***消息包括：

根据当前用户的用户标识信息，获取公共存储区保存的发送给该当前用户的***消息。

9.一种消息处理***，其特征在于，包括：

用户标识信息获取单元，用于获取当前用户的用户标识信息；

非***消息相关信息获取单元，用于根据所述用户标识信息获取发送给该当前用户的非***消息的相关信息；所述非***消息为以点对点的方式发送给当前用户的消息；

***消息相关信息获取单元，用于获取公共存储区保存的发送给该当前用户的***消息，并提取各条***消息对应的发送时间；所述***消息为以群发的方式发送给当前用户的消息；

消息聚合单元，用于根据获取到的所述非***消息的相关信息、***消息及其对应的发送时间，对所述非***消息以及***消息进行聚合，根据聚合的结果返回发送给当前用户的消息的信息。

10.根据权利要求9所述的***，其特征在于，还包括：

时间点查询单元，用于获取公共存储区记录的当前用户上次查询时刻的时间点；

所述非***消息相关信息获取单元包括：

未读非***消息数量获取子单元，用于根据所述用户标识信息获取该当前用户的未读非***消息的数量；

所述消息聚合单元包括：

未读***消息数量获取子单元，用将发送时间晚于所述上次查询时刻的时间点的***消息确定为该当前用户未读的***消息，并统计出当前用户的未读***消息的数量；

未读消息总数确定子单元，用于取所述当前用户的未读非***消息的数量与未读***消息的数量之和作为当前用户未读消息的条目总数，返回所述未读消息的条目总数。