CN109657152A

CN109657152A - 推送消息发送方法、装置、电子设备及可读存储介质

Info

Publication number: CN109657152A
Application number: CN201811613475.2A
Authority: CN
Inventors: 曹东超
Original assignee: Beijing SF Intra City Technology Co Ltd
Current assignee: Beijing SF Intra City Technology Co Ltd
Priority date: 2018-12-27
Filing date: 2018-12-27
Publication date: 2019-04-19
Anticipated expiration: 2038-12-27
Also published as: CN109657152B

Abstract

本申请公开了一种推送消息发送方法、装置、电子设备及可读存储介质，涉及通信技术领域，本申请所述的推送消息发送方法包括：获取消息请求；所述消息请求中携带有用户身份标识；根据所述用户身份标识，检测是否存在与所述用户身份标识对应的未推送的推送消息；当检测到存在与所述用户身份标识对应的未推送的推送消息后，将所述未推送的推送消息发送给消息请求方。该方法提高了服务器向客户端发送推送消息时，推送消息的到达率。

Description

推送消息发送方法、装置、电子设备及可读存储介质

技术领域

本申请涉及通信技术领域，尤其是涉及一种推送消息发送方法、装置、电子设备及可读存储介质。

背景技术

目前，服务器通常采用推送的方式，向客户端发送推送消息。

推送的过程一般包括：服务器产生一条推送消息，将推送消息发送给第三方推送平台；在推送消息中携带有用于表征推送目标身份的信息；第三方推送平台在接收到推送消息后，主动根据推送消息中携带的表征推送目标身份的信息，将推送消息推送给对应的客户端。当客户端接收到第三方推送平台推送的推送消息后，就能够将推送消息展示给用户。

然而，由于第三方推送平台的推送服务存在诸多限制因素和不稳定因素，从而造成推送的推送消息到达率比较低。

发明内容

有鉴于此，本申请的目的在于提供推送消息发送方法、装置、电子设备及可读存储介质，提高服务器向客户端发送推送消息时，推送消息的到达率。

第一方面，本申请实施例提供了一种推送消息发送方法，包括：

获取消息请求；所述消息请求中携带有用户身份标识；

根据所述用户身份标识，检测是否存在与所述用户身份标识对应的未推送的推送消息；

当检测到存在与所述用户身份标识对应的未推送的推送消息后，将所述未推送的推送消息发送给消息请求方。

一种可能的实施方中，所述未推送的推送消息包括：个人消息和/或公告消息。

一种可能的实施方中，针对所述未推送的推送消息包括个人消息的情况，采用下述方式检测是否存在与所述用户身份标识对应的未推送的推送消息：

根据所述用户身份标识，确定与所述用户身份标识对应的未推送集合；

检测所述未推送集合中是否存在所述未推送的推送消息；

如果所述未推送集合中存在所述未推送的推送消息，则确定存在与所述用户身份标识对应的未推送的推送消息。

一种可能的实施方式中，将所述未推送的推送消息发送给消息请求方，包括：

将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方。

一种可能的实施方式中，所述将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，还包括：

将所述未推送的推送消息从所述未推送集合中删除；

或者，

所述消息请求中还携带有已接收指令；

所述将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，还包括：

根据所述消息请求中携带的已接收指令，清空所述未推送集合。

一种可能的实施方式中，还包括：

生成个人消息；所述个人消息对应有用户身份标识；

根据所述用户身份标识，将所述生成的个人消息存储到与所述用户身份标识对应的未推送集合中。

一种可能的实施方式中，还包括：

检测最后一个存储到所述未推送集合中的未推送的推送消息的存储时间，距离当前时间的时间段，是否超过第一预设时间段；

并在超过所述第一预设时间段后，清空所述未推送集合。

一种可能的实施方式中，根据所述用户身份标识，将所述生成的个人消息存储到与所述用户身份标识对应的未推送集合中，包括：

根据所述用户身份标识，确定与所述身份标识对应的未推送集合；

在当前未推送集合中已存储的未推送的推送消息满足预设消息数量的时候，将存储时间段最长的所述未推送的推送消息从所述未推送集合中删除，并将生成的个人消息存储在所述未推送集合中。

检测所述未推送集合中保存的未推送的推送消息的数量是否达到预设的数量阈值；

如果达到所述数量阈值，则将在所述未推送集合中存储时间最久的未推送的推送消息从所述未推送集合中删除，并将生成的个人消息保存在所诉未推送集合中。

一种可能的实施方式中，在生成个人消息之后，还包括：将生成的个人消息推送给消息请求方；

并将生成的个人消息存储在未读消息集合中；

当接收到所述消息请求方对所述生成的个人消息反馈的已读指令后，将所述生成的个人消息从所述未读消息集合中删除，以及

将所述生成的个人消息从所述未推送集合中删除。

一种可能的实施方式中，还包括：

检测最后一个存储到所述未读消息集合中的生成的个人消息的存储时间，距离当前时间的时间段是否超过第三预设时间段；

并在超过所述第三预设时间段后，清空所述未读消息集合。

一种可能的实施方式中，针对所述未推送的推送消息包括公告消息的情况，采用下述方式检测是否存在与所述用户区域标识对应的未推送的推送消息：

根据所述用户身份标识，确定所述用户区域标识，并根据所述用户区域标识确定与所述用户区域标识对应的目标公告消息集合；

从所述目标公告消息集合中，确定是否存在所述未推送的推送消息；

或者，所述消息请求中携带有用户区域标识；

采用下述方式检测是否存在与所述用户区域标识对应的未推送的推送消息：

根据所述消息请求中携带的所述用户区域标识，确定与所述用户区域标识对应的目标公告消息集合；

从所述目标公告消息集合中，确定是否存在所述未推送的推送消息。

