CN111866769B - 一种消息发送方法、装置、服务器及介质 - Google Patents

Abstract

本申请适用于通信技术领域，提供了一种消息发送方法、装置、服务器及介质，所述方法包括：接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息和消息发送策略信息；根据所述消息发送需求信息，生成多个待发送消息体；根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列；通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送。通过上述方法，可以采用多种发送渠道对消息进行发送，有助于提高消息的触达率。

Description

一种消息发送方法、装置、服务器及介质

技术领域

本申请属于通信技术领域，尤其涉及一种消息发送方法、装置、服务器及介质。

背景技术

随着通信技术的发展，消息发送的途径变得多样，比如可以通过短信、微信、蓝信等各种方式发送消息。

目前，在发送消息时，一般每次都只能通过单一渠道发送，不能够多渠道灵活推送。在一些情况下，需要群发给用户的消息，如果只通过一个发送渠道进行发送，接收方不一定能准确地接收到。若通过每一个渠道都对该消息发送一次，则又需要分别对每个发送渠道进行一次操作，不仅费时费力，还会严重影响消息的发送效率。

发明内容

本申请实施例提供了一种消息发送方法、装置、服务器及介质，可以采用多种发送方式和发送渠道，灵活地发送消息，提高消息的触达率。

第一方面，本申请实施例提供了一种消息发送方法，应用于统一消息业务平台，所述方法包括：

接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息和消息发送策略信息；

根据所述消息发送需求信息，生成多个待发送消息体；

根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列；

通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送。

第二方面，本申请实施例提供了一种消息发送装置，应用于统一消息业务平台，所述装置包括：

接收模块，用于接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息和消息发送策略信息；

生成模块，用于根据所述消息发送需求信息，生成多个待发送消息体；

分发模块，用于根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列；

发送模块，用于通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送。

第三方面，本申请实施例提供了一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，包括所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在服务器上运行时，使得服务器执行上述第一方面中任一项所述的方法。

本申请实施例与现有技术相比存在的有益效果是：在本申请实施例中，统一消息业务平台连接有多个发送渠道，每个发送渠道均可以对消息进行发送。统一消息业务平台在接收到消息发送请求报文后，可以从消息发送请求报文中提取出消息发送需求信息和消息发送策略信息，根据消息发送需求信息，可以生成多个待发送消息体，再按照消息发送策略将多个待发送消息体分发至对应的消息发送队列后，可以通过消息发送队列对应的发送渠道，完成对消息的发送。在本申请实施例中，待发送消息体可以通过不同的渠道进行发送，只要其中一个发送渠道成功将消息发送至接收方，接收方就可以接收到消息，提高了消息的触达率；本申请实施例通过设置消息发送策略，可以实现消息的灵活发送。例如，当一个发送渠道的消息发送成功后，其他发送渠道可以不再进行消息发送，节省了发送资源。

附图说明

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

图1是本申请实施例一提供的一种消息发送方法的流程示意图；

图2(a)为本申请实施例一提供的一种单点发送的示意图；

图2(b)为本申请实施例一提供的一种并行发送的示意图；

图2(c)为本申请实施例一提供的一种串行发送的示意图；

图3是本申请实施例一提供的一种发送方设置发送流程的示意图；

图4为本申请实施例一提供的一种发送方进行页面设置的一种流程图；

图5为本申请实施例一提供的一种生成预览界面的一种流程示意图；

图6是本申请实施例二提供的一种消息发送方法的流程示意图；

图7是本申请实施例二提供的一种消息发送方法的系统流程图；

图8是本申请实施例二提供的一种统一消息业务平台的工作流程图；

图9是本申请实施例二提供的一种消息分发服务的流程示意图；

图10是本申请实施例三提供的一种消息发送方法的流程示意图；

图11是本申请实施例三提供的一种消息发送系统示意图；

图12是本申请实施例三提供的一种消息发送资费计算的流程示意图；

图13时本申请实施例四提供的一种消息发送装置的结构示意图；

图14为本申请实施例五提供的一种服务器的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本申请。在其他情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

图1是本申请实施例一提供的一种消息发送方法的流程示意图，如图1所示，所述方法包括：

S101，接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息和消息发送策略信息；

本实施例提供的消息发送方法可以应用于统一消息业务(Unified MessagingService，UMS)平台。统一消息业务平台可以通过应用接口或网络接口接收消息发送请求报文，消息发送请求报文中可以包括消息发送需求信息和消息发送策略信息。消息发送需求信息可以包括消息模板、消息的接收方、接收方的接收地址、发送参数和/或其他发送要求；消息模板可以为需要发送的消息的模板内容，例如，工资消息的模板可以为：尊敬的xxx，您尾号为xxxx的银行卡接收到本月工资人民币xxx元。接收方可以为一个用户名称，接收地址可以为该用户名称对应的邮件地址、微信号码、蓝信号码和/或手机号码等；发送参数包括对应消息模板中的待填写的内容，将消息模板和发送参数组合在一起，可以得到发送给接收方的具体消息内容。

