CN111901366B - 一种数据推送方法、装置、设备和存储介质 - Google Patents

Abstract

本发明公开了一种数据推送方法、装置、设备和存储介质。其中，该方法包括：获取待推送的业务数据；根据推送用户的在线存活状态确定匹配的推送机制，所述推送机制包括在线推送和第三方离线推送，所述在线推送的推送机制对应于在线存活的推送用户，所述第三方离线推送的推送机制对应于非在线存活的推送用户；根据所述推送机制向推送用户推送所述业务数据。本发明实施例提供的技术方案，将推送机制与推送用户的在线存活状态相关联，后续通过该推送机制向推送用户推送业务数据，提高数据推送的实时性，同时通过设定两种推送机制，扩展了推送服务的高可用性。

Description

一种数据推送方法、装置、设备和存储介质

技术领域

本发明实施例涉及互联网消息交互技术领域，尤其涉及一种数据推送方法、装置、设备和存储介质。

背景技术

在现代互联网系统中，为了满足移动应用中各项目高速发展的业务需求，服务端与移动应用之间的消息推送也越来越普遍，此时应用消息推送要求满足实时性、可控的触达率以及服务的高可用性等。

目前主流的移动应用推送技术主要有轮询方式、短信推送方式以及长连接方式。其中，轮询方式是通过移动应用与服务端定期建立连接，进而定时查询服务端是否有最新消息需要拉取；短信推送方式是服务端通过短信来向移动应用发送需要推送的消息，并由移动应用中植入的短信拦截功能模块来拦截并展现该短信中携带的消息；长连接方式是移动应用与服务端建立传输控制协议(Transmission Control Protocol，TCP)长连接，使移动应用定时向服务端发送心跳数据包来保持两者之间的连接，在有消息触达时，服务端可以直接通过已建立的TCP长连接将该消息发送给移动应用。

现有的移动应用消息推送技术分别存在不同的缺陷：轮询方式不能满足移动应用的消息实时性要求，而且需要根据消息场景定制不同的连接时机、频率等，影响消息的下发和用户体验；短信推送方式存在较高的运营成本，消息需要花费相应的短讯服务(ShortMessaging Service，SMS)费用，不能满足大量消息的推送；长连接方式在无新消息推送时，仍然会保持连接，造成一定的服务端和宽度费用的开销。

发明内容

本发明实施例提供了一种数据推送方法、装置、设备和存储介质，在保证数据推送实时性的基础上，扩展推送服务的高可用性。

第一方面，本发明实施例提供了一种数据推送方法，该方法包括：

获取待推送的业务数据；

根据推送用户的在线存活状态确定匹配的推送机制，所述推送机制包括在线推送和第三方离线推送，所述在线推送的推送机制对应于在线存活的推送用户，所述第三方离线推送的推送机制对应于非在线存活的推送用户；

根据所述推送机制向推送用户推送所述业务数据。

第二方面，本发明实施例提供了一种数据推送装置，该装置包括：

数据获取模块，用于获取待推送的业务数据；

推送机制确定模块，用于根据推送用户的在线存活状态确定匹配的推送机制，所述推送机制包括在线推送和第三方离线推送，所述在线推送的推送机制对应于在线存活的推送用户，所述第三方离线推送的推送机制对应于非在线存活的推送用户；

数据推送模块，用于根据所述推送机制向推送用户推送所述业务数据。

第三方面，本发明实施例提供了一种设备，该设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明任意实施例中所述的数据推送方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本发明任意实施例中所述的数据推送方法。

本发明实施例提供了一种数据推送方法、装置、设备和存储介质，根据推送用户的在线存活状态在在线推送和第三方离线推送两种推送机制中选取出与本次推送用户匹配的推送机制，从而将推送机制与推送用户的在线存活状态相关联，后续通过该推送机制向推送用户推送业务数据，提高数据推送的实时性，同时通过设定两种推送机制，扩展了推送服务的高可用性。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1A为本发明实施例一提供的一种数据推送方法的流程图；

图1B为本发明实施例一提供的数据推送的原理示意图；

