消息推送方法、装置和设备与流程

1.本公开涉及消息推送技术领域，尤其涉及一种消息推送方法、装置和设备。


背景技术：

2.消息推送指企业运营人员通过自己的产品或第三方工具对用户移动设备进行的主动消息推送。用户可以在移动设备锁定屏幕和通知栏看到推送消息通知，点击推送消息通知即可唤起应用程序并去往相应页面，这样，便可以建立起企业与用户之间沟通和事项传达的桥梁。
3.消息推送的及时性、准确性、稳定性以及成功率是衡量消息推送性能的重要指标。目前，常用多线程的方式来提高消息推送及时性，但是在消息拥堵的情况下，仍会出现某种类型的消息大面积延迟的调度不均衡现象。


技术实现要素：

4.有鉴于此，本公开提出了一种消息推送方法、装置和设备可以实现对多种类型消息的均衡调度。
5.根据本公开的第一方面，提供了一种消息推送方法，包括：
6.获取消息推送请求，并根据所述消息推送请求生成包含有待推送消息的消息体；
7.根据所述消息体的消息类型，将所述消息体路由到对应的智能调度器；
8.通过所述智能调度器确定所述消息体的推送通道，并通过所述推送通道进行所述待推送消息的推送。
9.在一种可能的实现方式中，获取消息推送请求后还包括：对当前获取到的所述消息推送请求进行风险识别的处理步骤；
10.其中，在对当前获取的所述消息推送请求进行风险识别，确定当前获取到的所述消息推送请求为非风险请求时，再执行根据所述消息推送请求生成所述消息体的步骤。
11.在一种可能的实现方式中，在根据所述推送请求，生成所述待推送消息的对应的消息体时，包括：
12.提取所述推送请求中的消息模板标识以及消息类型标识；
13.基于所述消息模板标识获取与所述推送请求对应的消息模板，并基于所述消息模板生成所述待推送消息的消息内容；
14.基于所述消息类型标识获取与所述待推送消息对应的至少两个推送通道的通道数据；
15.基于所述消息内容和所述通道数据，生成所述待推送消息的对应的消息体。
16.在一种可能的实现方式中，在根据所述消息推送请求生成所述消息体后，还包括：
17.确定所述消息体的发送方式；
18.在确定所述消息体的发送方式为异步发送时，将所述消息体加入消息队列中，然后再按照所述消息队列的顺序将各所述消息体路由到对应的智能调度器。
19.在一种可能的实现方式中，在根据所述消息体的消息类型将所述消息体路由至所述智能调度器时，还包括：确定所述消息体是否满足预设的发送场景要求，并在确定所述消息体满足所述发送场景要求时，将所述消息体路由至所述智能调度器；
20.其中，所述发送场景要求用于表征消息体的发送场景的配置，不同消息类型的消息体对应不同的发送场景要求。
21.在一种可能的实现方式中，在将所述消息体路由到与所述消息类型对应的智能调度器时，基于与所述消息类型对应阻塞队列实现。
22.在一种可能的实现方式中，所述智能调度器在确定所述消息体的推送通道时，包括：
23.获取至少两个所述推送通道的通道配置和运行统计数据；
24.基于至少两个所述推送通道的所述通道数据、所述通道配置和所述运行统计数据，确定消息体的推送通道。
25.在一种可能的实现方式中，在通过所述推送通道进行所述待推送消息的推送之后，还包括：
26.获取所述待推送消息的推送回执；
27.根据所述推送回执判断所述待推送消息是否推送成功；
28.在所述待推送消息未推送成功的情况下，根据所述推送回执中的推送失败原因，重新确定所述消息体的推送通道。
29.根据本公开的第二方面，提供了一种消息推送装置，包括：
30.消息体生成模块，用于获取消息推送请求，并根据所述消息推送请求生成包含有待推送消息的消息体；
31.路由模块，用于根据所述消息体的消息类型，将所述消息体路由到对应的智能调度器；
32.智能调度模块，用于通过所述智能调度器确定所述消息体的推送通道，并通过所述推送通道进行所述待推送消息的推送。
33.根据本公开的第三方面，提供了一种消息推送设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为执行本公开第一方面所述的方法。
34.在本公开中，针对不同消息类型的消息体，分别设置有独立的智能调度器，在得到消息体后，将根据消息体的消息类型，将消息体路由到对应的智能调度器中进行消息体的推送调度，通过对不同消息类型的消息体进行独立推送调度，便可以实现对多种类型消息的均衡调度。
35.根据下面参考附图对示例性实施例的详细说明，本公开的其它特征及方面将变得清楚。
附图说明
36.包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本公开的示例性实施例、特征和方面，并且用于解释本公开的原理。
37.图1示出根据本公开一实施例的消息推送方法的示意性流程图；
38.图2示出根据本公开一实施例的消息推送方法示例的示意性流程图；
39.图3示出根据本公开一实施例的消息推送装置的示意性框图；
40.图4示出根据本公开一实施例的消息推送设备的示意性框图。
具体实施方式
41.以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。
42.在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。
43.另外，为了更好的说明本公开，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本公开同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本公开的主旨。
44.《方法实施例》
45.图1示出根据本公开一实施例的消息推送方法的示意性流程图。如图1所示，该方法包括步骤s1100-s1300。
46.s1100，获取消息推送请求，并根据消息推送请求生成包含有待推送消息的消息体。
47.在进行消息推送前，需要先将推送消息的应用通过api接口接入到消息推送系统中。该api接口是一套统一的抽象接口(例如，基于dubbo协议或者restful协议构建的api接口)，应用只需要以一种统一的编程的方式即可对接发送不同类型的消息，而无需因消息类型的不同而对接多个接口。在一种可能的实现方式中，该api接口可以集成接入应用发送的短信、语音电话、邮件和app消息中的至少一种类型的消息。在一种可能的实现方式中，该api接口还可以提供多种消息发送方式，以满足各种接入的需求。该消息发送方式可以包括同步发送、异步发送、单个发送、批量发送、动态发送和静态发送中的至少一种发送方式。
48.在一种可能的实现方式中，获取消息推送请求后还包括：对当前获取到的消息推送请求进行风险识别的处理步骤。
49.需要说明的是，在对消息推送请求进行风险识别之前，可以通过预设的管理界面进行风险识别规则的配置。其中，该风险识别规则可以包括测试流量识别规则、号码(如手机号、邮箱号和app设备id号等)黑白名单识别规则、消息轰炸识别规则、薅羊毛识别规则以及分布式网络机器人请求识别规则中的至少一种。这样，就可以根据配置的风险识别规则对当前获取的消息推送请求进行风险识别。
50.在一种可能的实现方式中，在根据配置的风险识别规则对当前获取的消息推送请求进行风险识别时，包括：在消息推送请求中提取风险识别规则中涉及的特征字段，并根据该特征字段的提取结果确定当前获取的消息推送请求是否存在风险。
51.例如，风险识别规则包括测试流量识别规则，该测试流量识别规则为：检测消息推送请求中是否包含“测试流量”特征字段。对于当前获取的消息推送请求，在消息推送请求中提取“测试流量”字段：在当前获取的消息推送请求中不包括“测试流量”字段时，表征该消息推送请求不是测试流量，即为非风险请求；在当前获取的消息推送请求中包括“测试流量”字段时，表征该消息推送请求为测试流量，即为风险请求。
52.又如，风险识别规则包括号码黑名单识别规则，该号码黑名单识别规则为：检测消息推送请求中“号码”特征字段的特征值是否在预设的黑名单内。对于当前获取的消息推送请求，在消息推送请求中提取“号码”特征字段的特征值，判断该特征值是否在预设的黑名单内：在属于黑名单时，表征当前获取的消息推送请求来自存在不可靠的应用，即为风险请求；在不属于黑名单时，表征当前获取的消息推送请求来自可靠的应用，即为非风险请求。
53.在一另种可能的实现方式中，在根据配置的风险识别规则对当前获取的消息推送请求进行风险识别时，包括：在消息推送请求中提取风险识别规则中涉及的特征字段以及在预设的算法模型中获取与该风险识别规则对应的算法模型，基于特征字段以及算法模型计算该消息推送请求的风险评分，并基于该风险评分确定当前获取的消息推送请求是否存在风险。
54.例如，风险识别规则包括分布式网络机器人请求识别规则，该分布式网络机器人请求识别规则为：预设时间窗内相同“号码”特征字段的消息推送请求流量是否超过设定流量阈值。与该分布式网络机器人请求识别规则对应的算法模型为相同特征时间窗流量计算算法模型。对于当前获取的消息推送请求，在消息推送请求中提取“号码”特征字段的特征值，基于相同特征时间窗流量计算算法模型计算预设时间窗内与当前消息推送请求中“号码”特征字段的特征值相同的流量值，判断该流量值是否超过设定流量阈值：在超过设定流量阈值时，表征当前获取的消息推送请求为分布式网络机器人发送的消息推送请求，即为风险请求；在小于等于设定流量阈值时，表征当前获取的消息推送请求不是分布式网络机器人发送的消息推送请求，即为非风险请求。其中，该设定流量阈值可以是10条/每天，即推送请求中“号码”特征字段的特征值相同的流量值超过10条/每天，则表征该推送请求为风险请求。
55.又如，风险识别规则包括分布式网络机器人请求识别规则，该分布式网络机器人请求识别规则为：预设时间窗内相同“号码”特征字段的消息推送请求对应的推送失败条数是否超过设定推送失败阈值。在进行风险识别时，若推送失败条数超过设定推送失败阈值，表征当前获取的消息推送请求为分布式网络机器人发送的消息推送请求，即为风险请求；若推送失败条数未超过设定推送失败阈值，表征当前获取的消息推送请求不是分布式网络机器人发送的消息推送请求，即为非风险请求。其中，该推送失败阈值可以是10条/5分钟，即5分钟内，相同“号码”特征字段的消息推送请求对应的推送失败条数超过10条，则表征当前接收到的推送请求为风险请求。
56.在该可实现方式中，风险识别规则以及风险识别规则对应的算法模型是可以根据具体的应用需求进行设置的，在本技术中不作具体限定。
57.得到当前获取到的消息推送请求的风险识别结果后，可以根据风险识别结果执行对应的操作。
58.在一种可能的实现方式中，在确定当前获取到的消息推送请求为非风险请求时，执行根据消息推送请求生成消息体的步骤。在确定当前获取到的消息推送请求为风险请求时，将该消息推送请求进行记录，并在监控和统计页面中展示出来，以便于运维人员对存在风险的消息推送请求进行及时处理。
59.在根据风险评分确定当前获取的消息推送请求是否存在风险的实施例中，还可以根据风险评分和预设的风险等级阈值确定消息推送请求的风险等级。该风险等级可以包括
严重风险和一般风险中的至少一种。在当前获取的消息推送请求为严重风险时，还可以通过语音电话的方式告知向运维人员，以使运维人员进行及时处理。
60.在一种可能的实现方式中，在根据推送请求，生成待推送消息的对应的消息体时，包括步骤s1110-s1140。
61.s1110，提取推送请求中的消息模板标识以及消息类型标识。
62.该消息模板标识用于唯一标识一种特定的消息模板。需要说明的是，在进行消息推送前，需要将待推送消息的消息模板以及对应的消息模板标识存储在数据库中，这样，在提取出消息推送请求中的消息模板标识后，便可以基于该消息模板标识在数据库中提取出对应的消息模板。
63.该消息类型标识用于唯一标识一种特定的消息类型。这样，在基于该消息类型标识生成对应的消息体后，就可以消息体中的消息类型标识确定消息体的消息类型。其中，该消息类型与api接口可以集成接入消息类型类型一致，在此不再赘述。
64.s1120，基于消息模板标识获取与推送请求对应的消息模板，并基于消息模板生成待推送消息的消息内容。
65.该消息模板可以是动态消息模板，也可以是静态消息模板，在此不作具体限定。该动态消息模板内容中包含变量。在获取与推送请求对应的消息模板为动态模板时，需要根据消息推送请求中的参数对动态消息模板内容中的变量进行替换，以动态地生成待推送消息的消息内容。该静态模板内容为固定内容。在获取与推送请求对应的消息模板为静态模板时，直接将静态模板的内容作为待推送消息的消息内容。
66.s1130，基于消息类型标识获取与待推送消息对应的至少两个推送通道的通道数据。
67.该推送通道是指可以实现对待推送消息进行推送的通道。该推送通道可以是消息推送系统自己实现的通道，也可以是购买的第三方通道服务，在此不作具体限定。
68.需要说明的时，在消息推送系统中，对于每种消息类型都配置了至少两种以上的推送通道，以确保消息推送的可靠性。在一种可能的实现方式中，在进行消息推送前，将消息类型标识与该消息类型对应的至少两种以上推送通道的通道数据以映射关系表的形式存储在数据库中，这样，在提取出消息类型标识的情况下，就可以在映射关系表中，获取到与待推送消息对应的至少两个推送通道的通道数据。其中，该通道数据可以包括通道标识、通道使用优先级以及通道使用单价中的至少一种。
69.s1140，基于消息内容和通道数据，生成待推送消息的对应的消息体。具体地，在获取到待推送消息的消息内容后，将待推送消息的通道数据增加至该消息内容中，以得到待待推送消息的对应的消息体。
70.在一种可能的实现方式中，在根据消息推送请求生成消息体后，还包括步骤s1150-s1160。
71.s1150，确定消息体的发送方式。
72.具体地，在消息推送请求中可以配置发送方式标识，以通过该发送方式标识来唯一标识消息体的发送方式。其中，该发送方式可以是同步发送也可以是异步发送。在消息推送请求中配置有发送方式标识的情况下，在根据消息推送请求生成的消息体中也包括该发送方式标识，这样，在得到消息体后，就可以通过消息体中的发送方式标识确定该消息体的
发送方式。
73.s1160，在确定消息体的发送方式为异步发送时，将消息体加入消息队列中，然后再按照消息队列的顺序将各消息体路由到对应的智能调度器。在确定消息体的发送方式为同步发送时，可以直接消息体路由到对应的智能调度器中。
74.在一种可能的实现方式中，在根据消息体的消息类型将消息体路由至智能调度器时，还包括：确定消息体是否满足预设的发送场景要求，并在确定消息体满足发送场景要求时，将消息体路由至智能调度器。该发送场景要求用于表征消息体的发送场景的配置。该发送场景要求可以根据具体的应用场景在设定的管理界面中进行配置，在此不对发送场景要求进行具体限定。例如，该发送场景要求可以是指定时间段禁止发送。又如，该发送场景要求可以是设定时间窗口内的重复消息体禁止发送。通过发送场景要求的配置，可以是消息推送满足各种消息推送场景的要求，以提高被推送用户的使用体验。
75.对于不同消息类型的消息体可以对应相同的发送场景要求，也可以对应不同的发送场景要求，在此不作具体限定。
76.在不同消息类型的消息体对应不同的发送场景要求的可实现方式中，对于语音电话类型的消息体，其对应的发送场景要求可以是指定时间段禁止发送。例如，在获取到语音电话类型的消息体后，先检测获取到该消息体的时间，再判断获取到该消息体的时间是否在晚上10点至早晨6点之间的指定时间段内，在位于该指定时间段的情况下，禁止将该消息体路由至智能调度器中，以防止夜间发送语音电话类型的消息，打扰用户休息。对于指定时间段禁发的消息体将暂存于数据库中，待过了禁发时间，再将该消息体路由至智能调度器中进行补发，以确保用户可以接收到禁发消息体对应的待推送消息。例如，对于晚上10点至早晨6点之间禁发的消息体，可以在次日早晨6点以后路由至智能调度器中进行补发。在另一种可能的实现方式中，对于时效性高的消息体，若禁发时间超过设定的时效阈值，则可以直接在数据库中删除该消息体，以减少存储资源的浪费。
77.在不同消息类型的消息体对应相同的发送场景要求的可实现方式中，任何消息类型的消息体，对应发送场景要求可以均为设定时间窗口内重复的消息体禁止发送。例如，在获取到消息体后，先判断该消息体是否与设定时间窗内发送过的消息体重复，在重复的情况下，禁止将该消息体路由至智能调度器中，在禁发后，可以直接将重复的消息体删除，以减少存储资源的浪费。
78.s1200，根据消息体的消息类型，将消息体路由到对应的智能调度器。
79.在本公开中，消息推送系统为每种消息类型的消息体配置了相互独立智能调度器，每个智能调度器对应有独立的线程池，以对不同类型消息体进行分别存储和调度，以确保不同类型的消息体可以均衡调度。
80.例如，在消息类型包括短信、语音电话、邮件和app消息的可实现方式中，在确定消息体的消息类型为短信时，将该消息体路由至第一线程池中，并由第一智能调度器进行推送调度。在确定消息体的消息类型为语音电话时，将该消息体路由至第二线程池中，并由第二智能调度器进行推送调度。在确定消息体的消息类型为邮件时，将该消息体路由至第三线程池中，并由第三智能调度器进行推送调度。在确定消息体的消息类型为app消息时，将该消息体路由至第四线程池中，并由第四智能调度器进行推送调度。其中，第一线程池、第二线程池、第三线程池以及第四线程池为相互独立的线程池。
81.在一种可能的实现方式中，在将消息体路由到与消息类型对应的智能调度器时，基于与消息类型对应阻塞队列实现。具体地，对于每种消息类型还设置有对应的阻塞队列，在将消息体路由到与消息类型对应的智能调度器时，先将消息体路由到与消息类型对应的阻塞队列中，阻塞队列判断与消息类型对应的智能调度器对应的线程池是否存在空闲线程：在存在空闲线程时，阻塞队列允许线程池从阻塞队列中拉取消息体至线程池中，以将消息体路由到与消息类型对应的智能调度器中。在不存在空闲线程时(即线程池满)，阻塞队列禁止线程池从阻塞队列中拉取消息体至线程池中，以通过阻塞队列的阻塞方式保护线程池、避免其过载导致cpu飙高和线程卡死的问题。
82.在一种可能的实现方式中，各线程池可以根据不同服务器cpu的配置和运行参数进行自适应调节，以实现资源感知的目的。在主机部署环境中，如果主机cpu配置高则线程池的核心线程数越多、并发能力就越强。在容器环境或虚拟化环境中，如果分配的资源越多则线程池的核心线程数越多、并发能力就越强。具体地，在线程池根据不同服务器cpu的配置和运行参数进行自适应调节时，包括步骤s1210-s1220。
83.s1210，获取服务器的配置和运行参数。其中，服务器的配置包括cpu的核心数，运行参数包括当前的cpu负载百分比和进程空闲内容大小(单位：mb)。
84.s1220，根据获取的服务器的配置和运行参数对线程池进行自适应调节。
85.例如，如果当前的cpu负载百分比《10％时，则将线程池的核心线程数设置为cpu核心数*2，最大线程数设置为进程空闲内存大小*80％后取整。如果当前的cpu负载百分比≧10％且《30％时，则将线程池的核心线程数设置为cpu核心数，最大线程数设置为进程空闲内存大小*80％后取整。如果当前的cpu负载百分比≧30％,则将线程池的核心线程数设置为cpu核心数/2后取整，最大线程数设置为进程空闲内存大小*80％后取整。
86.在一种可能的实现方式中，对于需要紧急推送的消息，可以在消息推送请求中标识优先级，在该可实现方式中，根据该消息推送请求生成的消息体中具有优先级标识，这样，在该消息体进入到线程池后，便可以对具有优先级标识的消息体进行有限调度推送，以确保重要的消息可以及时推送至用户，提高消息推送的时效性。
87.在一种可能的实现方式中，在消息体进入对应的线程池后，智能调度器先根据消息体中的目标用户变量列表中目标用户标识的数量判断该消息体是批量消息还是单体消息。具体地，在目标用户变量列表中的目标用户标识数量为1时，确定该消息体为单体消息，此时，可以直接对该消息体进行智能调度。在目标用户变量列表中的目标用户标识数量大于1时，确定该消息体为批量消息，此时，需要先将该消息体拆分成具体地单个消息体，再对单个消息体进行智能调度。这样，便可以实现对消息体的最小粒度的调度控制。
88.s1300，通过智能调度器确定消息体的推送通道，并通过推送通道进行待推送消息的推送。
89.在一种可能的实现方式中，智能调度器在确定消息体的推送通道时，包括步骤s1310-s1320。
90.s1310，获取至少两个推送通道的通道配置和运行统计数据。
91.该通道配置包括通道所属的厂商、配额和资费中的至少一种关键参数。该运行统计数据包括窗口发送总量、推送成功率、推送失败率、窗口平均发送时间、窗口平均接收延时以及通道可用状态中的至少一种参数。
92.s1320，基于至少两个推送通道的通道数据、通道配置和运行统计数据，确定消息体的推送通道。
93.在一种可能的实现方式中，消息体的推送通道数据包括通道标识，通道配置包括使用通道的资费，运行统计数据包括通道每小时的推送成功率和每小时窗口平均接收延时。例如，消息体的通道数据、通道配置数据和运行统计数据可以如表1所示。
94.表1
[0095][0096]
在该可实现方式中，在基于至少两个推送通道的通道数据、通道配置和运行统计数据，确定消息体的推送通道时，包括：分别计算任意两个通道每小时推送成功率的差值以及任意两个通道每小窗口平均接收延时的差值；在每小时推送成功率两两之差≧5％时，则确认推送成功率高的通道为消息体的推送通道。在每小窗口平均接收延时两两之差≧5秒时，则确定窗口平均接收延时最低的通道为消息体的推送通道。在每小时推送成功率两两之差《5％且每小窗口平均接收延时两两之差《5秒时，则确定资费最低的通道为消息体的推送通道。
[0097]
消息推送之后，并不能及时知道用户的接收状态，由于各种原因(如网络信号不好、欠费、用户转网、空号等)可能最终导致用户接收不到推送消息。通过厂商通道的回调和自己实现的通道回调来收集反映用户接收状态的推送回执，以通过推送回执进行推送统计和查询原因。智能调度器也需要用户的接收状态和接收耗时来判断某个通道的速率和质量，并为后继消息如何调度做决策依据。
[0098]
在一种可能的实现方式中，在通过推送通道进行待推送消息的推送之后，还包括：获取待推送消息的推送回执；根据推送回执判断待推送消息是否推送成功；在待推送消息未推送成功的情况下，根据推送回执中的推送失败原因，重新确定消息体的推送通道。
[0099]
例如，推送回执中的推送失败原因为通道原因，则切换通道重试发送。又如，推送回执中的推送失败原因为用户信号不好，则再原通道尝试重试，直到重试n次(例如，3次)后，如果仍然失败才触发切换通道，由另外可用的通道将消息发送出去。再如，当检测到某个通道故障时，则该通道会在可用通道列表中下线，消息会切换到其他可用通道中进行发送，从而实现自动的通道故障切换，极大程度的提高了消息发送的可靠性和稳定性。
[0100]
在本公开中，针对不同消息类型的消息体，分别设置有独立的智能调度器，在得到消息体后，将根据消息体的消息类型，将消息体路由到对应的智能调度器中进行消息体的推送调度，通过对不同消息类型的消息体进行独立推送调度，便可以实现对多种类型消息的均衡调度。
[0101]
《方法示例》
[0102]
图2示出根据本公开一实施例的消息推送方法示例的示意性流程图。如图2所示，
该方法包括以下步骤。
[0103]
第一，通过集成对接方式获取应用发送的短信、语音电话、邮件和app消息中的至少一种消息类型的消息推送请求。
[0104]
第二，根据配置的风险识别规则，对当前获取到的消息推送请求进行风险识别，并在确定该息推送请求为非风险请求时，根据该消息推送请求生成对应的消息体。
[0105]
第三，确定该消息体的发送方式，在该消息体的发送方式为同步发送时，直接执行第四步。在该消息体的发送方式为异步发送时，将消息体加入消息队列中，然后再按照消息队列的顺序将各消息体执行第四步。
[0106]
第四，确定消息体是否满足预设的发送场景要求，并在确定消息体满足发送场景要求时，根据消息体的消息类型将，其路由至对应的智能调度器中。
[0107]
第五，通过智能调度器由该消息类型对应的至少两个推送通道中选出最优的通道，并通过该最优推送通道进行待推送消息的推送。
[0108]
《装置实施例》
[0109]
图3示出根据本公开一实施例的消息推送装置的示意性框图。如图3所示，该消息推送装置100包括：
[0110]
消息体生成模块110，用于获取消息推送请求，并根据消息推送请求生成包含有待推送消息的消息体。
[0111]
路由模块120，用于根据消息体的消息类型，将消息体路由到对应的智能调度器。
[0112]
智能调度模块130，用于通过智能调度器确定消息体的推送通道，并通过推送通道进行待推送消息的推送。
[0113]
在一种可能的实现方式中，消息体生成模块110在获取消息推送请求后还用于：对当前获取到的消息推送请求进行风险识别的处理；
[0114]
其中，在对当前获取的消息推送请求进行风险识别，确定当前获取到的消息推送请求为非风险请求时，再执行根据消息推送请求生成消息体的步骤。
[0115]
在一种可能的实现方式中，消息体生成模块110在根据推送请求，生成待推送消息的对应的消息体时，具体用于：
[0116]
提取推送请求中的消息模板标识以及消息类型标识；
[0117]
基于消息模板标识获取与推送请求对应的消息模板，并基于消息模板生成待推送消息的消息内容；
[0118]
基于消息类型标识获取与待推送消息对应的至少两个推送通道的通道数据；
[0119]
基于消息内容和通道数据，生成待推送消息的对应的消息体。
[0120]
在一种可能的实现方式中，消息体生成模块110在根据消息推送请求生成消息体后，还用于：
[0121]
确定消息体的发送方式；
[0122]
在确定消息体的发送方式为异步发送时，将消息体加入消息队列中，然后再按照消息队列的顺序将各消息体路由到对应的智能调度器。
[0123]
在一种可能的实现方式中，路由模块120在根据消息体的消息类型将消息体路由至智能调度器时，还用于：确定消息体是否满足预设的发送场景要求，并在确定消息体满足发送场景要求时，将消息体路由至智能调度器；
[0124]
其中，发送场景要求用于表征消息体的发送场景的配置，不同消息类型的消息体对应不同的发送场景要求。
[0125]
在一种可能的实现方式中，路由模块120在将消息体路由到与消息类型对应的智能调度器时，基于与所述消息类型对应阻塞队列实现。
[0126]
在一种可能的实现方式中，智能调度模块130在智能调度器在确定消息体的推送通道时，具体用于：
[0127]
获取至少两个推送通道的通道配置和运行统计数据；
[0128]
基于至少两个推送通道的通道数据、通道配置和运行统计数据，确定消息体的推送通道。
[0129]
在一种可能的实现方式中，智能调度模块130在通过推送通道进行待推送消息的推送之后，还用于：
[0130]
获取待推送消息的推送回执；
[0131]
根据推送回执判断待推送消息是否推送成功；
[0132]
在待推送消息未推送成功的情况下，根据推送回执中的推送失败原因，重新确定消息体的推送通道。
[0133]
《设备实施例》
[0134]
图4示出根据本公开一实施例的消息推送设备的示意性框图。如图4所示，该消息推送设备200包括处理器210以及用于存储处理器210可执行指令的存储器220。其中，处理器210被配置为执行可执行指令时实现前面任一的消息推送方法。
[0135]
此处，应当指出的是，处理器210的个数可以为一个或多个。同时，在本公开实施例的消息推送设备200中，还可以包括输入装置230和输出装置240。其中，处理器210、存储器220、输入装置230和输出装置240之间可以通过总线连接，也可以通过其他方式连接，此处不进行具体限定。
[0136]
存储器220作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序和各种模块，如：本公开实施例的消息推送方法所对应的程序或模块。处理器210通过运行存储在存储器220中的软件程序或模块，从而执行消息推送设备200的各种功能应用及数据处理。
[0137]
输入装置230可用于接收输入的数字或信号。其中，信号可以为产生与设备/终端/服务器的用户设置以及功能控制有关的键信号。输出装置240可以包括显示屏等显示设备。
[0138]
以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。