一种可能的实施方式中，还包括：根据所述用户身份标识，确定与所述用户身份标识对应的已接收消息标识；

或者，所述消息请求中还携带有已接收消息标识；

所述从所述目标公告消息集合中，确定是否存在所述未推送的推送消息，包括：

根据所述已接收消息标识，从所述目标公告消息集合中确定是否存在所述未推送的推送消息。

一种可能的实施方式中，所述目标公告消息集合中所存储的每条推送消息均对应有消息标识；

根据所述已接收消息标识，从所述目标公告消息集合中确定是否存在所述未推送的推送消息，包括：

检测所述目标公告消息集合中是否存在消息标识大于所述已接收消息标识的推送消息；

如果存在，则将所述目标公告消息集合中存在的消息标识大于所述已接收消息标识的推送消息，确定为所述未推送的推送消息。

一种可能的实施方式中，根据所述用户身份标识，确定与所述用户身份标识对应的已接收消息标识，包括：

根据所述用户身份标识，检测是否存在与所述用户身份标识对应的已接收消息标识；

如果不存在，则将目标公告消息集合中推送消息所具有的最大的消息标识确定为所述已接收消息标识。

一种可能的实施方式中，将所述未推送的推送消息发送给消息请求方之后，还包括：使用目标公告消息集合中推送消息所具有的最大的消息标识更新所述已接收消息标识。

一种可能的实施方式中，还包括：生成公告消息；所述公告消息对应有至少一个用户区域标识；

根据所述公告消息的用户区域标识，将生成的所述公告消息存储到与所述用户区域标识对应的公告消息集合中，并根据与所述用户区域标识对应的公告消息集合中已存储的各个公告消息的消息标识，为生成的所述公告消息添加消息标识。

第二方面，本申请实施例还提供一种推送消息发送装置，包括：

获取模块，用于获取消息请求；所述消息请求中携带有用户身份标识；

检测模块，用于根据所述用户身份标识，检测是否存在与所述用户身份标识对应的未推送的推送消息；

发送模块，用于当检测到存在与所述用户身份标识对应的未推送的推送消息后，将所述未推送的推送消息发送给消息请求方。

一种可能的实施方式中，未推送的推送消息包括：个人消息和/或公告消息。

一种可能的实施方式中，针对所述未推送的推送消息包括个人消息的情况，检测模块，具体用于，采用下述方式检测是否存在与所述用户身份标识对应的未推送的推送消息：

检测所述未推送集合中是否存在所述未推送的推送消息；

一种可能的实施方式中，发送模块，具体用于，将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方。

一种可能的实施方式中，所述装置，还包括：删除模块，用于在将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，将所述未推送的推送消息从所述未推送集合中删除。

或者，

所述消息请求中还携带有已接收指令；

一种可能的实施方式中，所述装置，还包括：生成模块，用于生成个人消息；所述个人消息对应有用户身份标识；

一种可能的实施方式中，所述装置，还包括：存储容量控制模块，用于检测最后一个存储到所述未推送集合中的未推送的推送消息的存储时间，距离当前时间的时间段，是否超过第一预设时间段；

并在超过所述第一预设时间段后，清空所述未推送集合。

一种可能的实施方式中，所述生成模块，还用于根据所述用户身份标识，确定与所述身份标识对应的未推送集合；

一种可能的实施方式中，所述存储容量控制模块，还用于检测所述未推送集合中保存的未推送的推送消息的数量是否达到预设的数量阈值；

一种可能的实施方式中，所述装置，还包括：未读检测模块，用于并将生成的个人消息存储在未读消息集合中；

将所述生成的个人消息从所述未推送集合中删除。

一种可能的实施方式中，所述存储容量控制模块，还用于检测最后一个存储到所述未读消息集合中的生成的个人消息的存储时间，距离当前时间的时间段是否超过第三预设时间段；

并在超过所述第三预设时间段后，清空所述未读消息集合。

一种可能的实施方式中，针对所述未推送的推送消息包括公告消息的情况，检测模块，具体用于，采用下述方式检测是否存在与所述用户区域标识对应的未推送的推送消息：

根据所述用户身份标识，确定所述用户区域标识，并根据所述用户区域标识确定与所述用户区域标识对应的目标公告消息集合；从所述目标公告消息集合中，确定是否存在所述未推送的推送消息；

或者，所述消息请求中携带有用户区域标识；

根据所述消息请求中携带的所述用户区域标识，确定与所述用户区域标识对应的目标公告消息集合；从所述目标公告消息集合中，确定是否存在所述未推送的推送消息。

一种可能的实施方式中，检测模块，还用于，根据所述用户身份标识，确定与所述用户身份标识对应的已接收消息标识；

或者，所述消息请求中还携带有已接收消息标识；

一种可能的实施方式中，所述目标公告消息集合中所存储的每条推送消息均对应有消息标识；检测模块，还用于，

一种可能的实施方式中，还包括：已接受消息表示确定模块，用于根据所述用户身份标识，检测是否存在与所述用户身份标识对应的已接收消息标识；

一种可能的实施方式中，已接受消息表示确定模块，还用于将所述未推送的推送消息发送给消息请求方之后，还包括：使用目标公告消息集合中推送消息所具有的最大的消息标识更新所述已接收消息标识。

一种可能的实施方式中，生成模块，还用于，生成公告消息；所述公告消息对应有至少一个用户区域标识；

第三方面，本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面的任一种可能的实施方式中的步骤。

第四方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面的任一种可能的实施方式中的步骤。

本申请实施例是在接收到消息请求方发送的消息请求后，通过消息请求中携带的用户身份标识，检测是否存在与所述用户身份标识对应的未推送的消息信息，并将未推送的推送信息发送给消息请求方，与现有技术中的通过第三方推送平台将消息信息推送给客户端相比，基于消息请求方的主动请求进行推送，大幅提升了消息的到达率。