图2A为本发明实施例二提供的一种数据推送方法的流程图；

图2B为本发明实施例二提供的一种数据推送过程的原理示意图；

图3A为本发明实施例三提供的一种数据推送方法的流程图；

图3B为本发明实施例三提供的一种数据推送过程的原理示意图；

图4A为本发明实施例四提供的一种数据推送方法的流程图；

图4B为本发明实施例四提供的一种数据推送方法所应用的业务数据推送平台的原理架构图；

图5为本发明实施例五提供的一种数据推送装置的结构示意图；

图6为本发明实施例六提供的一种设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。此外，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

实施例一

图1A为本发明实施例一提供的一种数据推送方法的流程图，本实施例可应用于任一种移动应用的服务端中。本发明实施例的方案可以适用于如何解决数据推送存在的实时性低或花费成本较高的问题。本实施例提供的一种数据推送方法可以由本发明实施例提供的数据推送装置来执行，该装置可以通过软件和/或硬件的方式来实现，并集成在执行本方法的设备中，该设备可以是任一移动应用对应的服务器。

具体的，参考图1A，该方法可以包括如下步骤：

S110，获取待推送的业务数据。

其中，业务数据是指当移动应用在处于某种特定业务场景下时，根据用户执行的相应操作生成的需要推送给其他用户的消息数据，本实施例中的移动应用是指与服务端之间存在数据推送需求的任意应用程序，如视频类或聊天类应用程序等，本实施例中对此不作限定；业务场景是指允许移动应用执行的任一种待处理事务所处的场景，例如在某一视频类移动应用中，业务场景可以包括对用户发布视频进行推送的场景，以及官方公众号推送视频的场景等。

具体的，当用户在移动应用处于某一特定业务场景下通过执行相应的操作而实现某一事务处理功能时会生成匹配的业务数据，此时本实施例会获取到该业务数据进行推送。

以官方公众号推送视频的场景为例，若运营人员通过配置视频链接以及对应的描述文案在选择某一官方公众号中进行发布时，服务端会获取到该官方公众号中的视频链接以及对应的描述文案，此时该视频链接以及对应的描述文案为待推送的业务数据，如服务端后续可以将该视频链接以及对应的描述文案推送给该视频类移动应用中的其他用户。

S120，根据推送用户的在线存活状态确定匹配的推送机制。

其中，推送用户可以是在移动应用中注册过的任意用户，也可以是与业务数据的执行方存在关联关系的其他用户，如若某一用户在移动应用中发布一条短视频，此时推送用户可以是该移动应用中对该发布用户进行关注的其他用户；在线存活状态是指推送用户所在的移动应用与服务端之间的通信连接状态，此时在线存活是指推送用户所在的移动应用与服务端之间当前存在通信连接，非在线存活是指推送用户所在的移动应用与服务端之间当前不存在通信连接，也就是当前通信链路断开，无法通信。

进一步的，推送机制是指服务端向用户推送数据时所能够选用的推送方式，包括在线推送和第三方离线推送两种；此时需要说明的是，在线推送的推送机制对应于在线存活的推送用户，第三方离线推送的推送机制对应于非在线存活的推送用户。

具体的，在获取到待推送的业务数据时，首先需要确定本次推送的推送用户，此时推送用户可以是在移动应用中注册过的所有用户或者部分用户，并通过判断服务端与各推送用户所在的移动应用之间当前是否存在通信连接，也就是识别各推送用户所在的移动应用是否在线，进而确定各推送用户的在线存活状态，同时根据各推送用户的在线存活状态在在线推送和第三方离线推送两种推送机制中选取出匹配的推送机制，此时本实施例为在线存活的推送用户选择在线推送的推送机制，为非在线存活的推送用户选择第三方离线推送的推送机制，以便后续采用匹配的推送机制来向各个推送用户推送业务数据。由于现有技术中通常仅存在一种推送机制，而本实施例中通过扩展数据推送的推送机制为在线推送和第三方离线推送两种，提高了数据推送的高可用性；将推送机制与推送用户的在线存活状态相关联，不同在线存活状态下的推送用户适用不同的推送机制，提高数据推送的实时性。

