消息推送方法和系统与流程

本发明涉及计算机领域，更具体地，涉及一种消息推送方法和系统。

背景技术：

互联网时代的发展，消息推送越来越重要，一些设计到金融、安全的领域对于消息推送的可靠性，就变得非常重要，传统的消息推送容易丢失消息，遇到网络中断或者一些特殊情况消息很容易丢失，推送方保证不了自己推送出去的消息是否能够到达到对方，这将会带来极大的损失。

多客户端之间的消息推送也是一个问题，一些常见的推送服务器可能只支持pc端，支持不了web或者移动端的推送，用户体验极不好。

目前对于消息在网络中断或者一些特殊的情况下造成的丢失消息还没有比较好的解决方案，比如极推、百度云推送等在一些情况下也会丢失消息，所以推送消息丢失是个需要重视的问题。

技术实现要素：

本发明要解决的技术问题在于提高消息推送的可靠性。

根据本发明实施例的一方面，提供了一种消息的推送方法，包括：

发送方发送一组消息体至接收方，并记录所发送的该组消息体中最后发送的一条消息体的标识，一组消息体包括至少一条消息体；

发送方向接收方请求回执消息，回执消息包括接收方在接收该组消息体时最后接收到的一条消息体的标识；以及

发送方接收到接收方返回的回执消息并将返回的回执消息中的标识与所记录的标识进行比较。

可选地，发送方基于预先注册的推送账号而发送一组消息体至接收方。

优选地，根据本发明的推送方法还包括：

发送方向接收方每发送一条消息体之后，在本地保存该条消息体；

如果比较结果不同，则发送方重新向接收方发送所保存的消息体，或者向接收方提示消息发送错误。

另外，根据本发明的推送方法还包括：

发送方在重新发送所保存的消息体之后，再次向接收方请求回执消息；

发送方接收到接收方再次返回的回执消息并将再次返回的回执消息中的标识与所记录的标识进行比较；

在比较结果不同时，判断发送方发送该组消息体的次数是否达到预定次数，如果为否，则继续向接收方重新发送该组消息体；如果为是，则发送方判断为消息推送失败。

此外，根据本发明的推送方法还包括：

发送方在发送消息体至接收方之前，判断二者之间是否存在连接，若否，则发送方将该组消息体作为离线消息进行存储；

当二者之间存在连接，则发送方发送离线消息至接收方，并记录所发送的离线消息中最后发送的一条消息体的标识。

另外，根据本发明的推送方法还包括：

发送方以加密方式发送该组消息体/每一条消息体至接收方。

根据本发明实施例的再一方面，提供了一种用于消息推送的客户端，包括：

消息体发送单元，其配置为发送一组消息体至服务端，并记录所发送的该组消息体中最后发送的一条消息体的标识，一组消息体包括至少一条消息体；

回执消息请求单元，其配置为向服务端请求回执消息，回执消息包括服务端在接收该组消息体时最后接收到的一条消息体的标识；以及

比较单元，其配置为接收从服务端返回的回执消息并将回执消息中的标识与所记录的标识进行比较。

可选地，消息体发送单元配置为基于预先注册的推送账号而发送一组消息体至服务端。

可选地，根据本发明的客户端还包括：

存储单元，其配置为在消息体发送单元向服务端每发送一条消息体之后，在本地保存该条消息体，

其中，消息体发送单元还被配置为在比较单元得出的比较结果为不同时，重新向服务端发送所保存的消息体，或者向服务端提示消息发送错误。

根据本发明实施例的再一方面，提供了一种用于消息推送的服务端，包括：

消息体接收单元，其配置为接收客户端发送的一组消息体，并记录所接收的该组消息体中最后接收到的一条消息体的标识，一组消息体包括至少一条消息体；

回执消息发送单元，其配置为接收到客户端的回执消息请求后，向客户端发送回执消息，回执消息包括消息体接收单元在接收该组消息体时最后接收到的一条消息体的标识。

根据本发明实施例的再一方面，提供了一种消息推送系统，包括上述根据本发明的客户端和上述根据本发明的服务端。

根据本发明实施例的再一方面，提供了一种消息推送系统，包括接收端和根据本发明的服务端，服务端将从客户端接收的一组消息体发送至接收端，其中，服务端还包括：

消息体发送单元，其配置为发送一组消息体至接收端，并记录所发送的该组消息体中最后发送的一条消息体的标识，一组消息体包括至少一条消息体；

回执消息请求单元，其配置为向接收端请求回执消息，回执消息包括接收端在接收该组消息体时最后接收到的一条消息体的标识；以及