进一步，本申请实施例还可以通过最后一个存储到所述未推送集合中的未推送的消息信息的存储时间，或者通过当前未推送集合中已存储的未推送的消息信息的消息数量，控制未推送的消息信息的存储量，防止冗余的未推送的消息信息长期占据存储空间。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例所提供的推送消息发送方法的流程图；

图2示出了本申请实施例所提供的另一种推送消息发送方法的流程图；

图3示出了推送消息发送方法中推送消息的流转路径；

图4示出了本申请实施例所提供的一种推送消息发送装置的结构示意图；

图5示出了一种推送消息发送系统的组织架构图；

图6示出了本申请实施例所提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，服务器通常采用推送的方式，向客户端发送推送消息,使用应用级别的第三方推送平台，如极光推送、小米推送、阿里推送、友盟推送，信鸽等，消息接收方因此需要安装相应的第三方推送平台的应用。但是第三方推送平台的推送服务存在诸多限制因素和不稳定因素，例如：当发生消息接收方设备重启、或消息接收方应用闪退等情况时，都会造成消息接收方无法收到推送消息，从而造成推送的推送消息到达率比较低。

另外发送公告消息的时候，需要向预设区域范围内所有消息接收方发送公告效力，例如如果向北京区域全城数万消息接收方发送公告消息，现有方案是向每个消息接收方生成一条公告消息发送出去，因为服务器还需要实现查看公告消息列表、查看公告消息详情等功能，并且需要存储已读公告消息、未读公告消息等信息，需要公告消息标识和用户身份标识之间的对应关系单独存储在数据库中。也就是说，发送一个公告消息，会在服务器中产生并存储数万条数据，需要占用服务器中很大部分的存储资源。

并且有些僵尸用户可能永远不会查看上述推送消息，导致服务器中与这些僵尸用户的用户身份标识关联的个人消息和公告消息的相应存储资源被浪费。

因此，现有技术的推送消息发送方法，除了存在到达率较低的问题外，还存在浪费服务器中的存储资源、服务器中的推送消息数据数量过大、维护困难的问题。

示例性的，本申请实施例中的消息请求方包括：用户端，上述用户端可以理解为终端设备，也可以理解为用户在平台注册的用户端。

为便于对本实施例进行理解，首先对本申请实施例所公开的一种推送信息发送方法进行详细介绍。本申请实施例中，执行推送信息发送方法的设备，可以是专门用于对向消息请求方发送消息信息的服务设备，任一种需要向消息请求方消息信息的具体服务器，例如，可以是快递平台的服务器、交易平台的服务器、网约车平台的服务器、外卖平台的服务器、天气服务平台的服务器或社交平台的服务器等。下面从执行主体为快递平台的服务器角度，对本申请实施例一所提供的推送信息发送方法加以说明。

实施例一

如图1所示，本申请实施例一提供一种推送信息发送方法,包括以下步骤S101～S103：

S101：获取消息请求；所述消息请求中携带有用户身份标识。

在具体实现的时候，消息请求方每隔预定时间段，例如，每隔1分钟，主动向服务器发送消息请求，并且所述消息请求中携带有用户身份标识。上述用户身份标识，可以包括消息请求方的身份标识号码(Identification Card，ID，以下简称消息请求方ID)。

S102：根据所述用户身份标识，检测是否存在与所述用户身份标识对应的未推送的推送消息。

在具体实现的时候，所述未推送的推送消息包括：个人消息和/或公告消息。

其中，个人消息是指与用户对应的，仅仅需要推送给单独用户的消息；公告消息，是指与多个用户对应的，需要推送给一类具有某个共同特征用户的消息，例如推送给地理位置属于同一区域的用户的消息、推送给使用同一服务器进行数据交互的用户的消息等。

本申请实施例首先针对所述未推送的推送消息包括个人消息的情况进行说明。

在具体实施中，本申请实施例采用下述步骤生成个人消息：

生成个人消息；所述个人消息对应有用户身份标识；

这里，服务器生成的个人消息，可以由消息本体和消息标识两部分组成，上述消息标识可以包括个人消息的消息身份标识号码(Identification Card，ID)。

在具体实现的时候，每个生成的个人消息，对应有消息类型。不同消息类型的个人消息重要程度不同，因此可以两种不同的实施方式存储生成的个人消息。从而在保证数据存储效率和读取效率的基础上，提高个人消息的稳定性。

其一：在一种可能的实施方式中，重要程度较高的个人消息需要长期保存在服务器的内部存储中，例如MySQL数据库的稳定性较好，可以将重要程度较高的个人消息存储在MySQL数据库中。

例如涉及现金交易的个人消息，重要程度较高，需要将涉及现金交易的个人消息长期保存在服务器的内部存储中，因此将涉及现金交易的个人消息存储在MySQL数据库中。

针对MySQL数据库的存储特点，索引信息可以包括消息请求方ID，并将上述生成的个人消息的消息标识和消息本体作为MySQL数据库中的一条数据存储。同时，将生成的个人消息的消息标识存储到未推送集合中。

为了更方便快速的对生成的个人消息进行查找，上述索引信息还可以包括上述生成的个人消息对应的消息类型，和/或上述生成的个人消息的消息标识对应的存储类型，例如上述生成的个人消息的消息标识是否存储在未推送集合中等。

在从未推送集合中获取未推送的推送消息的消息标识后，从MySQL数据库中获取未推送的推送消息的消息本体。

其二：在另一种可能的实施方式中，重要程度较低的个人消息可以短期保存在服务器的内部存储中，例如Redis数据库实时性高、速度快，但稳定性不高，可以将重要程度较低的个人消息存储在Redis数据库中。