需要说明的是，本实施例在确定推送用户之前，可以根据业务数据所处的不同业务场景来设定各个业务场景下的推送用户类型，如处于对用户发布视频进行推送的场景时，设定推送用户可以为移动应用中关注过该发布视频的用户的其他用户；处于官方公众号推送视频的场景时，设定推送用户可以为移动应用中注册的全部用户；可选的，通过判断获取的业务数据当前所处的业务场景，进而确定本次需要推送的推送用户。

S130，根据该推送机制向推送用户推送业务数据。

具体的，在确定与推送用户的在线存活状态匹配的推送机制后，针对每一推送用户，均采用匹配的推送机制向该推送用户推送本次推送获取的业务数据；以对用户发布视频进行推送的场景为例，用户在移动应用中发布一条短视频，此时推送用户可以是该移动应用中关注过发布用户的其他用户，通过每一推送用户的在线存活状态在两种推送机制中为各推送用户选取出匹配的推送机制；对于在线存活的推送用户，通过在线推送的方式推送业务数据，对于非在线存活的推送用户，通过第三方离线推送的方式推送业务数据。

可选的，本实施例中推送业务数据的原理示意图如图1B所示，此时根据推送机制向推送用户推送业务数据，具体可以包括：若推送机制为在线推送，则通过在线连接通道直接向推送用户推送业务数据；若推送机制为第三方离线推送，则通过第三方服务端向推送用户推送业务数据。

具体的，对于每一推送用户，若匹配的推送机制为在线推送，说明该推送用户当前为在线存活，也就是该推送用户所在的移动应用与服务端之间存在通信连接，此时可以直接通过该推送用户所在的移动应用与服务端之间的在线连接通道向该推送用户推送业务数据；示例性的，移动应用可以通过其上的linkd业务进程实现与服务端之间的业务通信处理功能，进而保证移动应用在线，因此本实施例中若推送机制为在线推送，则可以直接通过该linkd业务进程向该推送用户推送业务数据，保证数据推送的实时性。

进一步的，若匹配的推送机制为第三方离线推送，说明该推送用户当前为非在线存活，也就是该推送用户所在的移动应用与服务端之间当前不存在通信连接，则可以将本次待推送的业务数据发送给预先设定的第三方服务端，该第三方服务端通过应用程序软件开发工具包(Software Development Kit,SDK)或者系统SDK与推送用户所在的移动应用之间保持有相应的长连接，该长连接可以为基于传输控制协议(Transmission ControlProtocol，TCP)的长连接，因此由第三方服务端将该业务数据转发给推送用户。对于每一个推送用户执行相同的推送处理过程，进而采用每一推送用户匹配的推送机制分别向各推送用户推送业务数据，实现数据推送的实时性和可控性。

本实施例提供的技术方案，根据推送用户的在线存活状态在在线推送和第三方离线推送两种推送机制中选取出与本次推送用户匹配的推送机制，从而将推送机制与推送用户的在线存活状态相关联，后续通过该推送机制向推送用户推送业务数据，提高数据推送的实时性，同时通过设定两种推送机制，扩展了推送服务的高可用性。

实施例二

图2A为本发明实施例二提供的一种数据推送方法的流程图，图2B为本发明实施例二提供的一种数据推送过程的原理示意图。本实施例中是在上述实施例提供的技术方案的基础上进行优化。具体的，本实施例中主要对获取业务数据以及确定推送机制的具体执行过程进行详细的解释说明。

可选的，如图2A所示，本实施例中可以包括如下步骤：

S210，获取用户业务请求。

其中，用户业务请求是指用户在移动应用上通过执行相应操作而指示实现相应业务处理功能的指令，该用户业务请求包括原始业务消息；原始业务消息是业务处理过程中生成的未被处理的原始数据。

具体的，用户在某一业务场景下进行相应业务处理时，可以采用异步消息队列的方式获取对应的用户业务请求，并对该用户业务请求进行解析得到包含的原始业务消息，该原始业务消息可以通过异步消息队列存储；此时若在同一时刻下获取到大量用户业务请求时，该异步消息队列存储大量原始业务消息时具备了消息缓存的功能，即使在业务数据的发送速率较高的情况下，也能够保证数据接收的正常运行，降低大量原始业务消息同时发送至服务端的数据冲击性，保护服务端上数据推送功能的正常运行。

