CN110290049A - 消息推送方法、服务器及计算机可读存储介质 - Google Patents

Abstract

本发明涉及数据处理技术，提供了一种消息推送方法、服务器及计算机可读存储介质。该方法先获取预设用户群的用户信息、APP信息及设备信息建立映射关系，并对每条映射关系设置对应的预设标识，然后，接收消息平台的消息推送请求，根据映射关系确定用户对应的APP、终端设备及预设标识，根据预设匹配规则获取与预设标识相匹配的预设消息模板，调用预设发送接口，利用预设消息模板向用户对应的目标APP推送消息，从预设数据库获取消息推送的回执状态，根据回执状态判断消息是否推送成功。利用本发明，通过为不同用户设置不同的标识，并对标识匹配相应的消息模板，再调用发送接口进行消息推送，提高了消息推送的效率。

Description

消息推送方法、服务器及计算机可读存储介质

技术领域

本发明涉及数据处理领域，尤其涉及一种消息推送方法、服务器及计算机可读存储介质。

背景技术

消息推送可以是通过第三方工具对用户移动设备进行的主动消息推送，用户可在移动设备锁定屏幕和通知栏看到推送消息的通知，在通知栏点击可唤起APP并查看相应的信息。

在对消息推送进行测试时，需要测试用户退出登录或绑定关系失效后用户端APP消息接收的场景，现有技术中在进行消息推送测试时，需要借助多台设备模拟用户退出登录，且难以模拟用户长时间未登录APP导致绑定关系失效的场景，无法对消息推送进行有效测试。

发明内容

鉴于以上内容，本发明提供一种消息推送方法、服务器及计算机可读存储介质，其目的在于提高消息推送的效率。

为实现上述目的，本发明提供一种消息推送方法，该方法包括：

设置步骤：获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识；

匹配步骤：接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板；

推送步骤：调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息；及

验证步骤：从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

优选的，所述推送步骤具体包括：更改用户ID、预设消息模板ID及APP ID的信息后，调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息。

优选的，所述预设消息模板包括：强关系消息模板、弱关系消息模板及强弱关系消息模板。

优选的，所述验证步骤是根据用户ID、预设消息模板ID及推送时间从所述预设数据库获取所述回执状态的。

优选的，所述预设匹配规则包括：

从所述预设数据库查询所述指定用户的预设标识的标志字段的值，根据所述值确定所述预设标识是否与所述预设消息模板相匹配。

为实现上述目的，本发明还提供一种服务器，该服务器包括：存储器及处理器，其特征在于，所述存储器上存储消息推送程序，所述消息推送程序被所述处理器执行，实现如下步骤：

设置步骤：获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识；

匹配步骤：接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板；

推送步骤：调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息；及

验证步骤：从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

优选的，所述推送步骤具体包括：更改用户ID、预设消息模板ID及APP ID的信息后，调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息。

优选的，所述预设消息模板包括：强关系消息模板、弱关系消息模板及强弱关系消息模板。

优选的，所述验证步骤是根据用户ID、预设消息模板ID及推送时间从所述预设数据库获取所述回执状态的。

为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质中包括消息推送程序，所述消息推送程序被处理器执行时，可实现如上所述消息推送方法中的任意步骤。

本发明提出的消息推送方法、服务器及计算机可读存储介质，解决了消息推送时无法模拟用户长时间未登录APP导致绑定关系失效等场景，从而无法进行消息有效推送的问题，通过为不同类型的用户设置不同的标识，并对标识匹配相应的消息模板，再调用发送接口进行消息推送，提高了消息推送的效率。

附图说明

图1为本发明服务器较佳实施例的示意图；

图2为图1中消息推送程序较佳实施例的模块示意图；

图3为本发明消息推送方法较佳实施例的流程图；

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

参照图1所示，为本发明服务器1较佳实施例的示意图。

服务器1包括但不限于存储器11、处理器12。