发送方可以通过应用程序或者网页上传自己的发送需求等信息，应用程序或网页根据发送方上传的信息生成消息发送请求报文，然后将消息发送请求报文发送至统一消息业务平台。

示例性地，发送方可以为有业务发送需求的企业或个体。发送方可以通过页面设置来上传消息发送策略和消息发送需求。消息发送策略可以包括消息发送渠道和发送方式，消息发送渠道可以包括邮件、蓝信、微信、APP、短信等。发送方式可以包括单点发送、并行发送和串行发送。

图2(a)为一种单点发送的示意图。单点发送即只配置一个消息发送渠道，若通过该消息发送渠道发送消息失败，则判定消息发送失败,图2(b)为一种并行发送的示意图。并行发送可选择一个消息发送渠道发送消息也可选择多个消息发送渠道发送消息，只要其中一个消息发送渠道将消息发送成功，则消息发送成功，图2(c)为一种串行发送的示意图。串行发送可只选择一个消息渠道或多个消息渠道，每个消息发送渠道相互独立，并只有前一个消息发送渠道发送消息失败后，才可以采用下一消息发送渠道进行消息发送。

待发送消息的消息发送策略，可以包括一种发送方式，也可以包括多种发送方式。

图3是本申请实施例一提供的一种发送方设置发送流程的示意图。如图3所示，发送方在设置消息发送策略前，可以选择消息模板，消息模板可以由发送方上传，也可以直接使用网页提供的消息模板，设置完消息模板后，可以选择发送方式，发送方可以只选择一种发送方式，也可以选择多种发送方式，例如，可以选择3个发送渠道并行发送消息，2个发送渠道串行发送消息。在选择完发送方式后，需要选择不同发送方式所对应的发送渠道，另外，若串行发送方式对应的发送渠道包括多个，还可以设置串行发送渠道的先后顺序。在另一种可能的实现方式中，可以不事先设置消息模板，而是在选择完发送渠道后，为每一个发送渠道设置一个对应的消息模板。另外，因为通过不同渠道发送给同一用户的消息内容基本相同，所以各个发送渠道对应的消息模板的相似度非常大，因此也可以只上传一个消息模板，然后由系统自动生成各个消息渠道对应的消息模板。此外，若设置的消息发送方式包括多个，还可以设置消息的发送顺序。例如，当既有串行发送，又有并行发送时，可以设置是先并行发送还是先串行发送。当然，也存在一种状况是，发送给所有的接收方的消息完全一致，此时，不需要上传消息模板，可以直接上传需要发送的消息内容。

图4为本申请实施例一提供的一种发送方进行页面设置的流程示意图。发送方可以登录统一消息业务平台相连的网页，根据页面的提示进行操作，从而将需要发送的消息提交至统一消息业务平台。具体地，发送方可以在页面设置消息发送策略。例如，按照图3的流程设置消息发送策略；另外，网页也可以提供多个策略模板供发送方选择，发送方可以直接选择相应的消息发送策略。发送方还需要通过页面上传发送需求文件。发送方可以直接上传自定义的发送需求文件，也可以由网页根据消息发送策略生成带有固定表头的发送需求列表模板，然后由发送方下载发送需求列表模板，发送方通过将发送需求信息填充至模板中，得到发送需求列表后，可以将发送需求列表上传至网页。此外，发送方还可以设置发送时间。若需要定时发送，则可以设置发送的时间段，若不设置发送时间段，发送时间可以默认为当前时间。发送方在通过网页完成设置后，后端可以根据发送方设置和上传的数据生成预览信息供发送方查看，发送方根据预览信息可以对之前的设置进行调整，或直接点击提交按钮，将该预览信息对应的消息发送请求报文提交至统一消息业务平台，由统一消息业务平台对消息进行发送。

此外，发送方还可以通过网页上传黑名单和白名单，来对发送需求中的接收地址进行过滤。黑名单中可以包括不合规的接收地址；白名单中可以包括合规的接收地址。