示例性的，本实施例中可以设定一个消息服务进程(push_server)，提供移动应用中各种不同类型下的业务数据的统一接入入口，本实施例中可以通过该push_server进程获取用户业务请求，并将该用户业务请求中的原始业务消息存储至异步消息队列中。

S220，对原始业务消息的合法性进行校验，得到待推送的业务数据。

具体的，在获取到原始业务消息后，由于数据传输过程中会存在时延或者重复发送等各种问题，因此需要对获取到原始业务消息的合法性进行校验，也就是对原始业务消息进行真实、时效或者去重等检查，将不满足要求的消息过滤，如伪消息、时效过期或者重复发送的消息等，进而得到过滤后的原始业务消息，作为本实施例中待推送的业务数据。

可选的，本实施例中会预先设定一个消息处理进程(push_handler)，该push_handler进程可以针对业务数据的类型进行去重、延迟处理或真实校验等过滤或拦截服务，本实施例中具体通过该push_handler进程对原始业务消息的合法性进行校验，得到待推送的业务数据。

S230，确定业务数据对应的待推送用户的关联用户，作为推送用户。

可选的，在获取到待推送的业务数据后，需要确定本次推送服务对应的推送用户，此时根据待推送的业务数据确定生成该业务数据的待推送用户，并在注册过该移动应用的全部用户中选取出与该待推送用户之间存在关联关系的用户，作为本次推送服务的推送用户。

示例性的，若业务数据为待推送用户在移动应用上发布的一条短视频，则关联用户为该移动应用上关注该待推送用户的其他用户。

S240，通过移动应用传输网关确定推送用户的在线存活状态。

其中，移动应用传输网关可以通过相应的应用协议将移动应用与另一网络设备进行通信连接，因此通过该移动应用传输网关可以识别移动应用当前是否在线，也就是可以判断移动应用与服务端之间当前是否存在通信连接，如本实施例中的app_gw。本实施例通过检测各个推送用户所在的移动应用对应的移动应用传输网关所处的状态，判断各移动应用当前是否与服务端之间存在通信连接，从而确定各个推送用户的在线存活状态，以便后续根据各推送用户的在线存活状态确定匹配的推送机制。

S250，根据推送用户的在线存活状态确定匹配的推送机制。

S260，根据该推送机制向推送用户推送业务数据。

本实施例提供的技术方案，通过异步消息队列来存储原始业务消息，使得服务端具备消息缓存的功能，在业务数据的发送速率较高的情况下，能够降低大量原始业务消息同时发送至服务端的数据冲击性，保护服务端上数据推送功能的正常运行；同时通过对原始业务消息的合法性进行校验，提高推送数据的有效性，降低消息的误推送率。

实施例三

图3A为本发明实施例三提供的一种数据推送方法的流程图，图3B为本发明实施例三提供的一种数据推送过程的原理示意图。本实施例中是在上述实施例提供的技术方案的基础上进行优化。具体的，本实施例中主要对在向推送用户推送业务数据之后的业务数据推送状况分析的具体过程进行详细的解释说明。

可选的，如图3A所示，本实施例中可以包括如下步骤：

S310，获取待推送的业务数据。

S320，根据推送用户的在线存活状态确定匹配的推送机制。

S330，根据该推送机制向推送用户推送业务数据。

S340，通过消息持久化机制存储业务数据。

其中，消息持久化机制用于保证在推送业务数据之后，为了方便查看历史业务推送情况，而对已推送的历史业务数据进行追溯、统计或分析等处理。可选的，在向推送用户推送业务数据后，可以根据设定的消息持久化机制将业务数据以及具体的推送情况进行存储，以便后续查看。

S350，通过消息应答机制接收推送用户的反馈信息。