比较单元，其配置为接收从接收端返回的回执消息并将回执消息中的标识与所记录的标识进行比较。

可选地，服务端还包括：

解析单元，其配置为对从客户端接收到的消息体以与客户端的序列化方式对应的方式进行解析以确定接收端。

可选地，服务端还包括：

判断单元，其配置为在解析单元解析后的格式满足预定发送条件的情况下，判断该接收端与服务端是否连接；

存储单元，其配置为在判断单元的判断结果为否的情况下，将该组消息存储为离线消息。

根据本发明实施例的再一方面，提供了一种消息推送系统，包括接收端、根据本发明的客户端和根据本发明的服务端，服务端将从客户端接收的一组消息体发送至接收端。

通过本发明实施例，可以避免消息推送过程中由于网络中断或者一些特殊情况造成的消息丢失。此外，只要发送方和接收方按照约定协议进行通信，实现的消息推送是可靠的，其中，客户端和服务端可以作为一组发送方和接收方，而服务端和接收端也可以作为一组发送方和接收方。而且，根据本发明的实施例，客户端可以是任意客户端，例如Web客户端、移动端客户端、PC客户端。在本发明实施例中，推送发送方(客户端)只需要实现推送协议，并注册推送账号或者获取临时推送账号，就可以完成推送率较高的消息推送。

附图说明

图1是根据本发明实施例的一种消息推送方法的流程图；

图2是根据本发明实施例的用于消息推送的客户端的示例性框图；

图3是根据本发明实施例的用于消息推送的服务端的示例性框图；

图4示出了利用根据本发明第一消息推送系统进行消息推送的实施例的流程图；

图5示出了利用根据本发明第二消息推送系统进行消息推送的实施例的流程图；

图6示出了利用根据本发明第三消息推送系统的示例性框图。

具体实施方式

下面结合附图对本发明实施例作进一步的详细说明。本发明所涉及到的发送/接收消息均是以双方所约定的协议格式进行传输，不再赘述。

图1是根据本发明实施例的一种消息的推送方法的流程图。如图1所示，该推送方法可以包括：

步骤S101,发送方发送一组消息体至接收方，并记录所发送的该组消息体中最后发送的一条消息体的标识，一组消息体包括至少一条消息体。其中，发送方可以是客户端，而接收方可以是服务端。

在一可选实施例中，发送方基于预先注册的推送账号而发送一组消息体至接收方，发送方向接收方注册的推送账号可以是固定的推送账号，也可以是临时的推送账号。固定的推送账号以后可以一直使用，而临时的推送账号则会有一定的限制。客户端向服务端发送消息体，可以发送一条也可以发送多条消息体。此外，客户端可以在本地缓存所发送的每一条消息体，并记录所发送的一组消息体中最后发送的一条消息体的标识，所谓标识就是每一消息体的特有的识别符。

S102，发送方向接收方请求回执消息，回执消息包括接收方在接收该组消息体时最后接收到的一条消息体的标识。

在本实施例中，接收方接收到的消息是按照顺序处理的，在接收到一组消息体后会记录下最后接收的一条消息体的标识(在另一个实施方式中，接收方可以在接收到该发送方的每一条消息体之后记录该条消息体的标识)，然后在接收到发送方所发送的回执消息的请求(该请求比较简单，其大小很小)之后，根据对应该发送方的上述最后接收的一条消息体的标识生成回执消息，并返回给该发送方。

S103，发送方接收到接收方返回的回执消息并将返回的回执消息中的标识与所记录的标识进行比较。如果比较结果为相同，发送方判断为接收方接收消息成功。

在一可选实施例中，根据本发明的推送方法还可以包括：发送方向接收方每发送一条消息体之后，在本地保存该条消息体；如果比较结果不同，则发送方重新向接收方发送所保存的消息体，或者向接收方提示消息发送错误。

上述消息推送过程是推送消息从发送方到接收方的过程，其保证了消息推送的可靠性。

在一可选实施例中，根据本发明的推送方法还可以包括：发送方在重新发送所保存的消息体之后，再次向接收方请求回执消息；发送方接收到接收方再次返回的回执消息并将再次返回的回执消息中的标识与所记录的标识进行比较；在比较结果不同时，判断发送方发送该组消息体的次数是否达到预定次数，如果为否，则继续向接收方重新发送该组消息体；如果为是，则发送方判断为消息推送失败。

即，可以设定发送策略，发送方可以只发送一次便提醒发送错误，然后由用户进行另外的操作，也可以设定让发送方在第一次发送失败后，自动再次发送，直到失败次数达到预定的失败上限。后者可以提高操作效率。

