信息的发送方法、装置、计算设备以及存储介质与流程

本申请涉及信息技术领域，尤其涉及一种信息的发送方法、装置、计算设备以及存储介质。

背景技术：

随着信息技术以及互联网的发展，越来越多的人们在线上进行活动，例如，观看视频、收听音乐等等，当用户在进行线上进行活动时，都需要通过客户端，如网页客户端，app等等，与对应的服务器进行信息交互，并通过该信息的交互实现用户的线上活动，为用户提供相应的活动内容，同时还会产生大量的活动消息，且处理这些大量的活动消息，需要耗费大量的成本，而如何处理这些大量的活动消息，更好地维持线上活动，是解决解决问题的关键。

技术实现要素：

本申请提出了以下技术方案，能够方便地处理大量消息，同时降低处理消息的成本。

本申请实例提出了一种信息的发送方法，所述方法包括：当主存储区域接收到表示媒体信息状态的消息时，从所述主存储区域中获取多个第一消息，所述消息携带媒体信息标识；根据所述第一消息的媒体信息标识确定第一消息的业务类型；根据所述业务类型，将所述多个第一消息存储至对应的业务存储区域；及从所述业务存储区域中获取多个第二消息，并根据所述第二消息的媒体信息标识，将多个第二消息发送至对应的业务服务器。

本申请实例还提出了一种信息的发送装置，所述装置包括：获取模块，当主存储区域接收到表示媒体信息状态的消息时，从所述主存储区域中获取多个第一消息，所述消息携带媒体信息标识；确定模块，根据所述第一消息的媒体信息标识确定第一消息的业务类型；存储模块，根据所述业务类型，将所述多个第一消息存储至对应的业务存储区域；及所述获取模块，从所述业务存储区域中获取多个第二消息，并根据所述第二消息的媒体信息标识，将多个第二消息发送至对应的业务服务器。

在一些实例中，所述获取模块，当从所述业务存储区域中获取多个第二消息后，将所述多个第二消息存储至备份存储区域；当重新启动后，获取所述备份存储区域中的所述多个第二消息；所述装置进一步包括：发送模块，根据所述第二消息的媒体信息标识，将多个第二消息发送至对应的业务服务器。

在一些实例中，所述获取模块，当从所述业务存储区域中获取多个第二消息后，向信息提供服务器发送表示媒体信息状态详情的获取请求，所述获取请求携带所述媒体信息标识；所述接收模块，接收所述信息提供服务器响应于所述获取请求发送的媒体信息状态详情；所述发送模块，根据所述第二消息的媒体信息标识，将所述媒体信息状态详情发送至对应的业务服务器。

在一些实例中，所述表示媒体信息状态的消息还携带媒体信息状态详情。

在一些实例中，所述存储模块，当确定所述第二消息发送失败时，将发送失败的所述第二消息存储至所述主存储区域中；所述装置进一步包括：删除模块，从所述备份存储区域中删除所述发送失败的所述第二消息。

在一些实例中，所述确定模块，当确定所述第二消息发送失败时，确定所述第二消息发送失败的次数；所述装置进一步包括：停止模块，当所述次数达到阈值时，则停止发送所述第二消息，并执行所述从所述备份存储区域中删除所述发送失败的所述第二消息的步骤。

在一些实例中，所述删除模块，当接收到表示所述第二消息发送成功的消息时，删除所述备份存储区域中的所述第二消息。

在一些实例中，所述发送模块，当确定所述第二消息发送失败时，将表示所述第二消息发送失败的消息发送至告警系统，以使所述告警系统对相应的业务方进行告警。

在一些实例中，所述主存储区域、业务存储区域以及备份存储区域设置在redis存储系统中。

在一些实例中，所述确定模块，当接收到表示所述第二消息发送成功的消息时，确定所述业务服务器接收所述第二消息的响应时间，将所述响应时间发送至告警系统，以使所述告警系统根据响应时间对业务方进行告警。

在一些实例中，所述获取模块，通过回调所述业务服务器的通用网络接口向对应的业务服务器发送第二消息。

在一些实例中，所述获取模块，从所述业务存储区域中获取多个第二消息后，获取发送设备的性能信息；所述发送模块，根据所述性能信息，选择发送设备发送所述第二消息。

本申请实例还提出了一种计算设备，包括存储器、处理器以及存储在所述存储器上并在所述处理器上运行的计算机程序；所述处理器执行所述计算机程序时实现上述的方法。

本申请实例还提出了一种存储介质，存储有一个或多个程序，所述一个或多个程序包括指令，所述指令当由计算设备执行时，使得所述计算设备执行上述的方法。