网页可以接收发送方的设置信息，然后对设置信息进行处理，生成预览界面，生成预览界面的过程可以如图5所示。首先检测用户是否上传待发送消息相关文件，例如发送需求文件、消息发送策略、消息模板等，若已经接收到文件，可以检测发送方设置的消息发送策略是否被禁用，若消息发送策略被禁用，则直接结束消息发送，并向发送方提示消息发送策略禁用信息；若消息发送策略未被禁用，则对发送方上传的消息模板或消息内容进行检测，判断其中是否包含敏感词；若消息内容或消息模板包含了预设的敏感词，可以停止消息发送，并将提示信息显示在前端页面，提示发送方进行修改；若消息内容或消息模板通过敏感词验证，则可以从发送需求文件中提取发送需求列表的表头，检测表头是否与消息发送策略相匹配。例如，消息发送策略中包括了微信发送渠道，若发送需求列表的表头中没有微信号一栏，则可以判定发送需求列表的接收地址类别与发送策略不匹配，并将此信息提交给发送方，供发送方修改。在完成以上检测后，可以对发送方上传的文件进行解析，获得其中的红名单和黑名单，其中，红名单中包括的接收地址为必须发送地址；黑名单中的接收地址为非法地址。根据用户上传的红名单和黑名单，可以获得实际的黑名单。若一个接收地址既存在于红名单中，又存在于黑名单中，则可以将该接收地址从黑名单中删除，删除掉黑名单中的所有存在于红名单中的接收地址，得到的即为实际的黑名单。

之后，从发送需求列表中依次提取出一条消息发送任务，然后可以对其接收地址进行检测，例如，手机号码应为11位阿拉伯数字，邮箱地址必须有@字符，接收地址是否在实际黑名单中等。将发送需求列表中的不合规接收地址删除，写入无效文件，可以节约资源，提高发送效率。再对发送参数进行检测，检测发送参数是否与消息模板匹配。若匹配，则将该条消息发送任务写入有效文件，否则将其写入无效文件。在将发送需求列表中的每一个消息发送任务处理完后，检测有效文件中是否包含至少一条消息发送任务，若是，则弹出预览界面，预览界面中包含有效文件和无效文件，有效文件和无效文件可以供发送方下载查看；若有效文件中不包含消息发送任务，则直接结束消息发送进程。

当发送方针对预览界面点击发送之后，网页将组装消息发送请求报文，并将消息发送请求报文提交至统一消息业务平台。报文内容可以包括消息发送需求、消息发送策略、消息内容和/或消息模板等。

发送方在发送消息时，可能会需要上级领导审批，此时可以检测是否审批通过，若审批通过，则可以组装消息发送请求报文并发送到统一消息业务平台。

当统一消息业务平台接收到消息发送请求报文后，可以对报文进行解析，然后进行消息发送。

S102，根据所述消息发送需求信息，生成多个待发送消息体；

上述待发送消息体可以包括消息内容、接收地址等信息，接收地址与发送渠道相对应。将待发送消息体提交至对应的发送渠道后，发送渠道可以将消息内容发送至对应的接收地址，从而使接收方能接收到消息。

具体地，统一消息业务平台接收到消息发送请求报文后，从中提取出消息模板、发送需求信息。发送需求信息中可以包括消息的接收方、发送参数、接收地址等。可以将其中每一个接收方分别与对应的各个接收地址以及对应于接收地址的发送参数组合为多个消息体。一个接收方可以对应多个待发送消息体。将待发送消息体提交至对应的消息发送渠道，则可以进行一次消息发送。例如，在发送需求中，包括对接收方A发送信息y，接收方的地址包括手机号码、微信号、邮箱号，则可以将接收方A的短信发送参数与短信消息模板组合为短信消息内容，将短信消息内容、手机号码组合为接收方A针对于短信发送渠道的待发送消息体；将接收方A的微信发送参数与微信消息模板组合为微信消息内容，将微信消息内容、微信号组合为接收方A针对于微信发送渠道的待发送消息体；将接收方A的邮件发送参数与邮件消息模板组合为邮件消息内容，将邮件消息内容、邮箱号组合为接收方A针对于邮件发送渠道的待发送消息体。

S103，根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列；

具体地，统一消息业务平台可以包括多个发送队列，每个发送队列可以与一个消息发送渠道相对应。每个待发送消息体包括一个接收地址，每个接收地址对应一个发送渠道，一个发送渠道对应一个发送队列。待发送消息体可以根据接收地址确定对应的目标发送队列。

根据发送需求生成的多个待发送消息体，可以根据接收地址和发送渠道的对应关系，提交至对应的发送队列中。发送队列中的待发送消息体可以依次提交至对应的发送渠道进行发送。例如，若待发送消息体的接收地址为微信号，则可以将该待发送消息体提交至微信发送队列中；若发送消息体的接收地址为手机号，则可以将该待发送消息体提交至短信发送队列中。

消息发送策略信息包括发送方式和发送渠道，在对待发送消息体进行分发时，可以根据发送方式，确定分发的顺序。例如，若发送方式为并行发送，则可以将针对于同一个接收方的各个待发送消息体提交至对应的发送队列中。若发送方式为串行发送，对于同一个接收方，则可以按照串行发送渠道的先后顺序，提交排列在第一位的发送渠道所对应的待发送消息体至对应的发送队列，当这一待发送消息体发送失败后，再提交排列在下一顺序位的发送渠道所对应的待发送消息体至对应的发送队列。