在一可选实施例中，根据本发明的推送方法还可以包括：发送方在发送消息体至接收方之前，判断二者之间是否存在连接，若否，则发送方将该组消息体作为离线消息进行存储；当二者之间存在连接，则发送方发送离线消息至接收方，并记录所发送的离线消息中最后发送的一条消息体的标识。

以离线方式进行存储因二者之间不存在连接而不能发送的消息体可以使发送方的操作时间更为灵活，不限于两者共同连接的时间。

在一可选实施例中，根据本发明的推送方法还可以包括：发送方以加密方式发送该组消息体/每一条消息体至接收方，这样提高了消息推送的安全性。

图2是根据本发明实施例的用于消息推送的客户端的示例性框图。如图2所示，根据本发明的用于消息推送的客户端(其对应于图1中所示的发送方)，包括：

消息体发送单元21，其配置为发送一组消息体至服务端，并记录所发送的该组消息体中最后发送的一条消息体的标识，一组消息体包括至少一条消息体；

回执消息请求单元22，其配置为向服务端请求回执消息，回执消息包括服务端在接收该组消息体时最后接收到的一条消息体的标识；以及

比较单元23，其配置为接收从服务端返回的回执消息并将回执消息中的标识与所记录的标识进行比较。

在一可选实施例中，消息体发送单元21配置为基于预先注册的推送账号而发送一组消息体至服务端。推送账号可以是固定的推送账号，也可以是临时的推送账号。固定的推送账号以后可以一直使用，而临时的推送账号则会有一定的限制。

在一可选实施例中，根据本发明的客户端还包括：存储单元，其配置为在消息体发送单元向服务端每发送一条消息体之后，在本地保存该条消息体，其中，消息体发送单元还被配置为在比较单元得出的比较结果为不同时，重新向服务端发送所保存的消息体，或者向服务端提示消息发送错误。

图3是根据本发明实施例的用于消息推送的服务端的示例性框图。如图3所示，根据本发明的用于消息推送的服务端(其对应于图1中所示的接收方)包括：

消息体接收单元31，其配置为接收客户端发送的一组消息体，并记录所接收的该组消息体中最后接收到的一条消息体的标识，一组消息体包括至少一条消息体；

回执消息发送单元32，其配置为接收到客户端的回执消息请求后，向客户端发送回执消息，回执消息包括消息体接收单元在接收该组消息体时最后接收到的一条消息体的标识。

根据本发明的一个实施例，提供了第一消息推送系统，其包括如图2示的客户端和如图3示的服务端，两者之间的消息推送过程可以参考图4。在图4所示出的消息推送过程中，首先，搭建基于根据本发明的消息推送方法的协议的推送服务器，选择合理的传输框架，开启服务。然后配置客户端，客户端可以向服务端注册推送账号。通常情况下，注册时会生成一些加密需要的证书。

然后选择合适的推送客户端，前提是该推送客户端也实现了与推送服务器相同的协议，选择合适的通信协议和序列化方式，准备好之后，登录推送平台，成功登录之后会得到令牌(Token，一个凭证，相当于会话机制，从而保证在一段时间内的客户端和服务端之间保持可以通话的状态，而无需每次发送消息体的时候重新登录)。

客户端可以基于注册的推送账号发送包括一条或多条消息体的一组消息体到服务端。客户端进一步发送消息回执请求。服务端根据接收到的消息回执请求，将基于该推送账号从客户端接收的一组消息体中最后接收的一条消息的标识返回给客户端。

客户端判断其记录的最后一条消息的标识与服务端返回到的最后一条消息的标识是否相同。判断为不相同时，重新发送之前发送的一条或多条消息体，或者向服务端提示消息发送错误。

在服务端，服务端解析消息内容，查看对应的消息接收方是否登录，即服务端与消息接收方是否存在连接。如果存在连接，则直接将从客户端接收到的一条或多条消息发送给消息接收方。如果不存在连接，则将接收到的一条或多条消息暂时存为离线消息，等到消息接收方登录之后再推送。

根据本发明的另一个可选实施例，其提供了第二消息推送系统，该消息推送系统包括接收端和如图3所示的服务端，服务端将从客户端接收的一组消息体发送至接收端，其中，服务端还包括：

消息体发送单元，其配置为发送一组消息体至接收端，并记录所发送的该组消息体中最后发送的一条消息体的标识，一组消息体包括至少一条消息体；

回执消息请求单元，其配置为向接收端请求回执消息，回执消息包括接收端在接收该组消息体时最后接收到的一条消息体的标识；以及