应用本发明的技术方案，能够方便且高效地处理大量消息，同时大大降低了处理消息的成本，且根据所述业务类型，将所述多个第一消息存储至对应的业务存储区域，将不同的业务消息进行隔离，防止不同业务消息之间的影响，如，由于一个业务消息的挤压，导致其他业务消息无法发送，从而提高消息的发送效率。

附图说明

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

图1为本申请一个实例的信息的发送方法适用的系统结构示意图；

图2为本申请一个实例的信息的发送方法的流程图；

图3为本申请一个实例的信息的发送应用构架图；

图4为本申请一个实例的信息的发送方法的处理流程图；

图5为本申请一个实例的消息备份的处理流程图；

图6为本申请一个实例中的接口配置的管理界面图；

图7为本申请一个实例的信息的发送装置的结构示意图；

图8为本申请一个实例的计算设备的硬件的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了描述上的简洁和直观，下文通过描述若干代表性的实施例来对本发明的方案进行阐述。实施例中大量的细节仅用于帮助理解本发明的方案。但是很明显，本发明的技术方案实现时可以不局限于这些细节。为了避免不必要地模糊了本发明的方案，一些实施方式没有进行细致地描述，而是仅给出了框架。下文中，“包括”是指“包括但不限于”，“根据……”是指“至少根据……，但不限于仅根据……”。下文中没有特别指出一个成分的数量时，意味着该成分可以是一个也可以是多个，或可理解为至少一个。

图1示出了本申请实例的信息的发送方法适用的系统100结构示意图。该系统100至少包括第一服务器101、第二服务器102、第三服务器103、第四服务器104以及网络105；此外，该系统还可以包括消息存储系统，如，redis存储系统，用于存储消息。

其中，第一服务器101是指具有数据计算处理功能的设备，可以为提供视频服务的设备，如视频服务器，该服务器安装了能够提供视频服务器软件，其中，该视频服务可以包括但不限于视频的上传、转码以及播放等业务，此外，该第一服务器101可以由视频服务器集群代替，该视频服务器集群中的服务器可以分别用于接收上传视频、转码视频以及存储转码后的视频。

第二服务器102是指具有数据计算处理功能的设备，可以为提供消息的处理服务的设备，如消息处理服务器，该服务器安装了消息处理的服务器软件。此外，该第二服务器102还可以通过多个服务器集群代替，该多个服务器集群分别安装了消息处理的服务器软件，实现提供消息的处理服务。

第三服务器103是指具有数据计算处理功能的设备，可以为提供消息发送服务的设备，如消息发送服务器，该服务器安装了能够发送消息的软件，此外，该第三服务器103也可以为终端设备，如pc终端，该终端设备安装有操作系统以及在操作系统上运行的消息发送软件。

第四服务器104是指具有数据计算处理功能的设备，可以为提供业务服务的设备，如社交业务服务器，该服务器安装了能够提供业务服务的软件。

第四服务器104可以通过网络105向第一服务器101上传原始视频，当第一服务器101接收到该原始视频后，需要对该原始视频进行转码操作，当该原始视频的转码操作成功后，即第一服务器101该确定原始视频的状态已改变，当前原始视频状态为“转码成功”，第一服务器101通过网络105将该转码成功的消息发送消息存储系统的主存储区域中，第二服务器102从该消息存储系统的主存储区域中获取这些存储的消息，并通过业务类型将消息存储在消息存储系统不同业务存储区域中，第二服务器102通过网络105将消息发送至第三服务器103，由第三服务器103通过网络105发送至第四服务器104，以告知第四服务器104该原始视频的当前视频状态。

网络105可以是有线网络，也可以是无线网络。

基于系统100，本申请的实例提出了一种信息的发送方法，应用于服务器，如消息服务器或消息系统(消息系统可以是由多个服务器组成的集群)。结合图2以及图4进行说明，其中，该方法200包括以下步骤：

步骤201：当主存储区域接收到表示媒体信息状态的消息时，从所述主存储区域中获取多个第一消息，所述消息携带媒体信息标识，还可以携带消息标识。

其中，媒体信息可以但不限于为：视频等。

媒体信息状态可以但不限于为：视频转码成功、视频转码不成功、视频人工审核通过、视频人工审核不通过等。

消息标识可以但不限于为：消息id，如001。

媒体信息标识可以但不限于为：视频id，如001。

主存储区域可以但不限于为：主队列。