例如，对接收方A发送信息y，消息发送策略为先采用微信和邮箱并行发送消息，再采用短信发送消息。此时，可以将针对于微信发送渠道的待发送消息体提交至微信发送队列，将针对于邮箱发送渠道的待发送消息体提交至邮箱发送队列；之后等待微信平台或者邮箱平台返回发送成功或失败的信息，若其中一个渠道消息发送成功，则不再采用短信发送消息；若微信和邮箱均发送消息失败，则将针对于短信发送渠道的待发送消息体提交至短信发送队列。

S104，通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送。

具体地，将发送队列中的待发送消息体通过接口提交至对应的渠道。例如，将微信发送队列的待发送消息体通过微信平台提供的接口提交至微信平台，微信平台完成对该消息的发送，并将发送结果返回给统一消息业务平台。

本实施例中，可以通过页面配置设置发送内容、消息发送策略和消息发送需求，操作简单；消息可以通过多种发送渠道发送至用户，提高了消息的触达率。

图6是本申请实施例二提供的一种消息发送方法的流程示意图，如图6所示，所述方法包括：

S601，接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息和消息发送策略信息；

本实施例提供的消息发送方法可以应用于统一消息业务平台。

统一消息业务平台可以通过应用程序接口接收消息发送请求报文，也可以通过网页接收消息发送请求报文。在接收到消息请求报文后，可以对报文进行数据校验，检测数据是否来自合法的发送方或应用程序。若数据校验成功，可以将数据存入主队列中。若数据校验失败，可以直接返回消息发送失败消息。

S602，从所述消息发送需求信息中，提取多个消息发送任务；

具体地，从主队列中依次提取出消息发送请求报文，然后提取出报文中的消息发送需求信息和消息发送策略，根据消息发送需求，可以提取出多个消息发送任务，每个消息发送任务对应不同的接收方。可以为每个消息发送任务生成一个唯一流水号。

S603，将所述消息发送参数组装到所述消息模板中，获得待发送的消息内容；

具体地，从消息发送请求报文中提取出消息模板，然后将发送参数填入消息模板中，组合成消息内容。

另外，不同的消息发送渠道可以对应不同的消息模板，例如，邮件格式与短信格式不同，因此采用二者发送消息时的消息模板也不相同。从消息发送任务中获取各个发送渠道的发送参数，然后将其与对应模板相组合，生成对应的各个消息内容。

S604，检测所述待发送的消息内容中是否包括预设的敏感词；

具体地，统一消息业务平台可以包括预设的敏感词库，检测消息内容中是否包括敏感词库中的敏感词。

敏感词还可以由发送方自行设定，并将设置的敏感词组装在消息发送请求报文中。

S605，若所述待发送的消息内容中包括敏感词，则将所述敏感词对应的消息发送任务加入发送失败队列中；

若消息内容包括敏感词，则不能对消息内容进行发送，则将对应的消息发送任务加入发送失败队列中。

S606，若所述待发送的消息内容中不包括敏感词，则将所述待发送的消息内容分别与所述至少一个接收地址组合，得到待发送消息体；

若消息内容不包括敏感词，则可以将消息内容分别与对应各个接收地址组合，生成消息发送任务的多个待发送消息体。

S607，根据所述消息发送策略信息，确定所述消息发送任务的消息发送渠道；

具体地，消息发送策略包括消息的接收渠道和消息发送方式。每个消息任务可以对应不同的接收地址，每个接收地址对应一个消息发送渠道。

S608，将所述多个待发送消息体，分别提交至与所述消息发送渠道关联的消息发送队列；

具体地，若发送方式为并行发送，则确定各个并行发送渠道所对应的待发送消息体，然后将各个并行发送渠道所对应的待发送消息体提交至对应的发送队列。

若发送方式为串行发送，则对应的多个串行发送渠道包括先后顺序。一般地，微信发送、公司应用程序发送消息一般不需要额外的费用，所以可以优先采用这些发送渠道，短信发送运营商一般要收取相应的费用，可以当其他渠道都发送消息失败之后，再采用短信发送渠道发送消息。先确定排列在第一位的串行发送渠道所对应的待发送消息体，然后将该消息体提交至对应的发送队列，当该消息体发送失败后，则采用下一顺序位的串行发送渠道进行消息发送。

S609，通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送。

具体地，统一消息平台通过接口将各个发送队列中的待发送消息体提交至对应的发送渠道，各个发送渠道接收到待发送消息体后，将消息内容发送至对应的接收地址。