具体的，为了判断业务数据是否推送成功，本实施例中可以引入消息应答(Acknowledgement，ACK)机制，此时该ACK机制能够在向推送用户推送业务数据后，控制推送用户所在的移动应用向服务端反馈确认业务数据是否推送成功的应答消息，也就是本实施例中的反馈信息；可选的，如果通过在线推送的推送机制向推送用户推送业务数据，则推送用户所在的移动应用直接通过在线连接通道反馈对应的应答消息；如果通过第三方离线推送的推送机制向推送用户推送业务数据，则推送用户所在的移动应用通过业务数据推送时采用的第三方服务端反馈对应的应答消息，从而接收各推送用户的反馈信息，进而判断本次推送是否成功。

S360，若根据反馈信息确定本次推送失败，则根据该推送机制重新向推送用户推送业务数据。

可选的，在接收到推送用户的反馈信息后，根据该反馈信息判断本次推送是否成功，同时本实施例中引入消息重传机制，在本次推送失败时，可以重新采用匹配的推送机制再次向推送用户推送该业务数据，提高业务数据的到达率，保证数据推送的成功率。

本实施例提供的技术方案，通过引入消息持久化机制和消息应答机制，在向推送用户推送业务数据后，能够对推送的业务数据进行存储，以便后续实现数据追溯和统计分析等功能，同时在推送失败时，可以根据匹配的推送机制向推送用户重新推送，提高业务数据的到达率，保证数据推送的成功率。

实施例四

图4A为本发明实施例四提供的一种数据推送方法的流程图，图4B为本发明实施例四提供的一种数据推送方法所应用的业务数据推送平台的原理架构图。本实施例是在上述实施例提供的技术方案的基础上进行优化。具体的，本实施例中数据推送方法的执行主体为业务数据推送平台，如图4B所示，该业务数据推送平台采用低耦合的分层设计，包括接入层、处理层和应用层三层。本实施例主要对该业务数据推送平台中每一层所执行的功能进行具体说明。

可选的，如图4A所示，本实施例中具体可以包括如下步骤：

S410，通过业务数据推送平台的接入层获取待推送的业务数据。

具体的，本实施例中针对不同的业务场景包括多个业务系统，此时业务数据推送平台的接入层可以对应设置多个接入入口，业务系统在发送携带原始业务消息的用户业务请求时，本实施例可以通过接入层中设定的push_server进程来接收用户业务请求，并对该用户业务请求进行解析，得到对应的原始业务消息，进而将原始业务消息存储至异步消息队列中。

S420，通过业务数据推送平台的处理层根据推送用户的在线存活状态确定匹配的推送机制。

可选的，通过业务数据推送平台的接入层将原始业务消息存储至异步消息队列后，可以通过业务数据推送平台的处理层对原始业务消息的合法性进行校验，得到待推送的业务数据，并根据推送用户的在线存活状态确定匹配的推送机制。其中，该业务数据推送平台的处理层中包括push_handler进程和移动应用传输网关app_gw，具体通过push_handler进程对原始业务消息进行校验和过滤等处理，得到待推送的业务数据，并将该业务数据下沉到移动应用传输网关app_gw中，通过移动应用传输网关app_gw判断各个推送用户当前是否与服务端存在通信连接，进而确定各推送用户的在线存活状态，并确定各个推送用户匹配的推送机制。

S430，根据该推送机制，通过业务数据推送平台的应用层向推送用户推送业务数据。

具体的，本实施例中业务数据推送平台的应用层设置在推送用户所在的移动应用上，该应用层主要提供统一的软件开发工具包(Software Development Kit，SDK)，以供业务数据推送平台使用，可以将适配自身的SDK接口以及第三方服务端的SDK接口封装到该统一的SDK中，使得业务数据推送平台只需关注统一封装的SDK即可实现业务数据的各项处理操作，而无需考虑各种过滤、重复校验等通用操作。