例如，根据前文所述，视频服务器可以与为多个业务服务器(即第四服务器104)提供了视频服务，如，视频上传、视频转码以及视频播放等，当视频服务器为微信公众号业务服务器提供了视频上传接口，该微信公众号业务服务器通过该视频上传接口将原始视频上传至视频服务器或视频服务器集群，视频服务器可以通过其中的转码模块将该原始视频进行转码，或者视频服务器集群也可以通过其中的转码服务器将该原始视频进行转码，当转码成功后，如图4所示，步骤401：视频服务器可以通过其中的消息发送模块利用lpush命令将该视频转码成功的消息(如，视频id“001”的转码成功的消息“001”)发送或插入或存储至redis存储系统中的主队列中，或者视频服务器集群可以通过其中的消息发送服务器利用lpush命令发送该视频转码成功的消息至redis存储系统中的主队列中；当消息系统或消息服务器检测到该redis存储系统中的主队列存在待分发的消息时(如，可以定时从该redis存储系统中的主队列获取该待分发的消息，来检测当前主队列是否存在该消息)，当检测到该主队列中存在该消息时，步骤402：该消息系统或消息服务器的分发(dispatch)进程利用rpoplpush命令从主队列提取排在队列前的批量消息(即批量第一消息，如，主队列中的前80个消息)。更具体的方式可以为，通过该分发线程的各个子进程利用rpoplpush命令从主队列提取排在队列前的批量消息，即每个子进程均可以独自实现从主队列中提取消息功能。其中，图3示出了消息系统或消息服务器应用构架图，其中，视频服务侧301允许其他业务侧接入视频服务，并为其他业务侧提供视频的上传、转码和播放等服务。在业务侧上传视频至视频服务侧301后，需要知道视频的状态变更情况，当视频的状态变更后，视频服务侧301将视频的状态变更消息通过消息系统302发送至业务侧接口303。

在一些实例中，所述表示媒体信息状态的消息还携带媒体信息状态详情。

其中，媒体信息状态详情可以包括但不限于：视频转码详情、视频人工审核详情以及视频文件列表等，其中，视频转码详情可以为视频转码时间、视频转码率等，视频人工审核详情可以为视频人工审核时间等。

当表示媒体信息状态的消息还携带媒体信息状态详情时，可以使得业务侧接收到该媒体信息更为详尽的信息，以使得业务侧能够了解当前媒体信息的状况，为业务侧提供更好的服务。

应理解，当上述消息还携带媒体信息状态详情时，视频服务器除了将媒体信息状态、媒体信息标识以及消息标识存储至主存储区域，还将媒体信息状态对应的状态详情存储至主存储区域。

需要说明的是，上述分发进程是该消息系统或消息服务器在初始化后启动的进程。

上述lpush以及rpolpush为redis存储系统命令。

主队列中可以存储有多个消息，并且以消息的存储时间由先到后的顺序进行排序，提取消息的时候，也是按照消息先进先出的原则进行提取。

步骤202：根据所述第一消息的媒体信息标识确定第一消息的业务类型。

其中，业务类型可以但不限于为：公众号视频业务、手机qq视频等。

例如，根据前文所述，消息系统302或消息服务器根据提取到的批量消息中一个消息携带的视频标识，如“001”，根据查找该消息标识与业务类型的对应关系，确定该消息标识对应的业务类型，如“公众号”业务类型。

应理解，消息系统302或消息服务器中应已存储有关于媒体信息标识与业务类型的对应关系，如对应关系表，或者一个数据库(可以与视频服务侧301以及消息系统302有通信关系的数据库)中已存储有关于媒体信息标识与业务类型的对应关系，如对应关系表，消息系统302或消息服务器根据该媒体信息标识在对应关系表中查找该媒体信息标识对应的业务类型。该对应关系应根据视频服务侧301的服务进行数据更新。

需要说明的是，除了根据该媒体信息标识去确定业务类型，还可以根据消息标识去确定业务类型，也就是说，消息标识与业务类型存在对应关系，此时，消息系统302或消息服务器可以已存储有消息标识与业务类型的对应关系，或一个数据库(可以与视频服务侧301以及消息系统302有通信关系的数据库)可以已存储有消息标识与业务类型的对应关系，从而实现消息系统302或消息服务器根据该消息标识确定对应的业务类型。

步骤203：根据所述业务类型，将所述多个第一消息存储至对应的业务存储区域。

其中，业务存储区域可以但不限于为：业务队列。

例如，根据前文所述，步骤402：消息系统302或消息服务器的分发(dispatch)进程利用rpoplpush命令从主队列提取批量消息，并根据各个消息对应的业务类型存储至对应的业务队列，如，携带有媒体信息标识001的消息对应公众号业务类型，则将携带有媒体信息标识001的消息存储至公众号业务队列中，该公众号业务队列也可以具有自己的标识，如业务队列1，从而实现将批量消息分别存储至对应的业务队列中。

需要说明的是，该redis存储系统中可以存在多个业务队列，且一个业务队列中可以存储多个相同业务的消息，以消息的存储时间由先到后的顺序进行排序。