图7是实施例二提供的一种消息发送方法的系统流程图，发送方可以通过与统一消息业务平台相连的客户端进行设置。客户端接收到发送方设置的信息后，可以检测是否需要分批发送消息，若需要分批发送消息，则可以根据发送方提供的数据设置发送批次，并为每一批次的发送任务设置发送时间段；然后根据发送方提供的数据组装有效发送数据并提交给发送方预览，发送方在点击提交后，检测此次发送消息是否需要经过管理人员批准，若需要，则创建审批任务，当审批通过时，将组装的消息发送请求报文提交至统一消息业务平台；若不需要审批，则检测是否需要定时发送，若需要定时发送时，则生成定时任务，当到达发送时间时，将报文提交至统一消息业务平台。

统一消息业务平台接收到消息发送请求报文后，提取报文中的消息发送策略信息和发送需求信息，然后将消息分发至不同的发送渠道进行发送。若发送方式为串行发送，则在第一个串行发送渠道发送消息失败后，再采用下一个串行发送渠道进行消息发送；当发送方式为并行发送时，同时采用多个消息发送渠道进行消息发送，只要有一个发送渠道成功发送消息，则说明发送成功；若发送方式为单点发送，则只采用一种消息发送渠道进行消息发送。

图8是实施例二提供的一种统一消息业务平台的工作流程图，如图8所示，统一消息业务平台可以通过API接口或者WEB接口接收消息发送请求报文，消息接收服务可以接收报文并对报文进行处理，生成待发送消息体；消息分发服务根据消息发送策略，将待发送消息体分发至不同的发送渠道进行消息发送。当待发送消息体发送失败时，则将消息返回至消息分发服务，消息分发服务检测对应消息发送任务是否完成，并根据消息发送策略确定是否需要通过其他发送渠道发送消息。

图9是实施例二提供的一种消息分发服务的流程示意图，如图9所示，从队列中取出待发送消息体，然后检测待发送消息体的接收地址是否合规，获取发送方提供的红名单、黑名单和白名单，若接收地址在红名单中，则需要对该待发送消息体进行发送，并可以提升对应的待发送消息体的优先级，若接收地址不在红名单而在黑名单中，则不可以对待发送消息体进行发送，若接收地址不在红名单也不在黑名单中但是在白名单中，可以按照发送策略对该待发送消息体进行发送。通过红名单、黑名单和白名单对接收地址进行检测后，可以获取消息内容，对消息内容进行检测，检测消息内容中是否包括敏感词，若消息内容通过检测，则将对应的待发送消息体的发送状态设置为发送中，将待发送消息体提交至对应的发送渠道中。

本实施例中，通过配置多个发送渠道进行消息发送，只要其中一个发送渠道发送成功，则不再继续发送消息，节约了企业消息推送成本；其次，发送方可以通过页面设置完成对消息的发送，只需要管理消息发送策略，操作简单便于上手；第三，根据对应的流水号，可以统计出消息发送的数量，便于计算消息发送资费和监督消息发送进程。

图10是本申请实施例三提供的一种消息发送方法的流程示意图，如图10所示，所述方法包括：

S1001，接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息和消息发送策略信息；

本实施例的方法可以应用在统一消息业务平台，统一消息业务平台可以采用Redis数据库。Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。

在统一消息业务平台可以采用队列进行消息的接收和分发。具体地，可以将接收到的消息发送请求报文存储在主队列中。

S1002，从所述消息发送需求信息中，提取多个消息发送任务；

具体地，可以从主队列中获取消息发送请求报文，并进行解析，提取出消息发送需求信息，然后将消息发送需求信息拆分为多个消息发送任务。

S1003，根据所述多个消息发送任务和所述消息模板，生成多个待发送消息体；

具体地，待发送消息体重可以包括发送参数、接收地址、消息模板等信息；也可以直接将消息模板和发送参数组合为消息内容，将消息推内容和接收地址组合为待发送消息体。将待发送消息体存储在预备队列中。

S1004，根据所述消息发送任务的发送方式，为所述消息发送任务建立相应的发送节点；

具体地，若所述消息发送任务的发送方式为并行发送，则为所述消息发送任务建立一个并行发送节点；若所述消息发送任务的发送方式为串行发送，则为所述消息发送任务建立一个串行发送节点；若所述消息发送任务的发送方式为单点发送，则为所述消息发送任务建立一个单点发送节点。

当然，一个消息发送任务的发送方式可以既包括并行发送，也包括串行发送，此时消息发送任务既包括并行发送节点也包括串行发送节点。

S1005，若所述消息发送任务的发送节点为并行发送节点，则通过所述多个并行连接的消息发送渠道同时对所述待发送消息体进行发送；

具体地，若消息发送任务的发送方式为并行发送，则为所述消息发送任务建立一个并行发送节点，一个并行发送节点至少对应一个发送渠道，每个发送渠道对应一个待发送消息体，将并行发送节点对应的多个待发送消息体同时通过各自对应的发送渠道发送至接收方。

