CN105099894A - 消息推送方法、装置及系统 - Google Patents

Abstract

本发明公开了一种消息推送方法、装置及系统，属于通信技术领域。所述方法包括：通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；获取动态信息的消息ID；向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

Description

消息推送方法、装置及系统

技术领域

本发明涉及通信技术领域，特别涉及一种消息推送方法、装置及系统。

背景技术

在各种即时通信程序、团队语音工具、直播室等社交类客户端中，用户通常都会发布一些动态信息表达自己的心情。

在当前用户发布新的动态信息后，服务器会检测当前用户的好友列表中的所有好友，将当前用户发布的动态信息ID推送到当前用户的好友列表中所有好友的消息箱中，当前用户的好友根据消息箱中的动态信息ID读取当前用户发布的动态信息。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟。

发明内容

为了解决存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重延迟的问题，本发明实施例提供了一种消息推送方法、装置及系统。所述技术方案如下：

第一方面，提供了一种消息推送的方法，该方法包括：

接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；

获取动态信息的消息标识ID；

查询发布方帐号的好友列表中的活跃帐号；

向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息。

在一种可能的实现方式中，向活跃帐号的消息箱推送动态信息之后，还包括：

接收好友列表中的活跃帐号的客户端发送的信息获取请求，信息获取请求携带有从活跃帐号的消息箱获取的消息ID；

根据消息ID向活跃帐号的客户端反馈动态信息。

在一种可能的实现方式中，该方法，还包括：

接收好友列表中的非活跃帐号的客户端发送的关系获取请求，关系获取请求用于获取非活跃帐号的好友列表；

根据关系获取请求向非活跃帐号的客户端发送非活跃帐号的好友列表；

接收非活跃帐号的客户端发送的ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；

根据ID获取请求向非活跃帐号的客户端发送各个用户帐号的动态信息的消息ID列表；

接收非活跃帐号的客户端发送的信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；

根据信息获取请求向非活跃帐号的客户端反馈与消息ID对应的动态信息。

在一种可能的实现方式中，接收发布方帐号的客户端发送的发布请求之前，还包括：

存储发布方帐号的好友列表；

对于发布方帐号的好友列表中的各个帐号，检测帐号是否符合预设条件，预设条件是指在预定时间内发布和/或浏览过动态信息；

若好友列表中的帐号符合预设条件，则记录帐号的类型为活跃帐号；

若好友列表中的帐号不符合预设条件，则记录帐号的类型为非活跃帐号；

存储各个帐号的类型。

第二方面，提供了一种消息读取方法，该方法，包括：

检测客户端的消息箱中是否存在消息ID；

若消息箱中存在消息ID，则向服务器发送信息获取请求；

接收服务器反馈的与消息ID对应的动态信息；

其中，消息箱中的消息ID是服务器获取发布方帐号的客户端发送的发布请求后，向发布方帐号的好友列表中的活跃帐号推送的，发布请求用于发布用户的动态信息。

在一种可能的实现方式中，检测客户端的消息箱中是否存在消息ID之后，还包括：

若消息箱中不存在消息ID，则向服务器发送关系获取请求，关系获取请求用于获取好友列表；

接收服务器反馈的好友列表；

根据好友列表，向服务器发送ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；

接收服务器反馈的各个用户帐号的动态信息的消息ID列表；

向服务器发送信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；

接收服务器反馈的与消息ID对应的动态信息。

在一种可能的实现方式中，该方法，还包括：

检测消息箱中消息ID的数量是否大于或等于预设阈值；

若消息ID的数量大于或等于预设阈值，则根据接收消息ID的时间删除最早的消息ID。

第三方面，提供了一种消息推送装置，该装置包括：

发布接收模块，用于接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；

标识获取模块，用于获取动态信息的消息标识ID；

第一查询模块，用于查询发布方帐号的好友列表中的活跃帐号；

标识推送模块，用于向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息。

在一种可能的实现方式中，该装置，还包括：

第一请求模块，用于接收好友列表中的活跃帐号的客户端发送的信息获取请求，信息获取请求携带有从活跃帐号的消息箱获取的消息ID；

第一反馈模块，用于根据消息ID向活跃帐号的客户端反馈动态信息。

在一种可能的实现方式中，该装置，还包括：

关系请求模块，用于接收好友列表中的非活跃帐号的客户端发送的关系获取请求，关系获取请求用于获取非活跃帐号的好友列表；

关系发送模块，用于根据关系获取请求向非活跃帐号的客户端反馈非活跃帐号的好友列表；

ID请求模块，用于接收非活跃帐号的客户端发送的ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；

ID发送模块，用于根据ID获取请求向非活跃帐号的客户端发送各个用户帐号的动态信息的消息ID列表；

第二请求模块，用于接收非活跃帐号的客户端发送的信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；

第二反馈模块，用于根据信息获取请求向非活跃帐号的客户端反馈与消息ID对应的动态信息。

在一种可能的实现方式中，该装置，还包括：

列表存储模块，用于存储发布方帐号的好友列表；

第一检测模块，用于对发布方帐号的好友列表中的各个帐号，检测帐号是否符合预设条件，预设条件是指在预定时间内发布和/或浏览过动态信息；

第一记录模块，用于在好友列表中的帐号符合预设条件时，记录帐号的类型为活跃帐号；

第二记录模块，用于在好友列表中的帐号不符合预设条件时，记录帐号的类型为非活跃帐号；

类型存储模块，用于存储各个帐号的类型。

第四方面，提供了一种消息读取装置，该装置包括：

第二检测模块，用于检测客户端的消息箱中是否存在消息ID；

第一发送模块，用于在消息箱中存在消息ID时，向服务器发送信息获取请求；

第一接收模块，用于接收服务器反馈的与消息ID对应的动态信息；

其中，消息箱中的消息ID是服务器获取发布方帐号的客户端发送的发布请求后，向发布方帐号的好友列表中的活跃帐号推送的，发布请求用于发布用户的动态信息。

在一种可能的实现方式中，该装置，还包括：

第二发送模块，用于在消息箱中不存在消息ID时，向服务器发送关系获取请求，关系获取请求用于获取好友列表；