为了防止不同业务之间有影响(比如由于其中一个业务消息积压，影响其他业务消息的发送)，消息系统302或消息服务器通过二次分发将消息分发到业务队列中，来支持不同业务消息的隔离。另外，不管从主队列还是业务队列中提取消息，都是批量获取消息，再并行将该批量消息发送出去，这样能够降低消息发送时延。

步骤204：从所述业务存储区域中获取多个第二消息，并根据所述第二消息的媒体信息标识，将多个第二消息发送至对应的业务服务器。

其中，第二消息可以与第一消息相同，也可以与第一消息不同，还可以与第一消息部分相同。

在一些实例中，所述将多个第二消息发送至对应的业务服务器，包括：通过回调所述业务服务器的通用网络接口(即cgi接口)向对应的业务服务器发送第二消息。

例如，根据前文所述，步骤403：消息系统302或消息服务器的发送(send)进程利用rpoplpush命令从业务队列中提取批量消息(即第二消息，如，80个消息)，并根据第二消息携带的视频标识，如“001”，根据查找该媒体信息标识与业务服务器的对应关系，确定该媒体信息标识对应的业务服务器(即对应的cgi接口)，如“yy公众号”业务服务器，步骤405：回调该业务服务器的cgi接口，并根据回调的该cgi接口，以http通信的方式，通过发送设备(如，web服务器)将该第二消息发送至对应的业务服务器，从而告知业务方其上传的视频的状态，若该第二消息还携带有视频状态详情，如视频转码率，则业务方还可以知道当前视频的转码率。

需要说明的是，提取业务队列中的批量消息时，可以从一个业务队列中提取批量消息，也可以从多个业务队列中提取多个消息，组成批量消息，无论提取哪个业务队列中的消息，都需要按照消息先进先出的原则进行消息提取。

上述发送进程是该消息系统或消息服务器在初始化后启动的进程，该发送进程可以通过其各个子进程利用rpoplpush命令从业务队列提取排在队列前的批量消息，即每个子进程均可以独自实现从业务队列中提取消息功能。

消息系统302或消息服务器中应已存储有关于媒体信息标识与业务服务器的对应关系，如对应关系表，或者一个数据库(可以与视频服务侧301以及消息系统302有通信关系的数据库)中已存储有关于媒体信息标识与业务服务器的对应关系，如对应关系表，消息系统302或消息服务器根据该媒体信息标识在对应关系表中查找该媒体信息标识对应的业务服务器。该对应关系应根据视频服务侧301的服务进行数据更新。

需要说明的是，除了根据该媒体信息标识去确定业务服务器，还可以根据消息标识去确定业务服务器，也就是说，消息标识与业务服务器存在对应关系，此时，消息系统302或消息服务器可以已存储有消息标识与业务服务器的对应关系，或一个数据库(可以与视频服务侧301以及消息系统302有通信关系的数据库)可以已存储有消息标识与业务服务器的对应关系，从而实现消息系统302或消息服务器根据该消息标识确定对应的业务服务器；同时，每个业务服务器对应一个回调cgi接口，即业务服务器与回调cgi接口存在关联关系或对应关系，确定了该业务服务器，即确定了回调cgi接口，从而实现消息发送。

此外，cgi接口符合制定的http协议，包括接收参数以及返回值。cgi接口的接收参数是预置好的，是要发送给业务侧的消息字段。各个业务侧提供的回调cgi接口，可以通过配置管理系统管理，并做动态下发。其中，图6示出了管理界面600，该管理界面600中展示了回调cgi接口的id601，如“65”，回调cgi接口的名称602，如“zkname：//ving_idc.webde……vidstatus”，消息类型603以及回调cgi接口重试次数604，该消息类型603可以为视频基本信息，可以为视频状态以及视频状态详情等，回调cgi接口重试次数604可以为3次。采用回调cgi接口方式通知业务侧消息，大大降低业务侧接入消息系统302的成本。

在一些实例中，所述方法200进一步包括：当从所述业务存储区域中获取多个第二消息后，将所述多个第二消息存储至备份存储区域；当重新启动后，获取所述备份存储区域中的所述多个第二消息；及根据所述第二消息的标识，将多个第二消息发送至对应的业务服务器。

其中，备份存储区域可以但不限于为：备份队列。