例如，新订单提醒的个人消息，重要程度较低，可以将新订单提醒的个人消息短期保存在服务器的内部存储中，因此将新订单提醒的个人消息存储在Redis数据库中。

针对Redis数据库的存储特点，可以把生成的个人消息的消息主体存储到哈希hash结构中，并将生成的个人消息的消息标识存储到未推送集合中。在从未推送集合中获取未推送的推送消息的消息标识后，从哈希hash结构中获取未推送的推送消息的消息本体。

这里，由于存储在Redis数据库中的个人消息的重要程度较低，因此，长期未被推送的个人消息会被认为是冗余的个人消息，这些冗余的个人消息意义不大，却会占用宝贵的服务器存储空间，增加服务器的存储成本和数据维护成本。尤其在有些用户是僵尸用户的情况下，这些僵尸用户可能永远不会打开用户端，导致此时服务器存储这些个人消息的存储空间是完全被浪费的。

这里，可以根据消息类型，以在服务器中为不同消息类型对应的未推送的推送消息设置不同的存储方式，例如通过设置文件对存储方式进行设置。

因此，本申请实施例通过控制未推送的推送消息的存储量，防止冗余的未推送的推送消息长期占据存储空间，可以选择以下方案中的任一种清除冗余的推送消息：

其一：一种可能的实施方式中，根据所述用户身份标识，将所述个人消息存储到与所述用户身份标识对应的未推送集合中，包括：根据所述用户身份标识，确定与所述身份标识对应的未推送集合；在当前未推送集合中已存储的个人消息满足预设消息数量的时候，将存储时间段最长的所述个人消息从所述未推送集合中删除，并将生成的个人消息存储在所述未推送集合中。

另一种可能的实施方式中，在与所述用户身份标识对应的未推送集合中，存储的是个人消息的消息标识的情况下，

根据所述用户身份标识，确定与所述身份标识对应的未推送集合；在当前未推送集合中已存储的消息标识满足预设消息数量的时候，将存储时间段最长的消息标识从所述未推送集合中删除，并将生成的个人消息的消息标识存储在所述未推送集合中。

从所述未推送集合中删除的存储时间段最长的消息标识对应的消息主体，也会在哈希hash结构中删除。

其二：一种可能的实施方式中，根据所述用户身份标识，将所述个人消息存储到与所述用户身份标识对应的未推送集合中之后，还包括：

根据所述用户身份标识，确定与所述身份标识对应的预设长度的先入先出队列，例如，链表list；在所述先入先出队列达到预设长度时，将生成的个人消息存储在所述先入先出队列的头部，将所述先入先出队列中尾部的所述个人消息从所述先入先出队列中删除，并将未推送集合中与所述先入先出队列中尾部的所述个人消息对应的未推送的推送消息，从未推送集合中删除。

并且，检测最后一个存储到所述先入先出队列中的个人消息的存储时间，距离当前时间的时间段，是否超过第二预设时间段；并在超过所述第二预设时间段后，清空所述先入先出队列。

另一种可能的实施方式中，可以将生成的个人消息的消息标识存储到先入先出队列中，

根据所述用户身份标识，确定与所述身份标识对应的预设长度的先入先出队列，例如，链表list；在所述先入先出队列达到预设长度时，将生成的个人消息的消息标识存储在所述先入先出队列的头部，将所述先入先出队列中尾部的消息标识从所述先入先出队列中删除，并将未推送集合中与所述先入先出队列中尾部的消息标识对应的未推送的推送消息，或未推送集合中与所述先入先出队列中尾部的消息标识相同的消息标识，从未推送集合中删除。

并且，检测最后一个存储到所述先入先出队列中的消息标识的存储时间，距离当前时间的时间段，是否超过第二预设时间段；并在超过所述第二预设时间段后，清空所述先入先出队列。

从所述先入先出队列中尾部删除消息标识对应的消息主体，也会在哈希hash结构中删除。同理，清空所述先入先出队列时，所述先入先出队列中存储的每个消息标识对应的消息主体，也会在哈希hash结构中删除。

其三：一种可能的实施方式中，检测最后一个存储到所述未推送集合中的未推送的推送消息的存储时间，距离当前时间的时间段，是否超过第一预设时间段；并在超过所述第一预设时间段后，清空所述未推送集合。

检测最后一个存储到所述未推送集合中的消息标识的存储时间，距离当前时间的时间段，是否超过第一预设时间段；并在超过所述第一预设时间段后，清空所述未推送集合。

清空所述未推送集合时，所述未推送集合中存储的每个消息标识对应的消息主体，也会在哈希hash结构中删除。

其四：一种可能的实施方式中，检测最后一个存储到所述哈希hash结构中的消息主体的存储时间，距离当前时间的时间段，是否超过第四预设时间段；并在超过所述第四预设时间段后，清空所述哈希hash结构。

这里，针对所述未推送的推送消息包括个人消息的情况，采用下述方式检测是否存在与所述用户身份标识对应的未推送的推送消息：

根据所述用户身份标识，确定与所述用户身份标识对应的未推送集合；检测所述未推送集合中是否存在所述未推送的推送消息；如果所述未推送集合中存在所述未推送的推送消息，则确定存在与所述用户身份标识对应的未推送的推送消息。

然后，针对所述未推送的推送消息包括公告消息的情况进行说明。

这里，本申请实施例所述方法，还包括生成公告消息的过程：

生成公告消息；所述公告消息对应有至少一个用户区域标识；

一种可能的实施方式为，为生成的所述公告消息添加的消息标识为数字，并且每生成一个公告信息，为生成的所述公告消息添加的消息标识加一。

在具体实现的时候，由于公告消息的数量不大，且公告消息一般具备长期保存的价值。因此，在一种可能的实施方式中，将公告消息的消息本体和消息标识保存在MySQL数据库中。