S1006，若所述消息发送任务的发送节点为串行发送节点，则按照所述多个串行连接的消息发送渠道的连接顺序，依次对所述待发送消息体进行发送；

具体地，若消息发送任务的发送方式为串行发送，则为所述消息发送任务建立一个串行发送节点，一个串行发送节点对应一个发送渠道，每个发送渠道对应一个待发送消息体，按照预先设置的顺序，依次采用发送渠道对对应的待发送消息体进行发送。

S1007，若通过所述多个并行连接的消息发送渠道中任一消息发送渠道发送所述待发送消息体成功，则记录发送成功信息；否则将所述待发送消息体提交至所述并行发送节点的下一节点进行发送；

若接收到第三方服务平台返回的某一消息体发送成功的信息，则记录该消息发送任务发送成功。

若消息发送任务的并行发送节点对应的待发送消息体全部发送失败，则检测该并行发送节点是否包括相连的下一发送节点，若有，则采用下一发送节点进行消息发送，若无，则消息发送失败。

S1008，若通过所述多个串行连接的消息发送渠道中当前的消息发送渠道发送所述待发送消息体成功，则停止所述待发送消息体的发送，并记录发送成功信息；否则将所述待发送消息体提交至所述当前的消息发送渠道的下一消息发送渠道进行发送；当依次通过所述串行发送节点的全部消息发送渠道发送所述待发送消息体均失败时，将所述待发送消息体提交至所述串行发送节点的下一节点进行发送。

具体地，若串行发送的消息体发送成功，则表明对应的消息发送任务完成，可以停止对消息的发送；若串行发送的消息体发送失败，则检测是否还存在下一个串行发送渠道，若存在，则查找该串行发送渠道所对应的待发送消息体，然后采用该串行发送渠道对待发送消息体进行发送。当不存在下一个串行发送渠道时，检测当前的串行发送节点是否具有下一个发送节点，若当前的串行发送节点具有下一个发送节点，则采用下一个发送节点进行消息发送。若不包括下一个发送节点，则将该消息发送任务存储至发送失败队列中。

在本实施例中，每次对待发送消息体进行发送后，都需要将相关信息写入日志，便于进行统计和计算资费。

当平台出现异常后，例如断电后，可以在开机后查看发送队列中的待发送文件，将还在有效期内的发送文件存储至预备队列中，之后再进行发送，从而实现异常后的数据恢复。

图11是实施例三提供的一种消息发送系统示意图。如图11所示，统一消息业务平台分别与外部接口、第三方服务相连。发送方可以通过外部接口向统一消息业务平台上传消息发送请求，统一消息业务平台通过消息接收服务模块将消息发送请求报文接收并存储到队列中，消息分发服务模块从队列汇总提取待发送的消息，然后根据消息发送策略，将待发送消息提交至第三方平台如短信网关、微信平台和蓝信平台，来完成对消息的发送。

图12是实施例三提供的一种消息资费计算的流程示意图，如图12所示，图11中的消息分发服务拉取消息体发送失败数据，检测当前消息体对应的消息发送任务当前是否处于最后一个发送节点，若是，则确认消费，删除队列中的此条信息；若不是，则检测并行节点对应的发送渠道数是否大于1，若是，则通过查找发送日志，检查日志中是否有成功发送的记录；若发送成功，则删除该日志数据；若发送日志中发送日志条数等于并行发送渠道数量，则删除数据库中的这一日志数据，查找该消息发送任务的下一个发送节点，采用下一发送节点对消息体进行发送。在图12中，每执行完一条消息发送任务计算一次费用，若一条消息通过多个渠道发送成功，也只计算一次费用。

本实施例中，通过多种发送渠道和发送方式对消息进行发送，可以提高消息的触达率；将所有的发送信息记录在日志中，便于进行发送费用的结算；采用一个流水号标记消息发送任务，便于进行报表统计。

通过上述各个实施例对本申请提供的消息发送方法进行介绍，可以了解本方法包括如下优点：

1、节约消息发送成本，提高触达率。通过配置多渠道发送，只要其中一个渠道发送成功了，其他渠道就可以不再对该消息进行发送，大大节约了企业信息推送成本。某一渠道发送失败，可以自动通过其他节点或渠道进行再发送，大大提高了消息发送的成功率。

2、发送过程操作简单，方便易上手且便于管理。发送方不需要熟悉不同平台渠道的发送操作，只需要管理好发送策略，根据不同的消息类型创建不同的发送策略，发送消息时只需要选择创建好的策略，就可以根据相应策略配置的渠道进行灵活发送。此外，发送策略的创建过程简单直观，策略流程图采用可视化操作，方便发送方了解整个流程信息。

3、便于报表统计。发送方只需要关注每批次的发送任务id，就可以统计出各渠道的发送情况，方便对消息的发送情况进行分析。