例如，根据前文所述，如图5所示，步骤501：当消息系统302或消息服务器的发送(send)进程利用rpoplpush命令从业务队列中提取批量消息后，将提取到的该批量消息存储至备份队列中，当消息系统302或消息服务器重启后或初始化后，发送(send)进程利用rpoplpush命令从备份队列中提取批量消息，并根据该批量消息的消息标识，将该批量消息通过回调cgi的方式发送至对应的业务服务器，由于该发送方式在前文中已经详细的阐述过了，此处就不再赘述。此外，当实现该方法200的部分乃至全部服务重启后或中途退出并再创建后，或部分乃至全部进程重启后或中途退出并再创建后，发送(send)进程利用rpoplpush命令从备份队列中提取批量消息，并根据该批量消息的消息标识，将该批量消息通过回调cgi的方式发送至对应的业务服务器，由于该发送方式在前文中已经详细的阐述过了，此处就不再赘述。

需要说明的是，该备份队列中可以存储有多个消息，并且以消息的存储时间由先到后的顺序进行排序，提取消息的时候，也是按照消息先进先出的原则进行提取。

除了可以根据上述方式，在从业务队列中提取到批量消息后，将该批量消息存储至备份队列，还可以在从主队列中提取到批量消息后，将该批量消息存储至备份队列，那么在从业务队列中提取到批量消息后，就无需再将该批量消息存储到备份队列中，从而也可以保证消息不丢失。当发送进程利用rpoplpush命令支持从业务队列提取到消息后，备份消息到备份队列时的这个操作是原子性的。当实现该方法200的部分乃至全部服务重启后或中途退出并再创建后，或部分乃至全部进程重启后或中途退出并再创建后，会优先从备份队列中提取消息，将消息重新发送，保证消息不会丢失。

在一些实例中，所述方法200进一步包括：当确定所述第二消息发送失败时，将发送失败的所述第二消息存储至所述主存储区域中；及从所述备份存储区域中删除所述发送失败的所述第二消息。

例如，根据前文所述，当消息系统302或消息服务器接收到对应的业务服务器发送的一个第二消息发送失败的消息时，确定该第二消息发送失败，或者，当消息系统302或消息服务器在阈值时间(如，5分钟)内未收到对应的业务服务器返回的响应消息，则确定该第二消息发送失败，则确定发送失败的该第二消息的标识，如001，则消息系统302或消息服务器的发送进程可以将从备份队列中获取该第二消息，并存储至主队列中，以等待下一次的发送，同时删除该备份队列中的该第二消息，以防止重发。

需要说明的是，当确定第二消息发送失败时，该第二消息的来源可以是由于重新启动后，从备份存储区域中获取到的，也可以是直接从业务存储区域中提取到的，无论该第二消息的来源是哪里，都可以根据上述方案在该第二消息发送失败的前提下，将该第二消息存储至所述主存储区域中；及从所述备份存储区域中删除所述发送失败的所述第二消息。

当第二消息存储至所述主存储区域后，为了避免由于重新启动导致的首先从备份存储区域中获取该第二消息进行发送而造成的动作冗余的问题，需要从所述备份存储区域中删除所述发送失败的该第二消息。

在一些实例中，所述方法200进一步包括：当确定所述第二消息发送失败时，确定所述第二消息发送失败的次数；当所述次数达到阈值时，则停止发送所述第二消息，并执行所述从所述备份存储区域中删除所述发送失败的所述第二消息的步骤。

例如，根据前文所述，当消息系统302或消息服务器接收到对应的业务服务器发送的一个第二消息发送失败的消息时，确定该第二消息发送失败，或者，当消息系统302或消息服务器在阈值时间(如，5分钟)内未收到对应的业务服务器返回的响应消息，则确定该第二消息发送失败，当确定该第二消息发送失败后，确定其失败次数，若失败次数大于阈值(如，三次)则停止发送该第二消息，即不再将该第二消息存储至主队列，且将该备份队列中的该第二消息删除，避免重新发送。

需要说明的是，当确定第二消息发送失败时，该第二消息的来源可以是由于重新启动后，从备份存储区域中获取到的，也可以是直接从业务存储区域中提取到的，无论该第二消息的来源是哪里，都可以根据上述方案在该第二消息发送失败的前提下，确定所述第二消息发送失败的次数；当所述次数达到阈值时，则停止发送所述第二消息，并执行所述从所述备份存储区域中删除所述发送失败的所述第二消息的步骤。

当该第二消息发送了一定次数仍没有发送出去，为了节省时间以及提高其他消息发送的效率，释放该第二消息所占用的存储空间以及提高系统性能，将停止发送该第二消息。

在一些实例中，上述主存储区域、业务存储区域以及备份存储区域设置在redis存储系统中。

基于redis存储系统的消息队列做消息存储，而在redis存储系统中插入消息和获取消息只需要通过lpush或rpoplpush等redis存储系统命令就可以实现，其操作轻量，并且保证消息不会丢失