然而，除了公告消息的消息标识和消息本体外，服务器还需要存储于用户个人相关的信息，包括与用户身份标识对应的已接收消息标识、未读消息集合等个人数据，为了防止从来不登录的僵尸用户的个人相关的公告消息过多的占用服务器的存储资源。在一种可能的实施方式中，可以将与用户身份标识对应的已接收消息标识、未读消息集合等个人数据存储在Redis数据库中。

并且为存储在Redis数据库中的个人数据针对每个用户身份标识，分别设置第五预设时间段，例如，3个月；在每个用户身份标识中存在超过第五预设时间段的相应的个人数据时，将超过第五预设时间段的个人数据清空。

针对所述未推送的推送消息包括公告消息的情况，采用下述方式检测是否存在与所述用户区域标识对应的未推送的推送消息：

或者，所述消息请求中携带有用户区域标识；

在实际实施过程中，在一种可能的实施方式中，根据所述用户身份标识，确定与所述用户身份标识对应的已接收消息标识；或者在另一种可能的实施方式中，所述消息请求中还携带有已接收消息标识。

获取已接收消息标识后，所述从所述目标公告消息集合中，确定是否存在所述未推送的推送消息，包括：

一种可能的实施方式中，公告消息的消息标识为数字，因此上述已接收消息标识也是一个数字。

所述目标公告消息集合中所存储的每条推送消息均对应有消息标识；

检测所述目标公告消息集合中是否存在消息标识大于所述已接收消息标识的推送消息；如果存在，则将所述目标公告消息集合中存在的消息标识大于所述已接收消息标识的推送消息，确定为所述未推送的推送消息。

通过比较消息标识和已接收消息标识两个数字的大小，将所述目标公告消息集合中存在的消息标识大于所述已接收消息标识的推送消息，确定为所述未推送的推送消息。

并且，将所述未推送的推送消息发送给消息请求方之后，还包括：使用目标公告消息集合中推送消息所具有的最大的消息标识更新所述已接收消息标识。

这里，为了在数据损坏、已接收消息标识丢失的情况下，或者在消息接收方第一次接收公告消息的情况下，系统在接收未推送的推送消息时发生错误，根据所述用户身份标识，确定与所述用户身份标识对应的已接收消息标识，包括：

根据所述用户身份标识，检测是否存在与所述用户身份标识对应的已接收消息标识；如果不存在，则将目标公告消息集合中推送消息所具有的最大的消息标识确定为所述已接收消息标识。

并且，在实际实施的过程中，在一种可能的实施方式中，可以根据所述用户身份标识，确定与所述用户身份标识对应的已读消息标识；或者在另一种可能的实施方式中，所述消息请求中还携带有已读消息标识。

获取已接收消息标识后，所述从所述目标公告消息集合中，确定是否存在所述未读的推送消息，包括：

根据所述已读消息标识，从所述目标公告消息集合中确定是否存在所述未读的推送消息。

根据所述已读消息标识，从所述目标公告消息集合中确定是否存在所述未推送的推送消息，包括：

检测所述目标公告消息集合中是否存在消息标识大于所述已读消息标识的推送消息；如果存在，则将所述目标公告消息集合中存在的消息标识大于所述已读消息标识的推送消息，将其消息标识加入到未读消息集合中。

并且，使用所述目标公告消息集合中最大的消息标识更新所述已读消息标识。

在发送未推送的推送消息时，发送未读消息集合；根据未读消息集合，在用户端将未读消息结合中的消息标识对应的推送消息标记为未读状态，并展示给用户。

为了防止在服务器数据清空，或消息接收方数据情况的情况下，消息接收方接收到的所有公告消息都被标记为未读的异常情况，提升客户体验，根据所述用户身份标识，确定与所述用户身份标识对应的已读消息标识，包括：

根据所述用户身份标识，检测是否存在与所述用户身份标识对应的已读消息标识；如果不存在，则将目标公告消息集合中推送消息所具有的最大的消息标识确定为所述已读消息标识。

这里，在实际实施过程中，如果发生在服务器获取定时发送的消息请求之前，用户通过手动刷新用户端的方式，向服务器发送消息请求的情况，或者发生服务器使用了第三方推送平台，在生成公告消息时，向消息接收方发送了生成的公告消息的情况，公告消息可能会被重复接收和重复提醒。

为了防止重复接收和重复提醒公告消息，提升用户体验。在一种可能的实施方式中，在对已接收消息标识进行更新前，还包括：

比较已接收消息标识和已读消息标识的大小，使用已接收消息标识和已读消息标识中的最大值，更新已接收消息标识。

S103：当检测到存在与所述用户身份标识对应的未推送的推送消息后，将所述未推送的推送消息发送给消息请求方。

这里，所述未推送的推送消息包括：个人消息和/或公告消息。

首先，针对所述未推送的推送消息包括个人消息的情况进行说明。

这里，将所述未推送的推送消息发送给消息请求方，包括：

这里，所述将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，还包括将所述未推送的推送消息从所述未推送集合中删除的步骤。

在实际实施过程中，可以选择以下方案中的任一种将所述未推送的推送消息从所述未推送集合中删除。

其一：可以在将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，服务器直接将将所述未推送的推送消息从所述未推送集合中删除。

其二：由于，即使使用服务器获取消息请求后，将推送消息定向发送给消息接收方的发送方式，还是有可能因为网络异常、消息接收方的设备异常等情况，出现消息没有被消息接收方接收到的情况，因此，可以在所述消息请求中携带有已接收集合；

所述将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，还包括：根据所述消息请求中携带的已接收集合，将所述已接收集合对应的未推送的推送消息从所述未推送集合中删除。

其三：在消息接收方向服务器发送消息请求的时间间隔足够小的情况下，还可以采用如下一种可能的实施方式简化操作流程：在所述消息请求中携带有已接收指令；