图13是本申请实施例四提供的一种消息发送装置的结构示意图，如图13所示，所述装置13包括：

接收模块131，用于接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息和消息发送策略信息；

生成模块132，用于根据所述消息发送需求信息，生成多个待发送消息体；

分发模块133，用于根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列；

发送模块134，用于通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送。

在上述装置13中，所述消息发送请求报文中还包括消息模板，所述生成模块132，包括：

消息发送任务提取子模块，用于从所述消息发送需求信息中，提取多个消息发送任务；

生成子模块，用于根据所述多个消息发送任务和所述消息模板，生成多个待发送消息体。

上述装置13中，所述多个消息发送任务分别具有相应的消息发送参数和至少一个接收地址，所述生成子模块包括：

消息内容获取单元，用于将所述消息发送参数组装到所述消息模板中，获得待发送的消息内容；

组合单元，用于将所述待发送的消息内容分别与所述至少一个接收地址组合，得到待发送消息体。

上述生成子模块还包括：

敏感词检测单元，用于检测所述待发送的消息内容中是否包括预设的敏感词；

第一判断单元，用于若所述待发送的消息内容中包括敏感词，则将所述敏感词对应的消息发送任务加入发送失败队列中；

第二判断单元，用于若所述待发送的消息内容中不包括敏感词，则执行将所述待发送的消息内容分别与所述至少一个接收地址组合，得到待发送消息体的步骤。

在上述装置13中，每个消息发送任务分别具有一种消息发送策略信息，所述消息发送策略信息包括至少一个消息发送渠道，每个消息发送渠道与一个消息发送队列关联，所述分发模块133包括：

发下渠道确定子模块，用于根据所述消息发送策略信息，确定所述消息发送任务的消息发送渠道；

提交子模块，用于将所述多个待发送消息体，分别提交至与所述消息发送渠道关联的消息发送队列。

上述装置13中，所述消息发送策略信息还包括消息发送方式，所述消息发送方式包括串行发送和/或并行发送，所述发送模块134，包括：

发送节点建立子模块，用于根据所述消息发送任务的发送方式，为所述消息发送任务建立相应的发送节点，所述发送节点包括并行发送节点和/或串行发送节点；所述并行发送节点包括多个并行连接的消息发送渠道，所述串行发送节点包括多个串行连接的消息发送渠道；

并行发送子模块，用于若所述消息发送任务的发送节点为并行发送节点，则通过所述多个并行连接的消息发送渠道同时对所述待发送消息体进行发送；

串行发送子模块，用于若所述消息发送任务的发送节点为串行发送节点，则按照所述多个串行连接的消息发送渠道的连接顺序，依次对所述待发送消息体进行发送。

上述装置13还包括：

并行判断模块，用于若通过所述多个并行连接的消息发送渠道中任一消息发送渠道发送所述待发送消息体成功，则记录发送成功信息；否则将所述待发送消息体提交至所述并行发送节点的下一节点进行发送；

串行判断模块，用于若通过所述多个串行连接的消息发送渠道中当前的消息发送渠道发送所述待发送消息体成功，则停止所述待发送消息体的发送，并记录发送成功信息；否则将所述待发送消息体提交至所述当前的消息发送渠道的下一消息发送渠道进行发送；当依次通过所述串行发送节点的全部消息发送渠道发送所述待发送消息体均失败时，将所述待发送消息体提交至所述串行发送节点的下一节点进行发送。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述得比较简单，相关之处参见方法实施例部分的说明即可。

图14为本申请实施例五提供的服务器的结构示意图，该服务器可以是用于实现前述各个实施例中统一消息业务平台各项功能的服务器。如图14所示，该实施例的服务器14包括：至少一个处理器140(图14中仅示出一个)处理器、存储器141以及存储在所述存储器141中并可在所述至少一个处理器140上运行的计算机程序1414，所述处理器140执行所述计算机程序1414时实现上述任意各个方法实施例中的步骤。

该服务器可包括，但不仅限于，处理器140、存储器141。本领域技术人员可以理解，图14仅仅是服务器14的举例，并不构成对服务器14的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器140可以是中央处理单元(Central Processing Unit，CPU)，该处理器140还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器141在一些实施例中可以是所述服务器14的内部存储单元，例如服务器14的硬盘或内存。所述存储器141在另一些实施例中也可以是所述服务器14的外部存储设备，例如所述服务器14上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器141还可以既包括所述服务器14的内部存储单元也包括外部存储设备。所述存储器141用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器141还可以用于暂时地存储已经输出或者将要输出的数据。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制。尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (7)

1.一种消息发送方法，其特征在于，应用于统一消息业务平台，所述方法包括：

接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息、消息模板和消息发送策略信息；