在一些实例中，所述方法200进一步包括：当接收到表示所述第二消息发送成功的消息时，确定所述业务服务器接收所述第二消息的响应时间，将所述响应时间发送至告警系统，以使所述告警系统根据响应时间对业务方进行告警。

例如，根据前文所述，当消息系统302或消息服务器接收到对应的业务服务器响应于该接收到的第二消息返回的响应消息，该响应消息可以表示为接收到该第二消息，则第二消息发送成功，此时，消息系统302或消息服务器对该业务服务器响应时间进行确定，并将响应时间发送至告警系统，该响应时间可以以消息的形式进行发送，且该消息还可以携带该响应时间对应响应的业务服务器信息、视频标识或能够表示该业务方的信息，告警系统可以用于判断该响应时间是否超出了正常响应阈值时间，若超出了正常响应阈值时间，则由告警系统可以根据该业务服务器信息，如业务服务器访问地址，确定该业务服务器对应或绑定的业务方的联系方式，如邮件联系方式、微信联系方式、短信联系方式等等，向对应的业务方发送告警信息，该告警信息可以表示为接收消息的响应时间过长的提示信息，以使得该业务侧的相关人员根据该提示信息对该业务服务器进行调试与维护。

需要说明的是，当确定第二消息发送成功时，该第二消息的来源可以是由于重新启动后，从备份存储区域中获取到的，也可以是直接从业务存储区域中提取到的，无论该第二消息的来源是哪里，都可以根据上述方案在该第二消息发送成功的前提下，确定所述业务服务器接收所述第二消息的响应时间，将所述响应时间发送至告警系统，以使所述告警系统根据响应时间对业务方进行告警。

该告警系统可以由至少一个服务器组成，用于向对应的业务服务器进行报警；当消息系统302或消息服务器确定了响应时间后，还可以直接对该响应时间是否超时进行判断，若该响应时间超时，即超出正常响应阈值时间，则将该响应时间发送至报警系统，若该响应时间未超时，则不将该响应时间发送至报警系统。

在一些实例中，所述方法200进一步包括：当接收到表示所述第二消息发送成功的消息时，删除所述备份存储区域中的所述第二消息。

例如，根据前文所述，当消息系统302或消息服务器接收到对应的业务服务器响应于该接收到的第二消息返回的响应消息，该响应消息可以表示为接收到该第二消息，则第二消息发送成功，删除备份列队中的该第二消息，以避免消息的重复发送。

需要说明的是，当确定第二消息发送失败时，该第二消息的来源可以是由于重新启动后，从备份存储区域中获取到的，也可以是直接从业务存储区域中提取到的，无论该第二消息的来源是哪里，都可以根据上述方案在该第二消息发送成功的前提下，删除所述备份存储区域中的所述第二消息。

在一些实例中，所述方法200进一步包括：当确定所述第二消息发送失败时，将表示所述第二消息发送失败的消息发送至告警系统，以使所述告警系统对相应的业务方进行告警。

例如，根据前文所述，当消息系统302或消息服务器根据上述方式确定该第二消息发送失败后，则将表示所述第二消息发送失败的消息发送至告警系统，该消息可以携带视频标识或者该视频标识对应的业务服务器信息或能够表示该业务方的信息，当告警系统接收到该消息后，可以根据该业务服务器信息，如业务服务器访问地址，确定该业务服务器对应或绑定的业务方的联系方式，如邮件联系方式、微信联系方式、短信联系方式等等，向对应的业务方发送告警信息，该告警信息可以表示为接收消息的响应时间过长的提示信息，以使得该业务侧的相关人员根据该提示信息对该业务服务器进行调试与维护。

需要说明的是，当确定第二消息发送失败时，该第二消息的来源可以是由于重新启动后，从备份存储区域中获取到的，也可以是直接从业务存储区域中提取到的，无论该第二消息的来源是哪里，都可以根据上述方案在该第二消息发送失败的前提下，将表示所述第二消息发送失败的消息发送至告警系统，以使所述告警系统对相应的业务方进行告警。

在一些实例中，所述方法200进一步包括：当从所述业务存储区域中获取多个第二消息后，向信息提供服务器发送表示媒体信息状态详情的获取请求，所述获取请求携带所述媒体信息标识；接收所述信息提供服务器响应于所述获取请求发送的媒体信息状态详情；及根据所述第二消息的标识，将所述媒体信息状态详情发送至对应的业务服务器。

例如，根据前文所述，当表示媒体信息状态的消息未携带媒体信息状态详情，只携带了媒体信息状态时，则消息系统302或消息服务器从业务队列中提取了批量消息后，步骤404：从信息提供服务器获取视频状态详情，如向信息提供服务器，如视频信息服务器，发送表示视频状态详情的获取请求，该获取请求携带视频id，并接收该信息提供服务器响应于该获取请求发送的视频状态详情，如视频转码率，然后将该视频状态详情伴随对应的第二消息发送至对应业务服务器，由于发送方式在前文中已经详细阐述过了，此处就不再赘述。