比较单元，其配置为接收从接收端返回的回执消息并将回执消息中的标识与所记录的标识进行比较。

在一可选实施例中，服务端还包括：解析单元，其配置为对从客户端接收到的消息体以与客户端的序列化方式对应的方式进行解析以确定接收端。序列化方式比如可以是但不限于josn、xml、protobuf等。

在一可选实施例中，服务端还包括：判断单元，其配置为在解析单元解析后的格式满足预定发送条件的情况下，判断该接收端与服务端是否连接；存储单元，其配置为在判断单元的判断结果为否的情况下，将该组消息存储为离线消息。

图5示出了根据本发明实施例的第二消息推送系统的将消息从服务端推送到接收端的过程。如图5所示，该推送消息过程包括：

S501，服务端在正确接收到一组消息体后并在该组消息体解析后的格式满足预定发送条件的情况下，判断该接收端与服务端是否连接，若否则执行S502，将该组消息体作为离线消息暂时存储；

S503，当服务端检测到接收端连接到服务端后，将所存储的该组消息体发送给接收端并记录所发送的该组消息体中最后发送的一条消息体的标识；

S504，服务端向接收端请求回执消息；

S505，服务端接收从接收端返回的回执消息；

S506，服务端将回执消息中的标识与所记录的标识进行比较，如果比较结果为相同则执行S507，服务端判定为接收消息成功；如果比较结果为不同，则执行S508，服务端重新向接收端发送所保存的该组消息体。可选地，服务端可以向接收端提示消息发送失败。本发明实施例确保了推送消息的每个阶段都是可达的，保证了推送消息的可达和可靠性。

在本发明实施例中，消息推送的过程是可以选择消息加密的，比如对称加密、协商秘钥等加密方案，这样可以保证数据的安全性。

根据本发明的一个实施例，整合本发明实施例的第一消息推送系统和第二消息推送系统而提供了第三消息推送系统，包括接收端、如图2所示的客户端和如图3所示的服务端，服务端将从客户端接收的一组消息体发送至接收端。客户端在发送消息体的时候作为发送方将一组消息体根据本发明的推送方法发送到服务端，而服务端相对于客户端时作为接收方，而在接收到客户端的一组消息体之后，又作为发送方将该组消息体根据本发明的推送方法发送到作为接收方的接收端。

通过本发明实施例的消息推送方法或消息推送系统，可以解决以下现存问题：

1.推送客户端不同不能推送，一个大型的网站推送必不可少，多端支持也必不可少，有些推送服务只支持pc端或者移动端，导致体验较差，使用本发明的协议不用担心使用什么客户端，只要实现协议，消息就能推送。

2.消息推送成功率极低，对于某些场景需要使用推送，而且消息比较重要，丢失推送消息就会给客户带来很大的损失，本发明制定了对应的可靠协议保证消息推送的成功率。

3.推送消息的安全性，考虑到安全级别较高的推送消息，就会担心消息中途被截取后，读取到其中的消息，造成不必要的损失，本发明的协议提供了很多安全协议和加密算法，比如对称加密、协商秘钥等加密方案。

4.推送消息通信协议单一，单一的通信协议会使得客户端实现起来比较单一，该协议提供了可配置的推送协议，比如rmi、http、ws、hession等。

5.推送传输框架单一，随着传输框架不断发展传输框架有了质的飞跃，老的推送框架可能显得效率过低，本发明的协议实现了多种通讯协议的选择，比如netty、mina等高性能的传输框架。

6.推送消息体序列化单一，不同开发语言的序列化方式可能不同，本发明的协议支持多种序列化协议，比如josn、xml、protobuf等，根据不同的环境可以选择不同的序列化方式。

本发明实施例的用于消息推送的客户端、服务端或者消息推送系统执行各动作的详细实施方式可参考本公开前面关于消息推送方法中相对应步骤的描述，在此不再描述。可选地，客户端和服务端可以是计算机、或与计算机相关的实体等。应当理解，可以以硬件、软件、固件、中间件、代码或其任何恰当组合来实现这里描述的实施例。对于硬件实现，客户端和服务端中的处理器可以在一个或多个下列单元中实现：专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、设计用于实现这里所描述功能的其他电子单元或其组合。

上面概述了几个实施例的特征使得本领域技术人员可较好地理解本公开的方面。本领域技术人员应当理解他们可容易地使用本公开作为基础以设计或修改其他工艺和结构以实行相同目的和/或实现在此介绍的实施例的相同优点。本领域技术人员也应意识到这种等同构造没有脱离本公开的精神和范围内，并且他们在没有脱离本公开的精神和范围情况下可以做各种改变、代替和更改。