所述将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，还包括：根据所述消息请求中携带的已接收指令，清空所述未推送集合。

其四：为了保证个人消息被用户接受并读取，还可以在服务器接收到消息请求放发送删除指令时，将所述未推送的推送消息从未推送集合中删除。

这里，可以根据消息类型，以在服务器中为不同消息类型对应的未推送的推送消息设置不同的删除方式，例如通过设置文件对删除方式进行设置。

这里，在生成个人消息之后，还包括：将生成的个人消息推送给消息请求方；并将生成的个人消息存储在未读消息集合中；当接收到所述消息请求方对所述生成的个人消息反馈的已读指令后，将所述生成的个人消息从所述未读消息集合中删除，以及将所述生成的个人消息从所述未推送集合中删除。

这里，消息接收方在接收到未读消息集合中的个人消息后，将未读消息集合中的个人消息标记为未读状态，向用户显示，例如，一种可能的实施方式中，用户端接收到未读消息集合中的个人消息后，通过将未读消息集合中的个人消息标记上小红点，向用户标明此个人消息为未读状态。并在用户调用标为已读接口或者获取详情节后后，将此未读状态消除，同时向服务器反馈已读指令。

在实际实施时，在生成个人消息后，可以利用第三方推送平台将生成的个人消息推送给消息请求方。

在一种可能的实施方式中，可以在生成个人消息之后，将生成的个人消息加入到未推送集合中，在利用第三方推送平台将生成的个人消息推送给消息请求方后，将所述生成的个人消息从未推送集合中删除。但是由于采用第三方推送平台推送生成的个人消息时，其推送消息到达率较低。

因此，在另一种可能的实施方式中，在生成个人消息之后，将生成的个人消息加入到未推送集合和未读消息集合中，在利用第三方推送平台将生成的个人消息推送给消息请求方后，不将生成的个人消息从未推送集合和未读消息集合中删除。而是等到接收到所述消息请求方对所述生成的个人消息反馈的已读指令后，如果所述消息请求方对所述生成的个人消息反馈已读指令，表明所述生成的个人消息已经确定被消息请求方接收到，此时将所述生成的个人消息从所述未读消息集合中删除，以及将所述生成的个人消息从所述未推送集合中删除。

再结合本申请实施例所述方法，消息请求方每隔预定时间段主动向服务器发送消息请求，接收服务器根据用户身份标识确定的上述用户身份标识对应的未推送的推送消息，可以大幅提升推送消息的到达率。

在上述另一种可能的实施方式中，由于利用第三方推送平台将生成的个人消息推送给消息请求方后，不将生成的个人消息从未推送集合和未读消息集合中删除，有可能出现，在第三方推送平台将生成的个人消息推送给消息请求方后，在所述消息请求方对所述生成的个人消息反馈的已读指令之前，服务器获取到消息请求，向消息请求方发送未推送集合中的未推送的推送消息中包含已经由第三方推送平台推送的生成的个人消息的情况。因此，消息请求方在接收到未推送的推送消息时，根据消息标识检查是否存在重复接收的推送消息，如果存在，将重复接收的推送消息删除。

这里，也可以通过检测最后一个存储到所述未读消息集合中的个人消息的存储时间，距离当前时间的时间段是否超过第三预设时间段；并在超过所述第三预设时间段后，清空所述未读消息集合。从而防止长期未读的冗余的个人消息占用存储资源的情况。

这里，未读消息集合中也可以只存储个人消息的消息标识，当清空上述未读消息集合时，将上述未读消息集合中的消息标识对应的消息本体从哈希hash结构中删除。

这里，为了保证未读信息集合的存储稳定性，将未读信息集合存储在服务器中。

接下来，针对所述未推送的推送消息包括公告消息的情况进行说明。

在实际实施过程中，将所述未推送的推送消息发送给消息请求方后，如果消息请求方阅读公告消息后，可以选择以下方案中将所述公告消息的消息ID从所述未读消息集合中删除。

在消息请求方的用户端调用获取公告详情接口后，消息接收方向服务器反馈已读指令；服务器接收到消息接收方反馈的已读指令后，清空所述未读消息集合。

在一种具体的场景下，当服务器需要向消息接收方发送消息类型为提现成功消息的个人消息时，由于提现成功消息具有永久存储的价值，因此在服务器中将该消息类型的存储方式配置为使用MySQL数据库进行存储。当用户提现成功后，服务器生成消息类型为提现成功消息的个人消息，在生成消息类型为提现成功消息的个人消息后，可以通过第三方推送平台将上述个人消息推送给消息接收方，从而保证推送消息接收的实时性，然后通过定时接收消息接收方的消息请求后，向消息接收方发送未推送的推送消息的方式，例如轮询的方式，保证消息接收方可以100％地接收到推送消息，并消息接收方的用户端接收到上述个人消息后，可以存储在用户端的个人中心的消息列表中，通过个人中心的消息列表向用户提供历史的提现成功消息。当消息接收方接收到服务器生成的消息类型为提现成功消息的个人消息后，在消息接收方的用户端将上述个人消息标识为未读，并且消息接收方的用户端检测到消息详情接口被点击后，将上述个人消息标识为已读。