在一些实例中，所述方法200进一步包括：从所述业务存储区域中获取多个第二消息后，获取发送设备的性能信息；及根据所述性能信息，选择发送设备发送所述第二消息。

例如，根据前文所述，消息系统302或消息服务器从业务队列中提取了批量消息后，获取各个发送设备(如，web服务器)的性能信息，如cpu使用率、内存使用率、io消耗率等，根据该性能信息，确定发送设备的请求成功率以及请求延时，选择请求成功率高以及请求延时低的发送设备发送消息，以使得发送设备的负载均衡，保证业务侧消息接收的稳定性。

需要说明的是，上述实例可以通过l5组件(可以包括名字服务以及负载均衡的功能)实现获取发送设备的性能信息，并根据性能信息选择发送设备发送第二消息的步骤。

本消息系统可以支持80多个不同的业务，消息系统在单台c1机器(1个4核cpu，16g内存，1*500gsata)运行可支持5000/秒的消息量处理。

本技术方案提供了将上述消息落地到redis存储系统中的消息队列(即主队列)中，再由消息系统302或消息服务器利用redis存储系统的rpoplpush命令从该消息队列中提取批量消息，并将该提取到的批量消息同时发送，从而保证消息不管是处理失败，还是消息系统302或消息服务器重启后，都不会丢失要发送的消息。另外，消息系统302或消息服务器还包括消息重传、支持cgi接口负载均衡以及消息失败监控告警等功能。同时消息系统302或消息服务器具有高处理性能，其部署上支持水平扩展。消息系统302或消息服务器可用于解耦业务消息通知流程，降低业务侧接入消息通知的成本，设计简单且易于理解。

而现有的消息中转系统，比如hippo、kafka等，都是高可用的消息系统。虽然支持的功能丰富，但是使用较繁杂，搭建整套消息系统的成本也很高。重点是，业务侧接入方式成本高，需要业务侧了解消息接出方式，自行开发消息接出程序。同时消息的发送失败处理以及监控告警，业务侧要自己保证。整体使用来说，不够轻量。

此外，基于回调接口方式来通知消息的方案还没有见到类似的。虽然上述hippo或kafka都可以实现对消息进行落地，但缺点很多，比如采用hippo或kafka做消息中转，这种方式的部署以及维护的负担要比采用redis存储系统做消息存储的方式的部署以及维护的负担要重；此外，采用disque做消息中转，但是目前版本还不够成熟，而且基于disque做回调接口方式通知消息，没有比采用rpoplpush操作消息队列更轻量。

基于上述实例，本申请的实例还提出了一种信息的发送装置，应用于服务器，如消息服务器或消息系统(消息系统可以是由多个服务器组成的集群)；如图7所示，所述装置700包括：获取模块701、确定模块702以及存储模块703：且各个模块的功能具体如下：

获取模块701，当主存储区域接收到表示媒体信息状态的消息时，从所述主存储区域中获取多个第一消息，所述消息携带媒体信息标识。

确定模块702，根据所述第一消息的媒体信息标识确定第一消息的业务类型。

存储模块703，根据所述业务类型，将所述多个第一消息存储至对应的业务存储区域。

所述获取模块701，从所述业务存储区域中获取多个第二消息，并根据所述第二消息的媒体信息标识，将多个第二消息发送至对应的业务服务器。

在一些实例中，所述获取模块701，当从所述业务存储区域中获取多个第二消息后，将所述多个第二消息存储至备份存储区域；当重新启动后，获取所述备份存储区域中的所述多个第二消息；所述装置700进一步包括：发送模块，根据所述第二消息的媒体信息标识，将多个第二消息发送至对应的业务服务器。

在一些实例中，所述获取模块701，当从所述业务存储区域中获取多个第二消息后，向信息提供服务器发送表示媒体信息状态详情的获取请求，所述获取请求携带所述媒体信息标识；所述接收模块，接收所述信息提供服务器响应于所述获取请求发送的媒体信息状态详情；所述发送模块，根据所述第二消息的媒体信息标识，将所述媒体信息状态详情发送至对应的业务服务器。

在一些实例中，所述表示媒体信息状态的消息还携带媒体信息状态详情。

在一些实例中，所述存储模块703，当确定所述第二消息发送失败时，将发送失败的所述第二消息存储至所述主存储区域中；所述装置700进一步包括：删除模块，从所述备份存储区域中删除所述发送失败的所述第二消息。