本实施例根据该推送机制，通过业务数据推送平台的应用层向推送用户推送业务数据，此时该应用层在接收到推送的业务数据时，可以根据业务数据的类型确定对应的展示样式，同时根据消息应答机制发送对应的反馈信息以及各项上报数据。可选的，业务数据推送平台的应用层的主要可以屏蔽推送接口，实现业务与推送服务解耦，通过统一的SDK接口，简化移动应用的接入；同时通过统一的SDK接口实现多点接入，能够同时接入多套不同业务下的数据推送服务；该SDK接口还可以实现移动应用的数据上报功能，以及对于推送的业务数据的监控和统计功能，并提供相关数据的统计分析和报警预警功能。

本实施例提供的技术方案，采用分层设计的方式搭建业务数据推送平台，实现业务服务和推送服务的解耦，实现数据推送的实时性，并保证可控的触达率，同时通过设定两种推送机制，扩展了推送服务的高可用性。

实施例五

图5为本发明实施例五提供的一种数据推送装置的结构示意图，具体的，如图5所示，该装置可以包括：

数据获取模块510，用于获取待推送的业务数据；

推送机制确定模块520，用于根据推送用户的在线存活状态确定匹配的推送机制，该推送机制包括在线推送和第三方离线推送，在线推送的推送机制对应于在线存活的推送用户，第三方离线推送的推送机制对应于非在线存活的推送用户；

数据推送模块530，用于根据该推送机制向推送用户推送业务数据。

本实施例提供的技术方案，根据推送用户的在线存活状态在在线推送和第三方离线推送两种推送机制中选取出与本次推送用户匹配的推送机制，从而将推送机制与推送用户的在线存活状态相关联，后续通过该推送机制向推送用户推送业务数据，提高数据推送的实时性，同时通过设定两种推送机制，扩展了推送服务的高可用性。

进一步的，上述数据推送模块530，可以包括：

在线推送单元，用于若推送机制为在线推送，则通过在线连接通道直接向推送用户推送业务数据；

第三方推送单元，用于若推送机制为第三方离线推送，则通过第三方服务端向推送用户推送业务数据。

进一步的，上述数据推送装置，还可以包括：

推送用户确定模块，用于在根据推送用户的在线存活状态确定匹配的推送机制之前，确定业务数据对应的待推送用户的关联用户，作为推送用户；

存活状态确定模块，用于通过移动应用传输网关确定推送用户的在线存活状态。

进一步的，上述数据获取模块510，可以包括：

请求获取单元，用于获取用户业务请求，该用户业务请求包括原始业务消息；

消息校验单元，用于对原始业务消息的合法性进行校验，得到待推送的业务数据。

进一步的，上述原始业务消息可以通过异步消息队列存储。

进一步的，上述数据推送装置，还可以包括：

数据存储模块，用于在根据该推送机制向推送用户推送业务数据之后，通过消息持久化机制存储业务数据。

进一步的，上述数据推送装置，还可以包括：

反馈信息接收模块，用于通过消息应答机制接收推送用户的反馈信息；

上述数据推送模块530，还用于若根据反馈信息确定本次推送失败，则根据推送机制重新向推送用户推送业务数据。

进一步的，上述数据推送装置可以为业务数据推送平台；

上述数据获取模块510，可以具体用于通过业务数据推送平台的接入层获取待推送的业务数据；

上述推送机制确定模块520，可以具体用于通过业务数据推送平台的处理层根据推送用户的在线存活状态确定匹配的推送机制；

上述数据推送模块530，可以具体用于根据该推送机制，通过业务数据推送平台的应用层向推送用户推送业务数据。

本实施例提供的数据推送装置可适用于本发明任意实施例提供的数据推送方法，具备相应的功能和有益效果。

实施例六

图6为本发明实施例六提供的一种设备的结构示意图，如图6所示，该设备包括处理器60、存储装置61和通信装置62；设备中处理器60的数量可以是一个或多个，图6中以一个处理器60为例；设备中的处理器60、存储装置61和通信装置62可以通过总线或其他方式连接，图6中以通过总线连接为例。

存储装置61作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中提供的数据推送方法对应的程序指令/模块。处理器60通过运行存储在存储装置61中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述数据推送方法。

存储装置61可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储装置61可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储装置61可进一步包括相对于处理器60远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

通信装置62可用于实现设备间的网络连接或者移动数据连接。