在一种具体的场景下，当服务器需要向消息接收方发送消息类型为新订单提醒的个人消息时，由于新订单提醒的个人消息不具备永久存储的价值，因此在服务器中将该消息类型的存储方式配置为使用Redis数据库进行存储。并且在用户接受到新订单提醒后，新订单提醒的个人消息就已经不具备保存的价值了，因此，在服务器中将该消息类型的删除方式设置为推送成功即删除。由于新订单需要及时被派送，因此新订单提醒的个人消息的时效性较强，需要被实时推送。因此，在生成消息类型为新订单提醒的个人消息后，需要通过第三方推送平台将上述个人消息推送给消息接收方，因为推送消息的到达率问题，在第三方推送平台推送给消息接收方的基础上，通过定时接收消息接收方的消息请求后，向消息接收方发送未推送的推送消息的方式，例如轮询的方式，再次确保消息接收方可以接收到上述个人消息，例如，在30s后，消息接收方向服务器发送消息请求，从而收到新订单提醒的个人消息。在1分钟后，消息接收方再次向服务器发送消息请求时，回传给服务器本次收到的消息标识，服务器收到后，即可确认消息接收方已收到新订单提醒的个人消息，将新订单提醒的个人消息删除，从而不会再次提醒。

在一种具体的场景下，当服务器需要向北京地区的消息接收方发送消息类型为天气提醒的公告消息，公告消息的内容为：“下午有大雨，注意出行安全”时，由于公告消息具备永久存储的价值，因此在服务器中将该消息类型的存储方式配置为使用MySQL数据库进行存储。服务器发送公告消息的时候，不需要获取所有北京地区的消息接收方进行逐个推送，也不需要存储北京地区的消息接收方的公告读取状态。消息接收方会每分钟向服务器发送消息请求，服务器判断消息接收方的用户区域信息，如果消息接收方是属于北京地区的，且这条公告消息的消息标识大于上述消息接收方收到的已接收消息标识，则把这条公告消息发送给消息接收方。消息接收方收到公告消息后，有声音提醒，在消息接收方向服务器发送消息请求时，消息请求携带已接收消息标识，服务器更新服务器中存储的已接收消息标识，且不会再次向消息接收方发送上述公告消息。消息接收方获取未读消息集合，如果上述公告消息的消息标识大于服务器存储器中缓存的已读消息标识，则在消息接收方的用户端将该公告消息标记为未读，并在消息接收方的用户端的公告列表看到有未读公告消息，消息接收方的用户端检测到用户点击进入详情查看后，将该公告消息标记为已读。

实施例二

本申请实施例二提供了从执行主体为快递平台的服务器角度，具体的推送消息发送方法的实施方式。如图2所示，本申请实施例二提供的推送消息发送方法包括以下步骤S201～S205，本申请实施例二提供的推送消息发送方法中推送消息的流转路径如图3所示：

S201：生成推送消息。

这里，服务器也可以接受消息产出方生成的推送消息，将消息产出方生成的推送消息作为消息本体存储在服务器的存储资源中，并且为消息产出方生成的推送消息生成消息标识，为每个推送消息对应消息类型。

这里，生成的推送消息包括个人消息和公告消息。

在生成推送消息时，同时生成消息本体和消息标识，并且每个推送消息对应有消息类型。

S202：存储推送消息。

根据每个推送消息的消息类型，获取每个推送消息的消息类型对应的推送消息的存储方式。根据推送消息的存储方式，将每个推送消息存储到不同的数据库中。

如果所述推送消息为公告消息，将推送消息存储在可靠性高的数据库中，例如存储在MySQL数据库中。

如果所述推送消息为个人消息，根据消息类型，判断所述个人消息是否需要可靠存储，将需要可靠存储的个人消息存储在可靠性高的数据库中，例如存储在MySQL数据库中；将不需要可靠存储的个人消息存储在可靠性一般，但读取速度和存储速度较高的数据库中，例如存储在Redis数据库中。

为了节省服务器的存储资源，通过检测最后一个存储到所述未推送集合中的未推送的推送消息的存储时间，当前未推送集合中已存储的未推送的推送消息的消息数量，控制未推送的推送消息的存储量，防止冗余的未推送的推送消息长期占据存储空间。控制未推送的推送消息的存储量的方法在本申请实施例一中已经进行了详细的论述，此处不再赘述。

S203：获取消息请求；所述消息请求中携带有用户身份标识。

S204：根据所述用户身份标识，检测是否存在与所述用户身份标识对应的未推送的推送消息。

针对所述未推送的推送消息包括个人消息的情况，采用下述方式检测是否存在与所述用户身份标识对应的未推送的推送消息：

或者，所述消息请求中携带有用户区域标识；采用下述方式检测是否存在与所述用户区域标识对应的未推送的推送消息：

S205：当检测到存在与所述用户身份标识对应的未推送的推送消息后，将所述未推送的推送消息发送给消息请求方。

这里，服务器也可以通过第三方推送平台，在生成推送消息后，将生成的推送消息主动推送给消息接收方。

将所述未推送的推送消息发送给消息请求方，包括：将未推送的推送消息的消息本体和消息标识都推送给消息接收方。

在实际实施过程中，可以选择多种方案将所述未推送的推送消息从所述未推送集合中删除。将所述未推送的推送消息从所述未推送集合中删除的方案在在本申请实施例一中已经进行了详细的论述，此处不再赘述。

基于相同的技术构思，本申请实施例还提供一种推送消息发送装置、电子设备、以及计算机存储介质等，具体可参见以下实施例。

实施例三

如图4所示，本申请实施例三提供的一种推送消息发送装置400，包括：

获取模块401，用于获取消息请求；所述消息请求中携带有用户身份标识。

一种可能的实施方中，生成模块，还用于，生成公告消息；所述公告消息对应有至少一个用户区域标识；

检测模块402，用于根据所述用户身份标识，检测是否存在与所述用户身份标识对应的未推送的推送消息。

未推送的推送消息包括：个人消息和/或公告消息。

针对所述未推送的推送消息包括个人消息的情况，检测模块，具体用于，采用下述方式检测是否存在与所述用户身份标识对应的未推送的推送消息：

检测所述未推送集合中是否存在所述未推送的推送消息；

并在超过所述第一预设时间段后，清空所述未推送集合。