第二接收模块，用于接收服务器反馈的好友列表；

第三发送模块，用于根据好友列表，向服务器发送ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；

第三接收模块，用于接收服务器反馈的各个用户帐号的动态信息的消息ID列表；

第四发送模块，用于向服务器发送信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；

第四接收模块，用于接收服务器反馈的与消息ID对应的动态信息。

在一种可能的实现方式中，该装置，还包括：

数量检测模块，用于检测消息箱中消息ID的数量是否大于或等于预设阈值；

消息删除模块，用于在消息ID的数量大于或等于预设阈值时，根据接收消息ID的时间删除最早的消息ID。

第五方面，提供了一种消息推送系统，该系统包括：服务器和客户端；

服务器包括如上第三方面或第三方面提供的任意一种可能的实现方式中的任一消息推送装置；

客户端包括如上第四方面或第四方面提供的任意一种可能的实现方式中的任一消息读取装置。

本发明实施例提供的技术方案带来的有益效果是：

通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；向活跃帐号的消息箱推送动态信息，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

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

图1是本发明一个实施例提供的一种实施环境的结构示意图；

图2是本发明一个实施例提供的消息推送方法的方法流程图；

图3是本发明另一个实施例提供的消息推送方法的方法流程图；

图4是本发明再一个实施例提供的消息读取方法的方法流程图；

图5是本发明一个实施例提供的消息推送装置的结构方框图；

图6是本发明另一个实施例提供的消息推送装置的结构方框图；

图7是本发明另一个实施例提供的消息推送装置的结构方框图；

图8是本发明一个实施例提供的消息读取装置的结构方框图；

图9是本发明另一个实施例提供的消息读取装置的结构方框图；

图10是本发明另一个实施例提供的消息读取装置的结构方框图；

图11是本发明一个实施例提供的消息推送系统的结构方框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是本发明一个实施例提供的一种实施环境的结构示意图。该实施环境包括：第一客户端110、第二客户端120、第三客户端130和服务器140。