本实施例提供的一种设备可用于执行本发明任意实施例提供的数据推送方法，具备相应的功能和有益效果。

实施例七

本发明实施例七还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可实现本发明任意实施例中的数据推送方法。该方法具体可以包括：

获取待推送的业务数据；

根据推送用户的在线存活状态确定匹配的推送机制，该推送机制包括在线推送和第三方离线推送，在线推送的推送机制对应于在线存活的推送用户，第三方离线推送的推送机制对应于非在线存活的推送用户；

根据该推送机制向推送用户推送业务数据。

当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的数据推送方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述数据推送装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域技术人员而言，本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种数据推送方法，其特征在于，包括：

获取待推送的业务数据；

根据推送用户的在线存活状态确定匹配的推送机制，所述推送机制包括在线推送和第三方离线推送，所述在线推送的推送机制对应于在线存活的推送用户，所述第三方离线推送的推送机制对应于非在线存活的推送用户；

根据所述推送机制向推送用户推送所述业务数据；

在根据推送用户的在线存活状态确定匹配的推送机制之前，还包括：

确定所述业务数据对应的待推送用户的关联用户，作为所述推送用户：包括，在注册过移动应用的全部用户中选取出与所述待推送用户之间存在关联关系的用户，作为所述推送用户；

通过移动应用传输网关确定所述推送用户的在线存活状态；

所述获取待推送的业务数据，包括：

预先设定一个消息服务进程，获取用户业务请求，所述用户业务请求包括原始业务消息；

所述原始业务消息通过异步消息队列存储；

对所述原始业务消息的合法性进行校验，得到待推送的业务数据。

2.根据权利要求1所述的方法，其特征在于，根据所述推送机制向推送用户推送所述业务数据，包括：

若所述推送机制为在线推送，则通过在线连接通道直接向所述推送用户推送所述业务数据；

若所述推送机制为第三方离线推送，则通过第三方服务端向所述推送用户推送所述业务数据。

3.根据权利要求1-2任一项所述的方法，其特征在于，在根据所述推送机制向推送用户推送所述业务数据之后，还包括：

通过消息持久化机制存储所述业务数据。

4.根据权利要求1-2任一项所述的方法，其特征在于，在根据所述推送机制向推送用户推送所述业务数据之后，还包括：

通过消息应答机制接收所述推送用户的反馈信息；

若根据所述反馈信息确定本次推送失败，则根据所述推送机制重新向所述推送用户推送所述业务数据。

5.根据权利要求1所述的方法，其特征在于，所述方法的执行主体为业务数据推送平台，则具体包括：

通过业务数据推送平台的接入层获取待推送的业务数据；

通过业务数据推送平台的处理层根据推送用户的在线存活状态确定匹配的推送机制；

根据所述推送机制，通过业务数据推送平台的应用层向推送用户推送所述业务数据。

6.一种数据推送装置，其特征在于，包括：

数据获取模块，用于获取待推送的业务数据；

推送机制确定模块，用于根据推送用户的在线存活状态确定匹配的推送机制，所述推送机制包括在线推送和第三方离线推送，所述在线推送的推送机制对应于在线存活的推送用户，所述第三方离线推送的推送机制对应于非在线存活的推送用户；

数据推送模块，用于根据所述推送机制向推送用户推送所述业务数据；

所述数据推送装置，还包括：

推送用户确定模块，用于在根据推送用户的在线存活状态确定匹配的推送机制之前，确定业务数据对应的待推送用户的关联用户，作为推送用户：包括，在注册过移动应用的全部用户中选取出与所述待推送用户之间存在关联关系的用户，作为所述推送用户；

存活状态确定模块，用于通过移动应用传输网关确定推送用户的在线存活状态；

所述数据获取模块，包括：

请求获取单元，用于预先设定一个消息服务进程，获取用户业务请求，所述用户业务请求包括原始业务消息；

所述原始业务消息通过异步消息队列存储；

消息校验单元，用于对所述原始业务消息的合法性进行校验，得到待推送的业务数据。

7.一种电子设备，其特征在于，所述设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-5中任一所述的数据推送方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-5中任一所述的数据推送方法。