在一些实例中，所述确定模块702，当确定所述第二消息发送失败时，确定所述第二消息发送失败的次数；所述装置700进一步包括：停止模块，当所述次数达到阈值时，则停止发送所述第二消息，并执行所述从所述备份存储区域中删除所述发送失败的所述第二消息的步骤。

在一些实例中，所述删除模块，当接收到表示所述第二消息发送成功的消息时，删除所述备份存储区域中的所述第二消息。

在一些实例中，所述发送模块，当确定所述第二消息发送失败时，将表示所述第二消息发送失败的消息发送至告警系统，以使所述告警系统对相应的业务方进行告警。

在一些实例中，所述主存储区域、业务存储区域以及备份存储区域设置在redis存储系统中。

在一些实例中，所述确定模块702，当接收到表示所述第二消息发送成功的消息时，确定所述业务服务器接收所述第二消息的响应时间，将所述响应时间发送至告警系统，以使所述告警系统根据响应时间对业务方进行告警。

在一些实例中，所述获取模块701，通过回调所述业务服务器的通用网络接口向对应的业务服务器发送第二消息。

在一些实例中，所述获取模块701，从所述业务存储区域中获取多个第二消息后，获取发送设备的性能信息；所述发送模块，根据所述性能信息，选择发送设备发送所述第二消息。

图8示出了发送装置700所在的计算设备800的组成结构图。此计算设备800可以是服务器。如图8所示，该计算设备包括一个或者多个处理器(cpu)802、通信模块804、存储器806、用户接口810，以及用于互联这些组件的通信总线808。

处理器802可通过通信模块804接收和发送数据以实现网络通信和/或本地通信。

用户接口810包括一个或多个输出设备812，其包括一个或多个扬声器和/或一个或多个可视化显示器。用户接口810也包括一个或多个输入设备814，其包括诸如，键盘，鼠标，声音命令输入单元或扩音器，触屏显示器，触敏输入板，姿势捕获摄像机或其他输入按钮或控件等。

存储器806可以是高速随机存取存储器，诸如dram、sram、ddrram、或其他随机存取固态存储设备；或者非易失性存储器，诸如一个或多个磁盘存储设备、光盘存储设备、闪存设备，或其他非易失性固态存储设备。

存储器806存储处理器802可执行的指令集，包括：

操作系统816，包括用于处理各种基本系统服务和用于执行硬件相关任务的程序；

应用818，包括用于视频播放的各种应用程序，这种应用程序能够实现上述各实例中的处理流程，比如可以包括图7所示的发送装置700中的部分或全部模块，各模块701-703中的至少一个模块可以存储有机器可执行指令，处理器802通过执行存储器806中各模块701-703中至少一个模块中的机器可执行指令，进而能够实现上述各模块701-703中的至少一个模块的功能。

需要说明的是，上述各流程和各结构图中不是所有的步骤和模块都是必须的，可以根据实际的需要忽略某些步骤或模块。各步骤的执行顺序不是固定的，可以根据需要进行调整。各模块的划分仅仅是为了便于描述采用的功能上的划分，实际实现时，一个模块可以分由多个模块实现，多个模块的功能也可以由同一个模块实现，这些模块可以位于同一个设备中，也可以位于不同的设备中。

各实施例中的硬件模块可以以硬件方式或硬件平台加软件的方式实现。上述软件包括机器可读指令，存储在非易失性存储介质中。因此，各实施例也可以体现为软件产品。

各例中，硬件可以由专门的硬件或执行机器可读指令的硬件实现。例如，硬件可以为专门设计的永久性电路或逻辑器件(如专用处理器，如fpga或asic)用于完成特定的操作。硬件也可以包括由软件临时配置的可编程逻辑器件或电路(如包括通用处理器或其它可编程处理器)用于执行特定操作。

另外，本申请的每个实例可以通过由数据处理设备如计算机执行的数据处理程序来实现。显然，数据处理程序构成了本申请。此外，通常存储在一个存储介质中的数据处理程序通过直接将程序读取出存储介质或者通过将程序安装或复制到数据处理设备的存储设备(如硬盘和或内存)中执行。因此，这样的存储介质也构成了本申请，本申请还提供了一种非易失性存储介质，其中存储有数据处理程序，这种数据处理程序可用于执行本申请上述方法实例中的任何一种实例。

图7中的模块对应的机器可读指令可以使计算机上操作的操作系统等来完成这里描述的部分或者全部操作。非易失性计算机可读存储介质可以是插入计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器。安装在扩展板或者扩展单元上的cpu等可以根据指令执行部分和全部实际操作。

另外，在本申请各个实例中的装置及各模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上装置或模块集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。