根据所述消息发送需求信息，生成多个待发送消息体，包括：从所述消息发送需求信息中，提取多个消息发送任务；根据所述多个消息发送任务和所述消息模板，生成多个待发送消息体；其中，每个消息发送任务对应不同的接收方；

根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列；其中，每个消息发送任务分别具有一种消息发送策略信息，所述消息发送策略信息包括至少一个消息发送渠道，每个消息发送渠道与一个消息发送队列关联，所述根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列，包括：根据所述消息发送策略信息，确定所述消息发送任务的消息发送渠道；将所述多个待发送消息体，分别提交至与所述消息发送渠道关联的消息发送队列；

通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送；其中，所述消息发送策略信息还包括消息发送方式，所述消息发送方式包括串行发送和/或并行发送，所述通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送，包括：根据所述消息发送任务的发送方式，为所述消息发送任务建立相应的发送节点，所述发送节点包括并行发送节点和/或串行发送节点；所述并行发送节点包括多个并行连接的消息发送渠道，所述串行发送节点包括多个串行连接的消息发送渠道；若所述消息发送任务的发送节点为并行发送节点，则通过所述多个并行连接的消息发送渠道同时对所述待发送消息体进行发送；若所述消息发送任务的发送节点为串行发送节点，则按照所述多个串行连接的消息发送渠道的连接顺序，依次对所述待发送消息体进行发送。

2.如权利要求1所述的方法，其特征在于，所述多个消息发送任务分别具有相应的消息发送参数和至少一个接收地址，所述根据所述多个消息发送任务和所述消息模板，生成多个待发送消息体，包括：

将所述消息发送参数组装到所述消息模板中，获得待发送的消息内容；

将所述待发送的消息内容分别与所述至少一个接收地址组合，得到待发送消息体。

3.如权利要求2所述的方法，其特征在于，在将所述消息发送参数组装到所述消息模板中，获得待发送的消息内容之后，还包括：

检测所述待发送的消息内容中是否包括预设的敏感词；

若所述待发送的消息内容中包括敏感词，则将所述敏感词对应的消息发送任务加入发送失败队列中；

若所述待发送的消息内容中不包括敏感词，则执行将所述待发送的消息内容分别与所述至少一个接收地址组合，得到待发送消息体的步骤。

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

若通过所述多个并行连接的消息发送渠道中任一消息发送渠道发送所述待发送消息体成功，则记录发送成功信息；否则将所述待发送消息体提交至所述并行发送节点的下一节点进行发送；

若通过所述多个串行连接的消息发送渠道中当前的消息发送渠道发送所述待发送消息体成功，则停止所述待发送消息体的发送，并记录发送成功信息；否则将所述待发送消息体提交至所述当前的消息发送渠道的下一消息发送渠道进行发送；当依次通过所述串行发送节点的全部消息发送渠道发送所述待发送消息体均失败时，将所述待发送消息体提交至所述串行发送节点的下一节点进行发送。

5.一种消息发送装置，其特征在于，应用于统一消息业务平台，所述装置包括：

接收模块，用于接收消息发送请求报文，所述消息发送请求报文中包括消息发送需求信息、消息模板和消息发送策略信息；

生成模块，用于根据所述消息发送需求信息，生成多个待发送消息体，包括：从所述消息发送需求信息中，提取多个消息发送任务；根据所述多个消息发送任务和所述消息模板，生成多个待发送消息体；其中，每个消息发送任务对应不同的接收方；

分发模块，用于根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列；其中，每个消息发送任务分别具有一种消息发送策略信息，所述消息发送策略信息包括至少一个消息发送渠道，每个消息发送渠道与一个消息发送队列关联，所述根据所述消息发送策略信息，将所述多个待发送消息体分发至对应的消息发送队列，包括：根据所述消息发送策略信息，确定所述消息发送任务的消息发送渠道；将所述多个待发送消息体，分别提交至与所述消息发送渠道关联的消息发送队列；

发送模块，用于通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送；其中，所述消息发送策略信息还包括消息发送方式，所述消息发送方式包括串行发送和/或并行发送，所述通过所述消息发送队列对应的发送渠道，对所述多个待发送消息体进行发送，包括：根据所述消息发送任务的发送方式，为所述消息发送任务建立相应的发送节点，所述发送节点包括并行发送节点和/或串行发送节点；所述并行发送节点包括多个并行连接的消息发送渠道，所述串行发送节点包括多个串行连接的消息发送渠道；若所述消息发送任务的发送节点为并行发送节点，则通过所述多个并行连接的消息发送渠道同时对所述待发送消息体进行发送；若所述消息发送任务的发送节点为串行发送节点，则按照所述多个串行连接的消息发送渠道的连接顺序，依次对所述待发送消息体进行发送。

6.一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至4任一项所述的方法。

7.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至4任一项所述的方法。

Images