并在超过所述第三预设时间段后，清空所述未读消息集合。

或者，所述消息请求中携带有用户区域标识；

或者，所述消息请求中还携带有已接收消息标识；

发送模块403，用于当检测到存在与所述用户身份标识对应的未推送的推送消息后，将所述未推送的推送消息发送给消息请求方。

或者，

所述消息请求中还携带有已接收指令；

将所述生成的个人消息从所述未推送集合中删除。

一种可能的实施方中，已接受消息表示确定模块，还用于将所述未推送的推送消息发送给消息请求方之后，还包括：使用目标公告消息集合中推送消息所具有的最大的消息标识更新所述已接收消息标识。

实施例四

本申请实施例三提供的一种推送消息发送系统500的组织架构图如图5所示，包括：

消息发送方501：用于生成发送的公告消息和个人消息。

公告消息，包括消息本体和用户区域标识；个人消息包括消息本体和用户身份标识。

消息系统502，包括：公告消息模块5021和个人消息模块5022。

公告消息模块5021，包括：

MySQL数据库50211，用于存储公告消息内容、公告消息对应的更新时间、公告消息对应的消息类型和公告消息对应的用户区域标识等；

控制器50212，用于控制公告消息的发送过程；

Redis管理器50213，用于存储用户区域标识和用户身份标识对应的已接收消息标识。

个人消息模块5022，包括：

消息类型配置模块50221：用于根据消息类型判断推送消息的存储方式、推送消息的删除方式等；

MySQL数据库50222，用于存储根据消息类型判断的，具有长久存储价值的推送消息；

Redis数据库50223，用于存储根据消息类型判断的，具有不长久存储价值的推送消息；

Redis管理模块50224，用于控制Redis数据库中存储的推送消息的数量。

第三方推送平台503，用于通过第三方推送服务推送推送消息。

信息接收方504，用于接收推送消息，包括：

新信息提醒模块5041，用于进行新信息的提醒，和根据消息标识对接收到的推送消息进行去重操作。

实施例五

图6示出了本申请实施例所提供的一种电子设备600，包括处理器601，存储器602，总线603，所述处理器601和存储器602通过总线603连接；处理器601用于执行存储器602中存储的可执行模块，例如计算机程序。

其中，存储器602可能包含高速随机存取存储器(Random Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

总线603可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component Interconnect，PCI)总线或扩充工业标准总结结构(Extended Industry Standard Architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器602用于存储程序，所述处理器601在接收到执行指令后，执行所述程序，前述本申请实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器601中，或者由处理器601实现。

处理器601可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器601中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器601可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器602，处理器601读取存储器602中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的一种推送消息发送装置及电子设备，与上述实施例提供的一种推送消息发送方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。

实施例六

本实施例公开了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述实施例的推送消息发送方法中的步骤。

本申请实施例所提供的进行推送消息发送方法的计算机程序产品，包括存储了处理器可执行的非易失的程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims

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

获取消息请求；所述消息请求中携带有用户身份标识；

2.根据权利要求1所述的方法，其特征在于，所述未推送的推送消息包括：个人消息和/或公告消息。

3.根据权利要求2所述的方法，其特征在于，针对所述未推送的推送消息包括个人消息的情况，采用下述方式检测是否存在与所述用户身份标识对应的未推送的推送消息：

检测所述未推送集合中是否存在所述未推送的推送消息；

4.根据权利要求3所述的方法，其特征在于，将所述未推送的推送消息发送给消息请求方，包括：

5.根据权利要求4所述的方法，其特征在于，所述将所述未推送集合中存在的所述未推送的推送消息发送给消息请求方之后，还包括：

将所述未推送的推送消息从所述未推送集合中删除；

或者，

所述消息请求中还携带有已接收指令；

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

生成个人消息；所述个人消息对应有用户身份标识；

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

并在超过所述第一预设时间段后，清空所述未推送集合。

8.根据权利要求6所述的方法，其特征在于，根据所述用户身份标识，将所述生成的个人消息存储到与所述用户身份标识对应的未推送集合中，包括：

9.根据权利要求6所述的方法，其特征在于，根据所述用户身份标识，将所述生成的个人消息存储到与所述用户身份标识对应的未推送集合中，包括：

10.根据权利要求6所述的方法，其特征在于，在生成个人消息之后，还包括：将生成的个人消息推送给消息请求方；

并将生成的个人消息存储在未读消息集合中；

将所述生成的个人消息从所述未推送集合中删除。

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

并在超过所述第三预设时间段后，清空所述未读消息集合。

12.根据权利要求2所述的方法，其特征在于，针对所述未推送的推送消息包括公告消息的情况，采用下述方式检测是否存在与所述用户区域标识对应的未推送的推送消息：

或者，所述消息请求中携带有用户区域标识；

13.根据权利要求12所述的方法，其特征在于，还包括：根据所述用户身份标识，确定与所述用户身份标识对应的已接收消息标识；

或者，所述消息请求中还携带有已接收消息标识；

14.根据权利要求13所述的方法，其特征在于，所述目标公告消息集合中所存储的每条推送消息均对应有消息标识；

15.根据权利要求13所述的方法，其特征在于，根据所述用户身份标识，确定与所述用户身份标识对应的已接收消息标识，包括：

16.根据权利要求13所述的方法，其特征在于，将所述未推送的推送消息发送给消息请求方之后，还包括：使用目标公告消息集合中推送消息所具有的最大的消息标识更新所述已接收消息标识。

17.根据权利要求12所述的方法，其特征在于，还包括：生成公告消息；所述公告消息对应有至少一个用户区域标识；

18.一种推送消息发送装置，其特征在于，包括：

19.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至17任一所述的推送消息发送方法的步骤。

20.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至17任一所述的推送消息发送方法的步骤。