其中，存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器11可以是所述服务器1的内部存储单元，例如该服务器1的硬盘或内存。在另一些实施例中，所述存储器11也可以是所述服务器1的外部存储设备，例如该服务器1配备的插接式硬盘，智能存储卡(SmartMedia Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器11还可以既包括所述服务器1的内部存储单元也包括其外部存储设备。本实施例中，存储器11通常用于存储安装于所述服务器1的操作系统和各类应用软件，例如消息推送程序10的程序代码等。此外，存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器12在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器12通常用于控制所述服务器1的总体操作，例如执行数据交互或者通信相关的控制和处理等。本实施例中，所述处理器12用于运行所述存储器11中存储的程序代码或者处理数据，例如运行消息推送程序10的程序代码等。

图2仅示出了具有组件11-12以及消息推送程序10的服务器1，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

可选地，所述服务器1还可以包括用户接口，用户接口可以包括显示器(Display)、输入单元比如键盘(Keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及有机发光二极管(Organic Light-Emitting Diode，OLED)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在服务器1中处理的信息以及用于显示可视化的用户界面。

该服务器1还可以包括射频(Radio Frequency，RF)电路、传感器和音频电路等等，在此不再赘述。

在上述实施例中，处理器12执行存储器11中存储的消息推送程序10时可以实现如下步骤：

设置步骤：获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识；

匹配步骤：接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板；

推送步骤：调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息；及

验证步骤：从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

关于上述步骤的详细介绍，请参照下述图3关于消息推送程序10实施例的程序模块图以及图4关于消息推送方法实施例的流程图的说明。

在其他实施例中，所述消息推送程序10可以被分割为多个模块，该多个模块被存储于存储器12中，并由处理器13执行，以完成本发明。本发明所称的模块是指能够完成特定功能的一系列计算机程序指令段。

参照图2所示，为图1中消息推送程序10一实施例的程序模块图。在本实施例中，所述消息推送程序10可以被分割为：设置模块110、匹配模块120、推送模块130及验证模块140。

设置模块110，用于获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识。

预设用户群的用户信息、该用户群的用户安装的APP信息及使用的终端设备信息，可以是预先从其他渠道收集、存储在指定的数据库中的，也可以是在用户使用APP的过程中实时收集、存储的。例如，用户在终端设备(例如手机)通常会下载、安装若干个APP，在用户通过APP商城向服务器请求下载APP时，服务器可以收集到用户信息及用户使用的终端设备信息(例如手机操作系统版本信息)，以及用户安装的APP信息。

例如，在本实施例中，用户在终端设备登录APP，当服务器验证用户身份ID合法时，生成一个随机的Token字符串(例如“daf32da456hfdh”)，建立Token字符串和用户信息的映射关系，例如建立Token字符串“daf32da456hfdh”和用户ID“5”之间的映射关系。

在本实施例中，所述预设标识包括强关系标识及弱关系标识，通过强关系标识、弱关系标识定义强、弱关系场景来进行消息推送测试。其中，强关系场景包括：用户登录了APP，在消息平台的数据库关系表中建立了绑定关系，该绑定关系即用户信息、APP信息及设备信息之间的映射关系。弱关系场景包括：用户之前登录了APP，但用户当前退出了APP，用户退出APP后，不会删除该用户与设备间的绑定关系。

本实施例中通过对强、弱关系设置不同的预设标识区分强、弱关系，例如，将强关系用户的映射关系中的某个特定字段置为“0”，将弱关系用户的映射关系中的某个特定字段置为“1”。

消息平台有用户绑定关系的API，供APP和其他接入方的调用，通过调用设备注册与用户绑定的接口及用户退绑的接口来模拟强弱关系的场景。

在另一实施例中，在用户下载APP后进行设备的注册时，可获取APP所在的设备信息即注册的设备信息，将APP所在的设备信息与APP信息、用户信息进行绑定，可建立起用户信息、APP信息及设备信息之间的映射关系。

匹配模块120，用于接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板。

在本实施例中，接收消息平台对指定用户的消息推送请求后，根据预先建立的用户信息、APP信息及设备信息之间的映射关系，确定出指定用户对应的APP、终端设备及预设标识。其中，消息平台可以是APP的后台服务器。预设标识包括强关系标识和弱关系标识，根据预设标识可确定出用户为强关系或弱关系。例如：若指定用户的映射关系即绑定关系中的某个特定字段标识置为“0”，则表示该用户为强关系。若所述用户的映射关系即绑定关系中的某个特定字段标识置为“1”，则表示该用户为弱关系。

之后，根据预设匹配规则获取与预设标识相匹配的预设消息模板。其中，预设消息模板包括强关系消息模板、弱关系消息模板和强弱关系消息模板。如果模板配置时选择了强关系模板，则该强关系模板发送的对象是绑定关系为强关系标识的用户，只有此类用户才能收到该消息，如果此类用户退出了APP，成了弱关系标识，即使触发了该强关系模板的消息推送，用户也不会收到该强关系模板的消息推送。

如果模板配置时选择了弱关系模板，则进行该消息模板推送时，发送对象仅是绑定关系为弱关系标识的用户；如果是强关系标识的用户，即使触发了该弱关系模板的消息推送，该用户也无法收到该消息。

如果配置模板时选择了强弱关系模板，则是对强关系和弱关系标识的用户都推送消息，即无论用户是强关系还是弱关系，均能收到该消息模板推送出来的消息，即使用户退出了APP，也能收到消息的推送。以强关系标识为例，检验消息模板是否与标识对应时，可以查询数据库该用户的强弱关系标志字段的值是否为强关系，如果查询出来用户是弱关系，则调用绑定接口将弱关系的用户变成强关系。若绑定接口调用后，在数据库中查询出该用户的绑定关系仍然为弱关系则执行中止，此时记录一个缺陷。若绑定接口调用过后，该用户的绑定关系变成了强关系，则消息模板与标识相对应。

推送模块130，用于调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息。

在本实施例中，若需要模拟对强关系场景下的消息推送，在确定用户为强关系标识时，为该用户配置强关系消息模板，调用发送接口根据强关系消息模板向该标识为强关系标识的用户对应的APP推送消息。

例如：在配置文件中配置好用户的信息、消息模板ID以及APP ID，APPID为消息平台接入APP的一种标识，执行消息推送时，调用消息发送的接口对用户发送一条强关系消息，消息发送时采用的模板是强关系消息模板。

若需要模拟对弱关系场景下的消息推送测试，在确定用户为弱关系标识时，为用户配置弱关系消息模板，调用发送接口根据弱关系消息模板向该用户对应的APP推送消息。若需要模拟对强关系场景或弱关系场景下的强弱消息推送测试，则在确定所述用户为强关系或弱关系时，为该用户配置强弱关系消息模板，调用发送接口根据强弱关系消息模板向该用户对应的APP推送消息。

在另一实施例中，对多个APP进行消息推送时，仅需要修改消息模板ID，用户ID及APP ID的信息，修改完成后再执行消息推送，完成后该APP的验证也完成了。因为消息平台接入了10个以上的APP，而强弱关系消息推送的逻辑修改，需要将所有的APP均覆盖，消息推送服务器是一台，但是由于每个APP数据库的隔离的，所以需要所有的APP都验证，传统的方式通过前端测试验证需要下载所有的APP，再进行用户登录，然后退出，接着消息发送，整个测试过程耗时长。

验证模块140，用于从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

本实施例中，验证消息是否发送成功可以查询数据库中消息发送的回执状态，判断消息是否发送成功。当预设发送接口调用成功后，将消息请求存入消息队列中，然后轮询是否有新的消息推送请求，若有新的消息推送请求，根据用户的信息去查询用户与设备之间的映射关系，当映射关系存在时获取用户绑定设备的APPToken值，将APPToken值推送给预设的第三方代理服务，调用预设的第三方代理服务成功后，则记录消息已经推送成功。预设的第三方代理服务接收到请求后会将消息推送到APP，然后回调消息平台的回执接口将推送的回执状态传给消息平台数据库。

之后，根据用户ID、预设消息模板ID及推送时间查询所述数据库，或者调用获取用户消息的接口判断消息是否发送成功。如果发送成功用户消息的数据表中会新增一条消息，在APP端会提示有新消息的提醒。当消息推送失败时，则记录一个BUG。

弱关系及强弱关系推送测试场景类似，在此不作赘述。

参照图3所示，是本发明消息推送方法较佳实施例的流程图。

步骤S10，获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识。

预设用户群的用户信息、该用户群的用户安装的APP信息及使用的终端设备信息，可以是预先从其他渠道收集、存储在指定的数据库中的，也可以是在用户使用APP的过程中实时收集、存储的。例如，用户在终端设备(例如手机)通常会下载、安装若干个APP，在用户通过APP商城向服务器请求下载APP时，服务器可以收集到用户信息及用户使用的终端设备信息(例如手机操作系统版本信息)，以及用户安装的APP信息。

例如，在本实施例中，用户在终端设备登录APP，当服务器验证用户身份ID合法时，生成一个随机的Token字符串(例如“daf32da456hfdh”)，建立Token字符串和用户信息的映射关系，例如建立Token字符串“daf32da456hfdh”和用户ID“5”之间的映射关系。

在本实施例中，所述预设标识包括强关系标识及弱关系标识，通过强关系标识、弱关系标识定义强、弱关系场景来进行消息推送测试。其中，强关系场景包括：用户登录了APP，在消息平台的数据库关系表中建立了绑定关系，该绑定关系即用户信息、APP信息及设备信息之间的映射关系。弱关系场景包括：用户之前登录了APP，但用户当前退出了APP，用户退出APP后，不会删除该用户与设备间的绑定关系。

本实施例中通过对强、弱关系设置不同的预设标识区分强、弱关系，例如，将强关系用户的映射关系中的某个特定字段置为“0”，将弱关系用户的映射关系中的某个特定字段置为“1”。

消息平台有用户绑定关系的API，供APP和其他接入方的调用，通过调用设备注册与用户绑定的接口及用户退绑的接口来模拟强弱关系的场景。

在另一实施例中，在用户下载APP后进行设备的注册时，可获取APP所在的设备信息即注册的设备信息，将APP所在的设备信息与APP信息、用户信息进行绑定，可建立起用户信息、APP信息及设备信息之间的映射关系。

步骤S20，接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板。

在本实施例中，接收消息平台对指定用户的消息推送请求后，根据预先建立的用户信息、APP信息及设备信息之间的映射关系，确定出指定用户对应的APP、终端设备及预设标识。其中，预设标识包括强关系标识和弱关系标识，根据预设标识可确定出用户为强关系或弱关系。例如：若指定用户的映射关系即绑定关系中的某个特定字段标识置为“0”，则表示该用户为强关系。若所述用户的映射关系即绑定关系中的某个特定字段标识置为“1”，则表示该用户为弱关系。

之后，根据预设匹配规则获取与预设标识相匹配的预设消息模板。其中，预设消息模板包括强关系消息模板、弱关系消息模板和强弱关系消息模板。如果模板配置时选择了强关系模板，则该强关系模板发送的对象是绑定关系为强关系标识的用户，只有此类用户才能收到该消息，如果此类用户退出了APP，成了弱关系标识，即使触发了该强关系模板的消息推送，用户也不会收到该强关系模板的消息推送。

如果模板配置时选择了弱关系模板，则进行该消息模板推送时，发送对象仅是绑定关系为弱关系标识的用户；如果是强关系标识的用户，即使触发了该弱关系模板的消息推送，该用户也无法收到该消息。

如果配置模板时选择了强弱关系模板，则是对强关系和弱关系标识的用户都推送消息，即无论用户是强关系还是弱关系，均能收到该消息模板推送出来的消息，即使用户退出了APP，也能收到消息的推送。以强关系标识为例，检验消息模板是否与标识对应时，可以查询数据库该用户的强弱关系标志字段的值是否为强关系，如果查询出来用户是弱关系，则调用绑定接口将弱关系的用户变成强关系。若绑定接口调用后，在数据库中查询出该用户的绑定关系仍然为弱关系则执行中止，此时记录一个缺陷。若绑定接口调用过后，该用户的绑定关系变成了强关系，则消息模板与标识相对应。

步骤S30，调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息。

在本实施例中，若需要模拟对强关系场景下的消息推送，在确定用户为强关系标识时，为该用户配置强关系消息模板，调用发送接口根据强关系消息模板向该标识为强关系标识的用户对应的APP推送消息。

例如：在配置文件中配置好用户的信息、消息模板ID以及APP ID，APPID为消息平台接入APP的一种标识，执行消息推送时，调用消息发送的接口对用户发送一条强关系消息，消息发送时采用的模板是强关系消息模板。

若需要模拟对弱关系场景下的消息推送测试，在确定用户为弱关系标识时，为用户配置弱关系消息模板，调用发送接口根据弱关系消息模板向该用户对应的APP推送消息。若需要模拟对强关系场景或弱关系场景下的强弱消息推送测试，则在确定所述用户为强关系或弱关系时，为该用户配置强弱关系消息模板，调用发送接口根据强弱关系消息模板向该用户对应的APP推送消息。

在另一实施例中，对多个APP进行消息推送时，仅需要修改消息模板ID，用户ID及APP ID的信息，修改完成后再执行消息推送，完成后该APP的验证也完成了。因为消息平台接入了10个以上的APP，而强弱关系消息推送的逻辑修改，需要将所有的APP均覆盖，消息推送服务器是一台，但是由于每个APP数据库的隔离的，所以需要所有的APP都验证，传统的方式通过前端测试验证需要下载所有的APP，再进行用户登录，然后退出，接着消息发送，整个测试过程耗时长。

步骤S40，从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

本实施例中，验证消息是否发送成功可以查询数据库中消息发送的回执状态，判断消息是否发送成功。当预设发送接口调用成功后，将消息请求存入消息队列中，然后轮询是否有新的消息推送请求，若有新的消息推送请求，根据用户的信息去查询用户与设备之间的映射关系，当映射关系存在时获取用户绑定设备的APPToken值，将APPToken值推送给预设的第三方代理服务，调用预设的第三方代理服务成功后，则记录消息已经推送成功。预设的第三方代理服务接收到请求后会将消息推送到APP，然后回调消息平台的回执接口将推送的回执状态传给消息平台数据库。

之后，根据用户ID、预设消息模板ID及推送时间查询所述数据库，或者调用获取用户消息的接口判断消息是否发送成功。如果发送成功用户消息的数据表中会新增一条消息，在APP端会提示有新消息的提醒。当消息推送失败时，则记录一个BUG。

此外，本发明实施例还提出一种计算机可读存储介质，该计算机可读存储介质可以是硬盘、多媒体卡、SD卡、闪存卡、SMC、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、便携式紧致盘只读存储器(CD-ROM)、USB存储器等等中的任意一种或者几种的任意组合。所述计算机可读存储介质中包括消息推送程序10，所述消息推送程序10被处理器执行时实现如下操作：

设置步骤：获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识；

匹配步骤：接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板；

推送步骤：调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息；及

验证步骤：从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

本发明之计算机可读存储介质的具体实施方式与上述消息推送方法的具体实施方式大致相同，在此不再赘述。

需要说明的是，上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。并且本文中的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。

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

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种消息推送方法，应用于服务器，其特征在于，该方法包括：

设置步骤：获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识；

匹配步骤：接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板；

推送步骤：调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息；及

验证步骤：从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

2.如权利要求1所述的消息推送方法，其特征在于，所述推送步骤具体包括：更改用户ID、预设消息模板ID及APP ID的信息后，调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息。

3.如权利要求1所述的消息推送方法，其特征在于，所述预设消息模板包括：强关系消息模板、弱关系消息模板及强弱关系消息模板。

4.如权利要求1至3任意一项所述的消息推送方法，其特征在于，所述验证步骤是根据用户ID、预设消息模板ID及推送时间从所述预设数据库获取所述回执状态的。

5.如权利要求1所述的消息推送方法，其特征在于，所述预设匹配规则包括：

从所述预设数据库查询所述指定用户的预设标识的标志字段的值，根据所述值确定所述预设标识是否与所述预设消息模板相匹配。

6.一种服务器，该服务器包括存储器及处理器，其特征在于，所述存储器上存储消息推送程序，所述消息推送程序被所述处理器执行，实现如下步骤：

设置步骤：获取预设用户群的用户信息、该预设用户群的用户安装的APP信息及使用的终端设备信息，建立所述用户信息、APP信息及终端设备信息之间的映射关系，并对所述映射关系设置对应的预设标识；

匹配步骤：接收消息平台对指定用户发送的消息推送请求，根据所述映射关系确定出所述指定用户对应的APP、终端设备及预设标识，并根据预设匹配规则确定与所述预设标识相匹配的预设消息模板；

推送步骤：调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息；及

验证步骤：从预设数据库获取消息推送的回执状态，根据所述回执状态判断所述消息是否推送成功。

7.如权利要求6所述的服务器，其特征在于，所述推送步骤具体包括：更改用户ID、预设消息模板ID及APP ID的信息后，调用预设发送接口，利用所述预设消息模板向所述指定用户的终端设备安装的所述APP推送消息。

8.如权利要求6所述的服务器，其特征在于，所述预设消息模板包括：强关系消息模板、弱关系消息模板及强弱关系消息模板。

9.如权利要求6所述的服务器，其特征在于，所述验证步骤是根据用户ID、预设消息模板ID及推送时间从所述预设数据库获取所述回执状态的。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中包括消息推送程序，所述消息推送程序被处理器执行时，可实现如权利要求1至5中任一项所述消息推送方法的步骤。