第一客户端110、第二客户端120或第三客户端130可以是手机、平板电脑、电子书阅读器、MP3(MovingPictureExpertsGroupAudioLayerIII，动态影像专家压缩标准音频层面3)播放器、MP4(MovingPictureExpertsGroupAudioLayerIV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。客户端120中安装有通信类应用程序，该通信类应用程序可以是即时通信程序、社交类应用程序或语音通信程序。比如，该通信类应用程序是即时通信程序QQ或微博或微信。

假定第一客户端110是发布方帐号对应的客户端，第二客户端120是活跃帐号对应的客户端，第三客户端130是非活跃帐号对应的客户端。

第一客户端110与第二客户端120通过服务器140建立连接；第一客户端110与第三客户端130也通过服务器140建立连接。

第一客户端110与服务器140之间建立连接。第一客户端110发布的动态信息经过服务器140处理后推送到第二客户端120的消息箱中；而第三客户端130需要通过服务器140去获取第一客户端110中发布的动态信息。

服务器140是通信类应用程序的后台服务器。服务器140可以是一台服务器、多台服务器组成的服务器集群或云计算中心。

服务器140可以包括：消息内容服务器141、好友关系服务器142和推送服务器143。

第一客户端110与消息内容服务器141建立连接，消息内容服务器141用于存储第一客户端110发布的动态信息，包括动态信息的内容和与动态信息对应的消息ID。

好友关系服务器142与消息内容服务器141直接建立连接，好友关系服务器142用于存储第一客户端110中的好友列表，并将第一客户端110的好友列表进行分类，分为活跃帐号的客户端和非活跃帐号的客户端。

推送服务器143与消息内容服务器141建立连接，推送服务器143用于将消息内容服务器141中的与动态消息对应的消息ID推送到活跃帐号的消息箱中。

可选地，服务器140中还可以包含有消息ID服务器144，与第一客户端110和消息内容服务器141建立连接，用于生成与动态信息对应的消息ID。

图2是本发明一个实施例提供的消息推送方法的方法流程图。本实施例以该消息推送方法应用于图1所示的服务器140中来举例说明。该方法包括：

步骤201，接收发布方帐号的客户端发送的发布请求，该发布请求用于发布用户的动态信息；

步骤202，查询发布方帐号的好友列表中的活跃帐号；

步骤203，获取动态信息的消息ID(Identification，标识)；

步骤204，向活跃帐号的消息箱推送消息ID，该活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，该活跃帐号用于根据消息ID读取动态信息。

综上所述，本实施例提供的消息推送方法，通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；获取动态信息的消息ID；向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图3是本发明另一个实施例提供的消息推送方法的方法流程图。本实施例以该消息推送方法应用于图1所示的实施环境中来举例说明；本实施例中假定第一客户端是发布方帐号的客户端，第二客户端为活跃帐号的客户端，第三客户端为非活跃帐号的客户端。该方法包括：

步骤301，服务器存储发布方帐号的好友列表；

服务器根据发布方帐号，获取发布方帐号中的所有好友帐号，服务器将所有的好友帐号存储为发布方帐号的好友列表，便于对发布方帐号的好友关系查找。

步骤302，对于发布方帐号的好友列表中的各个帐号，服务器检测帐号是否符合预设条件；

该预设条件是指在预定时间内发布和/或浏览过动态信息；

在存储发布方帐号的好友列表后，服务器对好友列表中的各个帐号进行检测，检测帐号是否符合预设条件，该预设条件是指该帐号在预定时间内是否有发布动态信息，和/或，浏览过该帐号的好友列表中好友帐号的动态信息。

比如：帐号A在3天内发布了一个动态信息，和/或，帐号A在4天内浏览过帐号A好友列表中好友帐号B的动态信息。

可选地，预定时间可以是3天、5天或者7天等；本实施例中对于预定时间不作具体限定。

步骤303，若好友列表中的帐号符合预设条件，则服务器记录帐号的类型为活跃帐号；

当好友列表中的帐号在预定时间内发布和/或浏览过动态信息，则服务器将该帐号记录为活跃帐号的类型。

比如：假定预定时间为7天，好友列表中的帐号A在第3天时发布了一个动态信息，则服务器将帐号A记录为活跃账户的类型；好友列表中的帐号B在第5天时浏览过自身好友列表中的动态信息，则服务器也将帐号B记录为活跃账户的类型；好友列表中的帐号C在第2天时发布了动态信息，同时在第4天时浏览了自身好友列表中的动态信息，则服务器将帐号C也记录为活跃帐号的类型。

步骤304，若好友列表中的帐号不符合预设条件，则服务器记录帐号的类型为非活跃帐号；

当好友列表中的帐号在预定时间内没有发布和浏览过动态信息，则服务器将该帐号记录为非活跃帐号的类型。

比如：假定预定时间为7天，好友列表中的帐号D在7天内都未发布动态，同时在这7天内也没有浏览自身好友列表中的任何动态信息，则服务器将帐号D记录为非活跃帐号的类型。

步骤305，服务器存储各个帐号的类型；

服务器将好友列表中的各个帐号都进行检测，并对各个帐号进行分类，存储各个帐号对应的类型。

可选地，服务器存储的各个帐号的类型每隔预设时间会重新进行检测，将重新检测的结果重新存储在服务器中，比如：每隔3天、7天或10天等，本实施例中对该预设时间不作具体限定。

在实际的实施例中，服务器通常对每个所有帐号都检测是否符合预设条件，并记录每个帐号的类型，并不需要区分是否为发布方帐号的好友。步骤302中的“发布方帐号的好友列表中的各个帐号”仅是针对发布方帐号来进行描述的，并不限定此处需要判断帐号是否为发布方帐号的好友。

步骤306，第一客户端向服务器发送发布请求，该发布请求用于发布用户的动态信息；

在用户发布动态信息时，第一客户端首先向服务器发送发布请求，该发布请求用于发布用户的动态信息，服务器接收该第一客户端发送的发布请求。

可选地，第一客户端调用预定的ID生成服务，为待发布的动态消息生成消息ID，并将消息ID携带在发布请求中。每个消息ID在所有消息ID中全局唯一。

对应地，服务器接收第一客户端发送的发布请求，该发布请求用于发布用户的动态信息。

步骤307，服务器获取动态信息的消息ID；

可选地，服务器根据第一客户端发送的发布请求生成与动态信息对应的消息ID，生成的消息ID与动态信息之间存在一一对应的关系，具有全局唯一性。

可选地，第一客户端也可以实现调用预定的ID生成服务，对待发布的动态信息生成消息ID，然后将消息ID携带在发布请求中发送给服务器。服务器从发布请求中获取动态消息的消息ID。

步骤308，服务器查询第一客户端的好友列表中的活跃帐号；

服务器根据接收到的发布请求，获取发布方帐号对应的好友列表，根据获取的好友列表，服务器查询发布方帐号的好友列表中的活跃帐号。

步骤309，服务器向活跃帐号的消息箱推送消息ID；

该活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，该活跃帐号用于根据消息ID读取动态信息。

根据查询到的发布方帐号的活跃帐号以及获取的动态信息对应的消息ID，服务器向活跃帐号的消息箱推送消息ID，活跃帐号根据消息箱中的消息ID读取对应的动态信息；

步骤310，第二客户端检测消息箱中消息ID的数量是否大于或等于预设阈值；

可选地，第二客户端每隔预定时间间隔检测消息箱中的消息ID数量是否大于或等于预设阈值；

可选地，第二客户端在每次接收消息ID时，检测消息箱中的消息ID数量是否大于或者等于预设阈值。

可选地，消息ID的数量包括未读消息ID的数量，或者，消息ID的数量包括已读消息ID的数量与未读消息ID的数量之和。

步骤311，若消息ID的数量大于或等于预设阈值，则第二客户端根据接收消息ID的时间删除最早的消息ID；

当消息ID的数量大于或等于预设阈值时，按照接收消息ID的时间，删除最早接收的消息ID。

比如：假定预设阈值为500，最早一条消息ID的时间是2014年5月20日，当消息箱中未读消息ID的数量大于或等于500，或者，已读消息ID的数量与未读消息ID的数量之和大于或等于500时，则客户端将2014年5月20日的消息ID删除。在删除一条最早接收的消息ID后，第二客户端可以重新执行步骤310。

步骤312，若消息ID的数量小于预设阈值，则第二客户端将消息ID直接存储到活跃帐号的消息箱中；

步骤313，在接收到消息读取操作时，第二客户端检测自身的消息箱中是否存在消息ID；

第二客户端检测自身消息箱中是否存在服务器推送的消息ID。

步骤314，若消息箱中存在消息ID，则第二客户端向服务器发送信息获取请求；

若消息箱中存在消息ID，说明该消息箱对应的帐号为活跃帐号，则第二客户端向服务器发送信息获取请求，该信息获取请求中携带有从消息箱中获取的消息ID。

对应地，服务器接收好友列表中的第二客户端发送的信息获取请求，信息获取请求携带有从活跃帐号的消息箱获取的消息ID。

步骤315，服务器根据消息ID向第二客户端反馈动态信息；

服务器根据接收到的消息ID，查询到该消息ID对应的动态信息，并将查询到与消息ID对应的动态信息反馈给第二客户端。

步骤316，第二客户端接收服务器反馈的与消息ID对应的动态信息；

第二客户端接收服务器反馈的与消息ID对应的动态信息，并将动态信息显示在动态信息列表中。

其中，消息箱中的消息ID是服务器获取第一客户端发送的发布请求后，向发布方帐号的好友列表中的活跃帐号推送的，发布请求用于发布用户的动态信息。

步骤317，在接收到消息读取操作时，第三客户端检测自身的消息箱中是否存在消息ID；

步骤318，若消息箱中不存在消息ID，则第三客户端向服务器发送关系获取请求，关系获取请求用于获取好友列表；

若消息箱中不存在消息ID，说明该消息箱对应的帐号为非活跃帐号，则第三客户端向服务器发送关系获取请求，该关系获取请求用于获取好友列表。

对应地，服务器接收好友列表中的第三客户端发送的关系获取请求，关系获取请求用于获取非活跃帐号的好友列表。

步骤319，服务器根据关系获取请求向第三客户端发送非活跃帐号的好友列表；

服务器根据关系获取请求，获取非活跃帐号对应的好友列表，并将非活跃帐号的好友列表发送给该第三客户端。

对应地，客户端接收服务器反馈的好友列表；

步骤320，根据好友列表，第三客户端向服务器发送ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；

根据接收到的好友列表，第三客户端向服务器发送ID获取请求，用于获取对应帐号的消息ID，该ID获取请求中携带有从非活跃帐号的好友列表获取到的用户帐号；根据获取到的用户帐号，查询对应用户帐号的消息ID。

对应地，服务器接收第三客户端发送的ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号。

步骤321，服务器根据ID获取请求向第三客户端发送各个用户帐号的动态信息的消息ID列表；

根据ID获取请求，服务器获取与用户帐号的动态信息对应的消息ID，服务器将各个用户帐号的动态信息对应地消息ID组成消息ID列表，将该消息ID列表发送给第三客户端。

对应地，第三客户端接收服务器反馈的各个用户帐号的动态信息的消息ID列表。

步骤322，第三客户端向服务器发送信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；

根据接收到的消息ID列表，第三客户端向服务器发送信息获取请求，请求获取与消息ID列表中的消息ID对应的动态信息，该信息获取请求携带有从消息ID列表获取到的消息ID。

对应地，服务器接收第三客户端发送的信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID。

步骤323，服务器根据信息获取请求向第三客户端反馈与消息ID对应的动态信息。

根据信息获取请求，服务器查询与消息ID对应的动态信息，将查询到的动态信息反馈给第三客户端。

对应地，第三客户端接收服务器反馈的与消息ID对应的动态信息。

例如：假定客户端A是发布方帐号的客户端，客户端B和客户端C都是客户端A帐号的好友，客户端B是活跃帐号的客户端，客户端C是非活跃帐号的客户端。当客户端A发布一条动态信息后，服务器会根据该动态信息获取与其对应的消息ID，并将与该动态信息对应的消息ID推送到客户端B的消息箱中，客户端B直接从消息箱获取消息ID，读取与该消息ID对应的客户端A发布的动态信息；而客户端C需要先从服务器中获取自身的好友关系列表，根据好友关系列表，获取到好友帐号发布动态信息的消息ID列表，最后根据消息ID列表读取到好友帐号发布的动态信息列表。

需要说明的是，图3实施例中步骤301至步骤305以及步骤307至步骤309可以单独实现成为服务器一侧的消息推送方法；步骤306可以单独实现成为第一客户端一侧的消息推送方法；步骤310至步骤316可以单独实现成为第二客户端一侧的消息读取方法；步骤318至步骤323可以单独实现成为第三客户端一侧的消息读取方法。

综上所述，本实施例提供的消息推送方法，通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；获取动态信息的消息ID；向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息；通过检测客户端的消息箱中是否存在消息ID；活跃帐号的客户端直接利用消息箱中的消息ID读取对应的动态信息；非活跃帐号的客户端通过好友列表获取消息ID，最后也通过消息ID读取对应的动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图2实施例和图3实施例提供的消息推送方法都是在一个服务器中进行的，该消息推送方法还可以在多个服务器中进行实施，请参考如下实施例。

图4是本发明再一个实施例提供的消息推送方法的方法流程图。本实施例以该消息推送方法应用于图1所示的实施环境中来举例说明；本实施例中假定第一客户端是发布方帐号的客户端，第二客户端为活跃帐号的客户端，第三客户端为非活跃帐号的客户端。该方法包括：

步骤401，好友关系服务器存储发布方帐号的好友列表；

好友关系服务器根据发布方帐号，获取发布方帐号中的所有好友帐号，好友关系服务器将所有的好友帐号存储为发布方帐号的好友列表，便于对发布方帐号的好友关系查找。

步骤402，好友关系服务器对于发布方帐号的好友列表中的各个帐号，检测帐号是否符合预设条件；

该预设条件是指在预定时间内发布和/或浏览过动态信息；

在存储发布方帐号的好友列表后，好友关系服务器对好友列表中的各个帐号进行检测，检测帐号是否符合预设条件，该预设条件是指该帐号在预定时间内是否有发布动态信息，和/或，浏览过该帐号的好友列表中好友帐号的动态信息。

比如：帐号A在3天内发布了一个动态信息，和/或，帐号A在4天内浏览过帐号A好友列表中好友帐号B的动态信息。

可选地，预定时间可以是3天、5天或者7天等；本实施例中对于预定时间不作具体限定。

步骤403，若好友列表中的帐号符合预设条件，则好友关系服务器记录帐号的类型为活跃帐号；

当好友列表中的帐号在预定时间内发布和/或浏览过动态信息，则好友关系服务器将该帐号记录为活跃帐号的类型。

比如：假定预定时间为7天，好友列表中的帐号A在第3天时发布了一个动态信息，则好友关系服务器将帐号A记录为活跃账户的类型；好友列表中的帐号B在第5天时浏览过自身好友列表中的动态信息，则好友关系服务器也将帐号B记录为活跃账户的类型；好友列表中的帐号C在第2天时发布了动态信息，同时在第4天时浏览了自身好友列表中的动态信息，则好友关系服务器将帐号C也记录为活跃帐号的类型。

步骤404，若好友列表中的帐号不符合预设条件，则好友关系服务器记录帐号的类型为非活跃帐号；

当好友列表中的帐号在预定时间内没有发布和浏览过动态信息，则好友关系服务器将该帐号记录为非活跃帐号的类型。

比如：假定预定时间为7天，好友列表中的帐号D在7天内都未发布动态，同时在这7天内也没有浏览自身好友列表中的任何动态信息，则好友关系服务器将帐号D记录为非活跃帐号的类型。

步骤405，好友关系服务器存储各个帐号的类型；

好友关系服务器将好友列表中的各个帐号都进行检测，并对各个帐号进行分类，存储各个帐号对应的类型。

可选地，服务器存储的各个帐号的类型每隔预设时间会重新进行检测，将重新检测的结果重新存储在服务器中，比如：每隔3天、7天或10天等，本实施例中对该预设时间不作具体限定。

在实际的实施例中，好友关系服务器通常对每个所有帐号都检测是否符合预设条件，并记录每个帐号的类型，并不需要区分是否为第一客户端的好友。步骤402中的“发布方帐号的好友列表中的各个帐号”仅是针对发布方帐号来进行描述的，并不限定此处需要判断帐号是否为发布方帐号的好友。

步骤406，第一客户端向消息内容服务器发送发布请求，该发布请求用于发布用户的动态信息；

在用户发布动态信息时，第一客户端首先向消息内容服务器发送发布请求，该发布请求用于发布用户的动态信息，消息内容服务器接收该第一客户端发送的发布请求。

可选地，第一客户端调用预定的ID生成服务，为待发布的动态消息生成消息ID，并将消息ID携带在发布请求中。每个消息ID在所有消息ID中全局唯一。

对应地，消息内容服务器接收第一客户端发送的发布请求，该发布请求用于发布用户的动态信息；

步骤407，消息内容服务器获取动态信息的消息ID；

可选地，消息内容服务器根据第一客户端发送的发布请求生成与动态信息对应的消息ID，生成的消息ID与动态信息之间存在一一对应的关系；具有全局唯一性。

可选地，第一客户端在向消息内容服务器发送发布请求的同时，调用消息ID服务器(图中未示出)生成与动态信息对应的消息ID，然后将消息ID携带在发布请求中发送给消息内容服务器。消息内容服务器从发布请求中获取动态消息的消息ID。。

步骤408，消息内容服务器向好友关系服务器发送好友列表请求；

消息内容服务器根据接收到的发布请求，向好友关系服务器发送好友列表请求。

好友关系服务器根据接收到的好友列表请求，查询发布方帐号对应的好友列表，并将查询到的好友列表发送给消息内容服务器。

对应地，消息内容服务器接收好友关系服务器发送的好友关系列表。

步骤409，消息内容服务器获取发布方帐号对应的好友列表，查询发布方帐号的好友列表中的活跃帐号；

消息内容服务器根据获取到的好友列表，查询该好友列表中的活跃帐号。

步骤410，消息内容服务器向推送服务器发送推送请求，该推送请求中携带有与动态信息对应的消息ID和发布方帐号好友列表中的活跃帐号；

消息内容服务器向推送服务器发送推送请求，请求推送服务器将与动态信息对应的消息ID推送到活跃帐号的消息箱中。

步骤411，推送服务器向活跃帐号的消息箱推送消息ID；

该活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，该活跃帐号用于根据消息ID读取动态信息；

根据查询到的发布方帐号的活跃帐号以及获取的动态信息对应的消息ID，推送服务器将获取的消息ID推送到活跃帐号的消息箱中，活跃帐号根据消息箱中的消息ID读取对应的动态信息。

步骤412，第二客户端检测消息箱中消息ID的数量是否大于或等于预设阈值；

可选地，第二客户端每隔预定时间间隔检测消息箱中的消息ID数量是否大于或等于预设阈值；

可选地，第二客户端在每次接收消息ID时，检测消息箱中的消息ID数量是否大于或者等于预设阈值。

可选地，消息ID的数量包括未读消息ID的数量，或者，消息ID的数量包括已读消息ID的数量与未读消息ID的数量之和。

步骤413，若消息ID的数量大于或等于预设阈值，则第二客户端根据接收消息ID的时间删除最早的消息ID；

当消息ID的数量大于或等于预设阈值时，按照接收消息ID的时间，删除最早接收的消息ID。

比如：假定预设阈值为500，最早一条消息ID的时间是2014年5月20日，当消息箱中未读消息ID的数量大于或等于500，或者，已读消息ID的数量与未读消息ID的数量之和大于或等于500时，则第二客户端将2014年5月20日的消息ID删除，在删除一条最早接收的消息ID后，第二客户端可以重新执行步骤411。

步骤414，若消息ID的数量小于预设阈值，则第二客户端将消息ID直接存储到活跃帐号的消息箱中；

步骤415，在接收到消息读取操作时，第二客户端检测自身消息箱中是否存在消息ID；

第二客户端检测自身消息箱中是否存在推送服务器推送的消息ID。

步骤416，若消息箱中存在消息ID，则第二客户端向消息内容服务器发送信息获取请求；

若消息箱中存在消息ID，说明该消息箱对应的帐号为活跃帐号，则第二客户端向消息内容服务器发送信息获取请求，该信息获取请求中携带有从消息箱中获取的消息ID。

对应地，消息内容服务器接收好友列表中的第二客户端发送的信息获取请求，信息获取请求携带有从活跃帐号的消息箱获取的消息ID。

步骤417，消息内容服务器根据消息ID向第二客户端反馈动态信息；

消息内容服务器根据接收到的消息ID，查询到该消息ID对应的动态信息，并将查询到与消息ID对应的动态信息反馈给第二客户端。

步骤418，第二客户端接收消息内容服务器反馈的与消息ID对应的动态信息；

第二客户端接收消息内容服务器反馈的与消息ID对应的动态信息，并将动态信息显示在动态信息列表中。

其中，消息箱中的消息ID是消息内容服务器获取第一客户端发送的发布请求后，向发布方帐号的好友列表中的活跃帐号推送的，发布请求用于发布用户的动态信息。

步骤419，在接收到消息读取操作时，第三客户端检测自身的消息箱中是否存在消息ID；

步骤420，若消息箱中不存在消息ID，则第三客户端向好友关系服务器发送关系获取请求，关系获取请求用于获取好友列表；

若消息箱中不存在消息ID，说明该消息箱对应的帐号为非活跃帐号，则第三客户端向服务器发送关系获取请求，该关系获取请求用于获取好友列表。

对应地，好友关系服务器接收好友列表中的第三客户端发送的关系获取请求，关系获取请求用于获取非活跃帐号的好友列表。

步骤421，好友关系服务器根据关系获取请求向第三客户端发送非活跃帐号的好友列表；

好友关系服务器根据关系获取请求，获取非活跃帐号对应的好友列表，并将非活跃帐号的好友列表发送给该第三客户端。

对应地，第三客户端接收好友关系服务器反馈的好友列表；

步骤422，根据好友列表，第三客户端向消息内容服务器发送ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；

根据接收到的好友列表，第三客户端向消息内容服务器发送ID获取请求，用于获取对应帐号的消息ID，该ID获取请求中携带有从非活跃帐号的好友列表获取到的用户帐号；消息内容服务器根据获取到的用户帐号，查询对应用户帐号的消息ID。

对应地，消息内容服务器接收第三客户端发送的ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号。

步骤423，消息内容服务器根据ID获取请求向第三客户端发送各个用户帐号的动态信息的消息ID列表；

根据ID获取请求，消息内容服务器获取与用户帐号的动态信息对应的消息ID，消息内容服务器将各个用户帐号的动态信息对应地消息ID组成消息ID列表，将该消息ID列表发送给第三客户端。

对应地，第三客户端接收消息内容服务器反馈的各个用户帐号的动态信息的消息ID列表。

步骤424，第三客户端向消息内容服务器发送信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；

根据接收到的消息ID列表，第三客户端向消息内容服务器发送信息获取请求，请求获取与消息ID列表中的消息ID对应的动态信息，该信息获取请求携带有从消息ID列表获取到的消息ID。

对应地，消息内容服务器接收第三客户端发送的信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID。

步骤425，消息内容服务器根据信息获取请求向第三客户端反馈与消息ID对应的动态信息。

根据信息获取请求，消息内容服务器查询与消息ID对应的动态信息，将查询到的动态信息反馈给第三客户端。

对应地，第三客户端接收消息内容服务器反馈的与消息ID对应的动态信息。

需要说明的是，图4实施例中步骤401至步骤405以及步骤421可以单独实现成为好友关系服务器一侧的消息推送方法；步骤406可以单独实现成为第一客户端一侧的消息推送方法；步骤407至步骤410以及步骤423可以单独实现成为消息内容服务器一侧的消息推送方法；步骤411可以单独实现成为推送服务器一侧的消息推送方法；步骤412至步骤416以及步骤418可以单独实现成为第二客户端一侧的消息读取方法；步骤419、步骤420和步骤422以及步骤424至步骤425可以单独实现成为第三客户端一侧的消息读取方法。

综上所述，本实施例提供的消息推送方法，通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；获取动态信息的消息ID；向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息；通过检测客户端的消息箱中是否存在消息ID；活跃帐号的客户端直接利用消息箱中的消息ID读取对应的动态信息；非活跃帐号的客户端通过好友列表获取消息ID，最后也通过消息ID读取对应的动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图5是本发明一个实施例提供的消息推送装置的结构方框图。该消息推送装置用于服务器中，该消息推送装置包括：

发布接收模块510，用于接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息。

标识获取模块520，用于获取动态信息的消息标识ID。

第一查询模块530，用于查询发布方帐号的好友列表中的活跃帐号。

标识推送模块540，用于向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息。

综上所述，本实施例提供的消息推送装置，通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；获取动态信息的消息ID；向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图6是本发明另一个实施例提供的消息推送装置的结构方框图。该消息推送装置用于服务器中，该消息推送装置包括：

列表存储模块610，用于存储发布方帐号的好友列表。

第一检测模块620，用于对发布方帐号的好友列表中的各个帐号，检测帐号是否符合预设条件，预设条件是指在预定时间内发布和/或浏览过动态信息。

第一记录模块630，用于在好友列表中的帐号符合预设条件时，记录帐号的类型为活跃帐号。

第二记录模块640，用于在好友列表中的帐号不符合预设条件时，记录帐号的类型为非活跃帐号。

类型存储模块650，用于存储各个帐号的类型。

发布接收模块660，用于接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息。

标识获取模块670，用于获取动态信息的消息标识ID。

第一查询模块680，用于查询发布方帐号的好友列表中的活跃帐号。

标识推送模块690，用于向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息。

第一请求模块700，用于接收好友列表中的活跃帐号的客户端发送的信息获取请求，信息获取请求携带有从活跃帐号的消息箱获取的消息ID。

第一反馈模块710，用于根据消息ID向活跃帐号的客户端反馈动态信息。

综上所述，本实施例提供的消息推送装置，通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；获取动态信息的消息ID；向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图7是本发明另一个实施例提供的消息推送装置的结构方框图。该消息推送装置用于服务器中，该消息推送装置包括：

列表存储模块610，用于存储发布方帐号的好友列表。

第一检测模块620，用于对发布方帐号的好友列表中的各个帐号，检测帐号是否符合预设条件，预设条件是指在预定时间内发布和/或浏览过动态信息。

第一记录模块630，用于在好友列表中的帐号符合预设条件时，记录帐号的类型为活跃帐号。

第二记录模块640，用于在好友列表中的帐号不符合预设条件时，记录帐号的类型为非活跃帐号。

类型存储模块650，用于存储各个帐号的类型。

发布接收模块660，用于接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息。

标识获取模块670，用于获取动态信息的消息标识ID。

第一查询模块680，用于查询发布方帐号的好友列表中的活跃帐号。

标识推送模块690，用于向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息。

关系请求模块720，用于接收好友列表中的非活跃帐号的客户端发送的关系获取请求，关系获取请求用于获取非活跃帐号的好友列表。

关系发送模块730，用于根据关系获取请求向非活跃帐号反馈非活跃帐号的好友列表。

ID请求模块740，用于接收非活跃帐号的客户端发送的ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号。

ID发送模块750，用于根据ID获取请求向非活跃帐号的客户端发送各个用户帐号的动态信息的消息ID列表。

第二请求模块760，用于接收非活跃帐号的客户端发送的信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID。

第二反馈模块770，用于根据信息获取请求向非活跃帐号的客户端反馈与消息ID对应的动态信息。

综上所述，本实施例提供的消息推送装置，通过接收发布方帐号的客户端发送的发布请求，发布请求用于发布用户的动态信息；查询发布方帐号的好友列表中的活跃帐号；获取动态信息的消息ID；向活跃帐号的消息箱推送消息ID，活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，活跃帐号用于根据消息ID读取动态信息；非活跃帐号根据好友列表和与好友列表中的帐号对应的消息ID读取好友列表中的动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图8是本发明一个实施例提供的消息读取装置的结构方框图。该消息推送装置用于活跃帐号的客户端中，该消息读取装置包括：

第二检测模块810，用于检测客户端的消息箱中是否存在消息ID。

第一发送模块820，用于在消息箱中存在消息ID时，向服务器发送信息获取请求。

第一接收模块830，用于接收服务器反馈的与消息ID对应的动态信息；

其中，消息箱中的消息ID是服务器获取发布方帐号的客户端发送的发布请求后，向发布方帐号的好友列表中的活跃帐号推送的，发布请求用于发布用户的动态信息。

综上所述，本实施例提供的消息读取装置，通过客户端检测客户端的消息箱中是否存在消息ID；若消息箱中存在消息ID，则客户端向服务器发送信息获取请求；服务器根据消息ID向活跃帐号的客户端反馈动态信息；客户端接收服务器反馈的与消息ID对应的动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图9是本发明另一个实施例提供的消息读取装置的结构方框图。该消息推送装置用于活跃帐号的客户端中，该消息读取装置包括：

数量检测模块910，用于检测消息箱中消息ID的数量是否大于或等于预设阈值；

消息删除模块920，用于在消息ID的数量大于或等于预设阈值时，根据接收消息ID的时间删除最早的消息ID。

第二检测模块930，用于检测客户端的消息箱中是否存在消息ID。

第一发送模块940，用于在消息箱中存在消息ID时，向服务器发送信息获取请求。

第一接收模块950，用于接收服务器反馈的与消息ID对应的动态信息；

其中，消息箱中的消息ID是服务器获取发布方帐号的客户端发送的发布请求后，向发布方帐号的好友列表中的活跃帐号推送的，发布请求用于发布用户的动态信息。

综上所述，本实施例提供的消息读取装置，通过客户端检测客户端的消息箱中是否存在消息ID；若消息箱中存在消息ID，则客户端向服务器发送信息获取请求；服务器根据消息ID向活跃帐号的客户端反馈动态信息；客户端接收服务器反馈的与消息ID对应的动态信息；解决了当存在多个用户需要发布动态信息时，推送的消息量较大；对推送服务器造成很大的压力，使得动态信息的发布会产生严重的延迟的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图10是本发明另一个实施例提供的消息读取装置的结构方框图。该消息推送装置用于非活跃帐号的客户端中，该消息读取装置包括：

第二检测模块1010，用于检测客户端的消息箱中是否存在消息ID。

第二发送模块1020，用于在消息箱中不存在消息ID时，向服务器发送关系获取请求，关系获取请求用于获取好友列表；

第二接收模块1030，用于接收服务器反馈的好友列表；

第三发送模块1040，用于根据好友列表，向服务器发送ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；

第三接收模块1050，用于接收服务器反馈的各个用户帐号的动态信息的消息ID列表；

第四发送模块1060，用于向服务器发送信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；

第四接收模块1070，用于接收服务器反馈的与消息ID对应的动态信息。

综上所述，本实施例提供的消息读取装置，通过客户端检测客户端的消息箱中是否存在消息ID；若消息箱中不存在消息ID，则客户端向服务器发送关系获取请求，关系获取请求用于获取好友列表；服务器根据关系获取请求向非活跃帐号的客户端反馈好友列表；根据好友列表，客户端向服务器发送ID获取请求，ID获取请求携带有从非活跃帐号的好友列表获取到的用户帐号；服务器根据ID获取请求向非活跃帐号的客户端发送各个用户帐号的动态信息的消息ID列表；客户端向服务器发送信息获取请求，信息获取请求携带有从消息ID列表获取到的消息ID；服务器根据信息获取请求向非活跃帐号的客户端反馈与消息ID对应的动态信息；解决了非活跃帐号的消息箱在未接收到消息ID的情况，读取好友列表中的动态信息的问题；达到了只向活跃帐号的消息箱推送动态信息，从而降低了推送的消息量，减轻了推送服务器的压力，使得动态消息能够快速送达的效果。

图11是本发明一个实施例提供的消息推送系统的结构方框图。该消息推送系统包括：服务器1120和客户端1140；

服务器1120包括如图5所示实施例或图6所示实施例或图7所示实施例任一描述的消息推送装置；

客户端1140包括如图8所示实施例或图9所示实施例或图10所示实施例任一描述的消息读取装置。

需要说明的是：上述实施例提供的消息推送的装置在推送动态信息时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将电子设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的消息推送的装置与消息推送的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

1.一种消息推送方法，其特征在于，所述方法包括：

接收发布方帐号的客户端发送的发布请求，所述发布请求用于发布用户的动态信息；

获取所述动态信息的消息标识ID；

查询所述发布方帐号的好友列表中的活跃帐号；

向所述活跃帐号的消息箱推送所述消息ID，所述活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，所述活跃帐号用于根据所述消息ID读取所述动态信息。

2.根据权利要求1所述的方法，其特征在于，所述向所述活跃帐号的消息箱推送所述动态信息之后，还包括：

接收所述好友列表中的所述活跃帐号的客户端发送的信息获取请求，所述信息获取请求携带有从所述活跃帐号的消息箱获取的所述消息ID；

根据所述消息ID向所述活跃帐号的客户端反馈所述动态信息。

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

接收所述好友列表中的非活跃帐号的客户端发送的关系获取请求，所述关系获取请求用于获取所述非活跃帐号的好友列表；

根据所述关系获取请求向所述非活跃帐号的客户端发送所述非活跃帐号的好友列表；

接收所述非活跃帐号的客户端发送的ID获取请求，所述ID获取请求携带有从所述非活跃帐号的好友列表获取到的用户帐号；

根据所述ID获取请求向所述非活跃帐号的客户端发送各个所述用户帐号的动态信息的消息ID列表；

接收所述非活跃帐号的客户端发送的信息获取请求，所述信息获取请求携带有从所述消息ID列表获取到的消息ID；

根据所述信息获取请求向所述非活跃帐号的客户端反馈与所述消息ID对应的动态信息。

4.根据权利要求1至3任一所述的方法，其特征在于，所述接收发布方帐号的客户端发送的发布请求之前，还包括：

存储所述发布方帐号的好友列表；

对于所述发布方帐号的好友列表中的各个帐号，检测所述帐号是否符合预设条件，所述预设条件是指在预定时间内发布和/或浏览过动态信息；

若所述好友列表中的帐号符合预设条件，则记录所述帐号的类型为所述活跃帐号；

若所述好友列表中的帐号不符合预设条件，则记录所述帐号的类型为非活跃帐号；

存储各个帐号的类型。

5.一种消息读取方法，其特征在于，所述方法包括：

检测客户端的消息箱中是否存在消息ID；

若所述消息箱中存在所述消息ID，则向服务器发送信息获取请求；

接收所述服务器反馈的与所述消息ID对应的动态信息；

其中，所述消息箱中的所述消息ID是所述服务器获取发布方帐号的客户端发送的发布请求后，向所述发布方帐号的好友列表中的活跃帐号推送的，所述发布请求用于发布用户的动态信息。

6.根据权利要求5所述的方法，其特征在于，所述检测客户端的消息箱中是否存在消息ID之后，还包括：

若所述消息箱中不存在所述消息ID，则向所述服务器发送关系获取请求，所述关系获取请求用于获取好友列表；

接收所述服务器反馈的所述好友列表；

根据所述好友列表，向所述服务器发送ID获取请求，所述ID获取请求携带有从所述非活跃帐号的好友列表获取到的用户帐号；

接收所述服务器反馈的各个所述用户帐号的动态信息的消息ID列表；

向所述服务器发送信息获取请求，所述信息获取请求携带有从所述消息ID列表获取到的消息ID；

接收所述服务器反馈的与所述消息ID对应的动态信息。

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

检测所述消息箱中所述消息ID的数量是否大于或等于预设阈值；

若所述消息ID的数量大于或等于所述预设阈值，则根据接收所述消息ID的时间删除最早的所述消息ID。

8.一种消息推送装置，其特征在于，所述装置包括：

发布接收模块，用于接收发布方帐号的客户端发送的发布请求，所述发布请求用于发布用户的动态信息；

标识获取模块，用于获取所述动态信息的消息标识ID；

第一查询模块，用于查询所述发布方帐号的好友列表中的活跃帐号；

标识推送模块，用于向所述活跃帐号的消息箱推送所述消息ID，所述活跃帐号是指在预定时间内发布和/或浏览过动态信息的帐号，所述活跃帐号用于根据所述消息ID读取所述动态信息。

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

第一请求模块，用于接收所述好友列表中的所述活跃帐号的客户端发送的信息获取请求，所述信息获取请求携带有从所述活跃帐号的消息箱获取的所述消息ID；

第一反馈模块，用于根据所述消息ID向所述活跃帐号的客户端反馈所述动态信息。

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

关系请求模块，用于接收所述好友列表中的非活跃帐号的客户端发送的关系获取请求，所述关系获取请求用于获取所述非活跃帐号的好友列表；

关系发送模块，用于根据所述关系获取请求向所述非活跃帐号的客户端反馈所述非活跃帐号的好友列表；

ID请求模块，用于接收所述非活跃帐号的客户端发送的ID获取请求，所述ID获取请求携带有从所述非活跃帐号的好友列表获取到的用户帐号；

ID发送模块，用于根据所述ID获取请求向所述非活跃帐号的客户端发送各个所述用户帐号的动态信息的消息ID列表；

第二请求模块，用于接收所述非活跃帐号的客户端发送的信息获取请求，所述信息获取请求携带有从所述消息ID列表获取到的消息ID；

第二反馈模块，用于根据所述信息获取请求向所述非活跃帐号的客户端反馈与所述消息ID对应的动态信息。

11.根据权利要求8至10任一所述的装置，其特征在于，所述装置，还包括：

列表存储模块，用于存储所述发布方帐号的好友列表；

第一检测模块，用于对所述发布方帐号的好友列表中的各个帐号，检测所述帐号是否符合预设条件，所述预设条件是指在预定时间内发布和/或浏览过动态信息；

第一记录模块，用于在所述好友列表中的帐号符合预设条件时，记录所述帐号的类型为所述活跃帐号；

第二记录模块，用于在所述好友列表中的帐号不符合预设条件时，记录所述帐号的类型为非活跃帐号；

类型存储模块，用于存储各个帐号的类型。

12.一种消息读取装置，其特征在于，所述装置包括：

第二检测模块，用于检测客户端的消息箱中是否存在消息ID；

第一发送模块，用于在所述消息箱中存在所述消息ID时，向服务器发送信息获取请求；

第一接收模块，用于接收所述服务器反馈的与所述消息ID对应的动态信息；

其中，所述消息箱中的所述消息ID是所述服务器获取发布方帐号的客户端发送的发布请求后，向所述发布方帐号的好友列表中的活跃帐号推送的，所述发布请求用于发布用户的动态信息。

13.根据权利要求12所述的装置，其特征在于，所述装置，还包括：

第二发送模块，用于在所述消息箱中不存在所述消息ID时，向所述服务器发送关系获取请求，所述关系获取请求用于获取好友列表；

第二接收模块，用于接收所述服务器反馈的所述好友列表；

第三发送模块，用于根据所述好友列表，向所述服务器发送ID获取请求，所述ID获取请求携带有从所述非活跃帐号的好友列表获取到的用户帐号；

第三接收模块，用于接收所述服务器反馈的各个所述用户帐号的动态信息的消息ID列表；

第四发送模块，用于向所述服务器发送信息获取请求，所述信息获取请求携带有从所述消息ID列表获取到的消息ID；

第四接收模块，用于接收所述服务器反馈的与所述消息ID对应的动态信息。

14.根据权利要求12所述的装置，其特征在于，所述装置，还包括：

数量检测模块，用于检测所述消息箱中所述消息ID的数量是否大于或等于预设阈值；

消息删除模块，用于在所述消息ID的数量大于或等于所述预设阈值时，根据接收所述消息ID的时间删除最早的所述消息ID。

15.一种消息推送系统，其特征在于，所述系统包括：服务器和客户端；

所述服务器包括如权利要求8至11任一所述的消息推送装置；

所述客户端包括如权利要求12至14任一所述的消息读取装置。