CN109640130B - 一种开播消息推送方法、服务器及可读存储介质 - Google Patents

Abstract

本发明实施例提供了一种开播消息推送方法、服务器及可读存储介质，用于提高推送开播消息的准确性与及时性。所述方法应用于直播应用程序的服务器，包括：接收至少一个开播消息；确定所述至少一个开播消息中每个开播消息对应的主播房间号；基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备。

Description

一种开播消息推送方法、服务器及可读存储介质

技术领域

本发明涉及电子技术领域，尤其涉及一种开播消息推送方法、服务器及可读存储介质。

背景技术

随着计算机技术和网络技术的发展，观看视频直播的用户越来越多，网络直播得到了广泛的普及，用户可以登录直播的应用程序，进入感兴趣的直播间，观看主播的直播节目。很多用户对自己感兴趣的主播会进行关注，同时项目中会有开播提醒按钮，用户还可以通过对开播提醒按钮的设置，使得服务器在直播开播之前向该用户对应的用户端设备发送开播消息，实现对用户感兴趣的视频直播的开播提醒。现有技术中的开播提醒方式，是将开播消息推送给关注主播的用户账户标识对应的用户端设备，由于用户账户标识各不相同，且经常变动，较难维护，导致在进行开播消息推送时很难确定出准确的推送对象，进一步导致推送开播消息的准确性降低。

发明内容

本发明实施例提供了一种开播消息推送方法、服务器及可读存储介质，用于提高推送开播消息的准确性与及时性。

第一方面，本发明提供了一种开播消息推送方法，应用于直播应用程序的服务器，包括：

接收至少一个开播消息；

确定所述至少一个开播消息中每个开播消息对应的主播房间号；

基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；

基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备。

可选的，在所述接收至少一个开播消息之前，所述方法还包括：

在接收到用户端设备发送的关注主播的信息时，将所述用户端设备与关注的主播对应的房间号绑定。

可选的，所述基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备，包括：

将所述至少一个开播消息通过生产进程写入消息队列；

通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备。

可选的，所述将所述至少一个开播消息通过生产进程写入消息队列，包括：

提取所述至少一个开播消息中每个开播消息对应的开播时间；

所述生产进程将所述至少一个开播消息按开播时间的先后顺序写入所述消息队列。

可选的，所述通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备，包括：

所述消费进程每次从所述消息队列中读取预设数量的开播消息直至所述至少一个开播消息全部被读取；

将每次读取的所述预设数量的开播消息分配至至少一个子消费进程，每个子消费进程将分配到的开播消息推送至推送服务中心；

所述推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备。

可选的，所述每个子消费进程将分配到的开播消息推送至推送服务中心，包括

每个子消费进程将分配到的开播消息封装为至少一种预设类型的封装消息，每种预设类型的消息与一种类型的用户端设备对应；

将至少一种预设类型的封装消息发送至推送服务中心。

可选的，所述推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备，包括：

所述推送服务中心在接收到与开播消息对应的至少一种预设类型的封装消息后，针对每一种预设类型的封装消息，将其推送至该开播消息对应的用户端设备中与该预设类型相匹配的用户端设备。

第二方面，本发明提供了一种服务器，所述服务器与直播应用程序对应，所述服务器包括：

接收单元，用于接收至少一个开播消息；

第一确定单元，用于确定所述至少一个开播消息中每个开播消息对应的主播房间号；

第二确定单元，用于基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；

推送单元，用于基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备。

可选的，所述服务器还包括：

绑定单元，用于在所述接收至少一个开播消息之前，在接收到用户端设备发送的关注主播的信息时，将所述用户端设备与关注的主播对应的房间号绑定。

可选的，所述推送单元包括：

消息生产模块，用于将所述至少一个开播消息通过生产进程写入消息队列；

消息消费模块，用于通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备。

可选的，所述消息生产模块包括：

提取子模块，用于提取所述至少一个开播消息中每个开播消息对应的开播时间；

写入子模块，用于通过所述生产进程将所述至少一个开播消息按开播时间的先后顺序写入所述消息队列。

可选的，所述消息消费模块包括：

读取子模块，用于控制所述消费进程每次从所述消息队列中读取预设数量的开播消息直至所述至少一个开播消息全部被读取；

分配子模块，用于将每次读取的所述预设数量的开播消息分配至至少一个子消费进程，每个子消费进程将分配到的开播消息推送至推送服务中心；

推送子模块，用于控制所述推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备。

可选的，所述分配子模块具体用于：

每个子消费进程将分配到的开播消息封装为至少一种预设类型的封装消息，每种预设类型的消息与一种类型的用户端设备对应；

将至少一种预设类型的封装消息发送至推送服务中心。

可选的，所述推送子模块具体用于：

所述推送服务中心在接收到与开播消息对应的至少一种预设类型的封装消息后，针对每一种预设类型的封装消息，将其推送至该开播消息对应的用户端设备中与该预设类型相匹配的用户端设备。

第三方面，本发明提供了一种服务器，所述服务器包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如前述第一方面实施例中所述的开播消息推送方法的步骤。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如前述第一方面实施例中所述的开播消息推送方法的步骤。

本申请实施例中的上述一个或多个技术方案，至少具有如下一种或多种技术效果：

在本发明实施例的技术方案中，由于直播的房间号与主播一一对应，并且间房号不会经常改动，较为稳定，维护起来较为容易，在用户端设备关注某一主播时，用户端设备与该主播的房间号绑定，进而，服务器在接收到多个主播设备端发送的至少一个开播消息时，针对每个开播消息，仅需要获取该开播消息对应的房间号，通过房间号可以快速且准确地确定出关注该房间号对应主播的用户端设备，进而将开播消息快速准确地推送至这些用户端设备。可以确保开播消息推送的准确性与及时性。

附图说明

图1为本发明第一实施例中的一种开播消息推送方法的流程图；

图2为本发明第二实施例中的服务器的示意图；

图3为本发明第三实施例中的服务器的示意图。

具体实施方式

本发明实施例提供了一种开播消息推送方法、服务器及可读存储介质，用于提高推送开播消息的准确性与及时性。所述开播消息推送方法，包括：接收至少一个开播消息；确定所述至少一个开播消息中每个开播消息对应的主播房间号；基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备。

下面通过附图以及具体实施例对本发明技术方案做详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互组合。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

实施例

请参考图1，本发明第一实施例提供一种开播消息推送方法，应用于直播应用程序的服务器，该开播消息推送方法包括如下步骤：

S101：接收至少一个开播消息；

S102：确定所述至少一个开播消息中每个开播消息对应的主播房间号；

S103：基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；

S104：基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备。

具体的，在本实施例中，该开播消息推送方法应用于直播应用程序的服务器。由于直播的房间号与主播一一对应，并且房间号不易变动，较为稳定，维护起来较为容易，较为容易，在用户端设备关注某一主播时，用户端设备与该主播的房间号绑定。当主播确定开播时间，将开播消息通过主播端设备发送至服务器，服务器接收到各个主播发送的至少一个开播消息，针对每个开播消息，服务器仅需要获取开播消息对应的房间号，通过房间号可以快速且准确地确定出关注该房间号对应主播的用户端设备，进而将开播消息快速准确地推送至这些用户端设备。可以确保开播消息推送的准确性与及时性。

进一步，在本实施例中，需要将用户端设备与关注的主播的房间号进行绑定，所以步骤S101之前，还包括如下步骤：

在接收到用户端设备发送的关注主播的信息时，将所述用户端设备与关注的主播对应的房间号绑定。

具体的，在本实施例中，用户可以登录直播的应用程序，进入感兴趣的直播间，观看主播的直播节目。用户对自己感兴趣的主播会进行关注，当用户A点击关注主播A的按钮时，生成关注主播A的信息，并由用户A所使用的客户端设备A发送该关注信息至服务器，服务器获取到该信息后，确定该用户端设备A关注的主播A对应的房间号A，将该用户端设备A与该房间号A绑定。服务器会维护关注各个主播的用户端设备，在用户端设备取消对主播的关注时，解除用户设备与主播对应的房间号的绑定。在有新的用户端设备关注主播时，将该新的用户端设备与主播对应的房间号绑定，绑定的方式可以是用户端设备的账户打上房间号的标签的方式。这样，实时动态维护关注各个主播的用户端设备，可以使得开播消息的推送更准确，更符合用户需求。

进一步，在本实施例中，上述步骤S104：基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备，可通过如下步骤实现：

将所述至少一个开播消息通过生产进程写入消息队列；

通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备。

具体的，在本实施例中，采用异步生产和消费的消息模型来进行开播消息的推送。即：通过生产进程将各主播发送的至少一个开播消息写入消息队列，再通过与消息生产进程不同的消息消费进程来进行开播消息的推送，消息消费进程通过读取消息队列中的开播消息，再将开播消息推送自各自对应的客户端设备。这样，由于采用两个进程完成开播消息的生产和消费，消息生产进程无需等待消息消费进程处理完一个开播消息才进行下一次生产，可以有效减少开播消息推送的延时，提高开播消息推送的及时性。

在消息生产进程将至少一个开播消息写入需消息队列时，可包含如下步骤：

提取所述至少一个开播消息中每个开播消息对应的开播时间；

所述生产进程将所述至少一个开播消息按开播时间的先后顺序写入所述消息队列。

首先，服务器需要提取至少一个开播消息中每个开播消息的开播时间，不同的开播消息对应的开播时间可能不同，为了确保开播消息推送的有效性与及时性，开播时间距离当前时刻最近的需要优先推送，所以将至少一个开播消息按开播时间的先后顺序排列后，消息生产进程按排列后的顺序将至少一个开播消息写入消息队列。比如：开播消息A的开播时间是晚上7点，开播消息B的开播时间是在晚上7点10分，则开播消息A需要排在开播消息B之前被消息生产进程写入至消息队列。这样，才能确保在消息消费进程进行推送时，优先推送开播消息A。

进一步，在通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备时，可通过如下步骤实现：

所述消费进程每次从所述消息队列中读取预设数量的开播消息直至所述至少一个开播消息全部被读取；

将每次读取的所述预设数量的开播消息分配至至少一个子消费进程，每个子消费进程将分配到的开播消息推送至推送服务中心；

所述推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备。

具体的，在本实施例中，为了确保开播消息推送的稳定性，消息消费进程每次只读取消息队列中的预设数量的开播消息，预设数量可以设置为5个、10个等，在具体实施过程中，预设数量可根据实际需要进行设定，在此，本申请不做限制。并且，消息消费进程对应有至少一个子消费进程，可以并行地推送开播消息。子消息进程的数量可以设置为3个、5个等，在具体实施过程中，子消息进程的数量可根据实际需要进行设定，在此本申请不做限制。

在消息消费进程每次读取预设数量的开播消息后，将其分配至子消费进程，各个子消费进程将分配到的开播消息推送至推送服务中心，再由推送服务中心来对接收到的开播消息进行最终的推送。在进行开播消息消费时，采用了多个子进程并行处理的方式，可以有效减少开播消息推送的延时，提高开播消息推送的及时性。

进一步，在每个子消费进程将分配到的开播消息推送至推送服务中心时，可通过如下步骤实现：

每个子消费进程将分配到的开播消息封装为至少一种预设类型的封装消息，每种预设类型的消息与一种类型的用户端设备对应；

将至少一种预设类型的封装消息发送至推送服务中心。

进而，推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备，可通过如下方式实现：

所述推送服务中心在接收到与开播消息对应的至少一种预设类型的封装消息后，针对每一种预设类型的封装消息，将其推送至该开播消息对应的用户端设备中与该预设类型相匹配的用户端设备。

具体的，在本实施例中，由于用户所使用的用户端设备的类型多种多样，比如：安卓系统终端设备、iOS(苹果公司的移动操作系统)终端设备、PC(Personal Computer，个人计算机)类型设备等。为了确保推送到用户端设备的开播消息能够有效地被读取并输出，各个子消费进程针对分配到的开播消息，需要将其封装成不同类型的封装消息。进而，每个自消费进程将封装后的至少一种预设类型的封装消息发送至推送服务中心。比如：子消费进程1分配到开播消息A，将开播消息A封装成安卓类型的封装消息1、iOS类型的封装消息2以及PC类型的封装消息3。子消费进程1将封装消息1、封装消息2以及封装消息3发送至推送服务中心。

推送服务中心维护各个用户端设备信息与房间号的绑定关系，当推送服务中心在接收到至少一个预设类型的封装消息后，至少一个预设类型的封装消息由开播消息封装而成，针对该开播消息，对应多个用户端设备，针对每一种预设类型的封装消息，将其推送至该开播消息对应的用户端设备中与该预设类型相匹配的用户端设备。

比如：推送服务中心接收到封装消息1、封装消息2以及封装消息3，这3个封装消息由开播消息A封装而成，开播消息A对应房间号A，与房间号A绑定的用户端设备包括用户端设备1、用户端设备2、用户端设备3。在将开播消息A推送至用户端设备1时，用户端设备1为安卓系统终端设备，所以将安卓类型的封装消息1推送至用户端设备1，使得用户端设备1能够解读出开播消息A，用户端设备1的用户能及时获知开播消息A。

同理，在将开播消息A推送至用户端设备2时，用户端设备2为iOS系统终端设备，所以将iOS类型的封装消息2推送至用户端设备2，使得用户端设备2能够解读出开播消息A，用户端设备2的用户能及时获知开播消息A。

同理，在将开播消息A推送至用户端设备3时，用户端设备3为PC类型设备，所以将PC类型的封装消息3推送至用户端设备3，使得用户端设备3能够解读出开播消息A，用户端设备3的用户能及时获知开播消息A。

同时，为了进一步减少推送延时，推送服务中心在将开播消息A推送至对应的多个用户端设备时，可以采用并行推送方式。继续沿用上述示例，将开播消息A推送至用户端设备1可以采用子进程1进行推送。将开播消息A推送至用户端设备2可以采用子进程2进行推送。将开播消息A推送至用户端设备3可以采用子进程3进行推送。

请参见图2，本发明的第二实施例提供了一种服务器，所述服务器与直播应用程序对应，所述服务器包括：

接收单元201，用于接收至少一个开播消息；

第一确定单元202，用于确定所述至少一个开播消息中每个开播消息对应的主播房间号；

第二确定单元203，用于基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；

推送单元204，用于基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备。

具体的，在本实施例中，当主播确定开播时间，将开播消息通过主播端设备发送至服务器，服务器的接收单元201接收到各个主播发送的至少一个开播消息，针对每个开播消息，服务器的第一确定单元202确定出该消息对应的房间号，由于直播的房间号与主播一一对应，并且房间号较为稳定，维护起来较为容易，第二确定单元203通过房间号可以快速且准确地确定出关注该房间号对应主播的用户，进而确定出对应的用户端设备，然后，服务器的推送单元204可以将开播消息快速准确地推送至确定出的用户对应的用户端设备，确保了开播消息推送的准确性与及时性。

进一步，在本实施例中，需要将用户端设备与关注的主播的房间号进行绑定，所述服务器还包括：

绑定单元，用于在所述接收至少一个开播消息之前，在接收到用户端设备发送的关注主播的信息时，将所述用户端设备与关注的主播对应的房间号绑定。

具体的，在本实施例中，用户可以登录直播的应用程序，进入感兴趣的直播间，观看主播的直播节目。用户对自己感兴趣的主播会进行关注，当用户A点击关注主播A的按钮时，生成关注主播A的信息，并由用户A所使用的客户端设备A发送该关注信息至服务器，服务器获取到该信息后，绑定单元确定该用户端设备A关注的主播A对应的房间号A，将该用户端设备A与该房间号A绑定。服务器会维护关注各个主播的用户端设备，在用户端设备取消对主播的关注时，解除用户设备与主播对应的房间号的绑定。在有新的用户端设备关注主播时，绑定单元将该新的用户端设备与主播对应的房间号绑定，绑定的方式可以是用户端设备的账户打上房间号的标签的方式。这样，实时动态维护关注各个主播的用户端设备，可以使得开播消息的推送更准确，更符合用户需求。

进一步，在本实施例中，所述推送单元204包括：

消息生产模块，用于将所述至少一个开播消息通过生产进程写入消息队列；

消息消费模块，用于通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备。

具体的，在本实施例中，采用异步生产和消费的消息模型来进行开播消息的推送。即：通过消息生产模块的生产进程将各主播发送的至少一个开播消息写入消息队列，消息消费模块再通过与消息生产进程不同的消息消费进程来进行开播消息的推送，消息消费进程通过读取消息队列中的开播消息，再将开播消息推送自各自对应的客户端设备。这样，由于采用两个进程完成开播消息的生产和消费，消息生产进程无需等待消息消费进程处理完一个开播消息才进行生产，可以有效减少开播消息推送的延时，提高开播消息推送的及时性。

在消息生产模块通过消息生产进程将至少一个开播消息写入需消息队列时，所述消息生产模块包括：

提取子模块，用于提取所述至少一个开播消息中每个开播消息对应的开播时间；

写入子模块，用于通过所述生产进程将所述至少一个开播消息按开播时间的先后顺序写入所述消息队列。

首先，提取子模块需要提取至少一个开播消息中的开播时间，不同的开播消息对应的开播时间可能不同，为了确保开播消息推送的有效性，开播时间距离当前时刻最近的需要优先推送，所以将至少一个开播消息按开播时间的先后顺序排列后，写入子模块通过消息生产进程按排列后的顺序将至少一个开播消息写入消息队列。比如：开播消息A的开播时间是晚上7点，开播消息B的开播时间是在晚上7点10分，则开播消息A需要排在开播消息B之前被消息生产进程写入至消息队列。这样，才能确保在消息消费进程进行推送时，优先推送开播消息A。

进一步，消息消费模块在通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备时，所述消息消费模块包括：

读取子模块，用于控制所述消费进程每次从所述消息队列中读取预设数量的开播消息直至所述至少一个开播消息全部被读取；

分配子模块，用于将每次读取的所述预设数量的开播消息分配至至少一个子消费进程，每个子消费进程将分配到的开播消息推送至推送服务中心；

推送子模块，用于控制所述推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备。

具体的，在本实施例中，为了确保开播消息推送的稳定性，读取子模块通过消息消费进程每次只读取消息队列中的预设数量的开播消息，预设数量可以设置为5个、10个等，在具体实施过程中，预设数量可根据实际需要进行设定，在此，本申请不做限制。并且，消息消费进程对应有至少一个子消费进程，可以并行地推送开播消息。子消息进程的数量可以设置为3个、5个等，在具体实施过程中，子消息进程的数量可根据实际需要进行设定，在此本申请不做限制。在消息消费进程每次读取预设数量的开播消息后，分配子模块将其分配至子消费进程，各个子消费进程将分配到的开播消息推送至推送服务中心，再由推送子模块控制推送服务中心来对接收到的开播消息进行最终的推送。这样，在进行开播消息消费时，采用了多进程并行处理的方式，可以有效减少开播消息推送的延时，提高开播消息推送的及时性。

进一步，在每个子消费进程将分配到的开播消息推送至推送服务中心时，所述分配子模块具体用于：

每个子消费进程将分配到的开播消息封装为至少一种预设类型的封装消息，每种预设类型的消息与一种类型的用户端设备对应；

将至少一种预设类型的封装消息发送至推送服务中心。

进而，推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备，所述推送子模块具体用于：

所述推送服务中心在接收到与开播消息对应的至少一种预设类型的封装消息后，针对每一种预设类型的封装消息，将其推送至该开播消息对应的用户端设备中与该预设类型相匹配的用户端设备。

具体的，在本实施例中，由于用户所使用的用户端设备的类型多种多样，比如：安卓系统终端设备、iOS系统终端设备、PC类型设备等。为了确保推送到用户端设备的开播消息能够有效地被读取并输出，各个子消费进程针对分配到的开播消息，需要将其封装成不同类型的封装消息。进而，每个自消费进程将封装后的至少一种预设类型的封装消息发送至推送服务中心。比如：子消费进程1分配到开播消息A，将开播消息A封装成安卓类型的封装消息1、iOS类型的封装消息2以及PC类型的封装消息3。子消费进程1将封装消息1、封装消息2以及封装消息3发送至推送服务中心。

推送服务中心维护各个用户端设备信息与房间号的绑定关系，当推送服务中心在接收到至少一个预设类型的封装消息后，至少一个预设类型的封装消息由开播消息封装而成，针对该开播消息，对应多个用户端设备，针对每一种预设类型的封装消息，将其推送至该开播消息对应的用户端设备中与该预设类型相匹配的用户端设备。

比如：推送服务中心接收到封装消息1、封装消息2以及封装消息3，这3个封装消息由开播消息A封装而成，开播消息A对应房间号A，与房间号A绑定的用户端设备包括用户端设备1、用户端设备2、用户端设备3。在将开播消息A推送至用户端设备1时，用户端设备1为安卓系统终端设备，所以将安卓类型的封装消息1推送至用户端设备1，使得用户端设备1能够解读出开播消息A，用户端设备1的用户能及时获知开播消息A。

同理，在将开播消息A推送至用户端设备2时，用户端设备2为iOS系统终端设备，所以将iOS类型的封装消息2推送至用户端设备2，使得用户端设备2能够解读出开播消息A，用户端设备2的用户能及时获知开播消息A。

同理，在将开播消息A推送至用户端设备3时，用户端设备3为PC类型设备，所以将PC类型的封装消息3推送至用户端设备3，使得用户端设备3能够解读出开播消息A，用户端设备3的用户能及时获知开播消息A。

同时，为了进一步减少推送延时，推送服务中心在将开播消息A推送至对应的多个用户端设备时，可以采用并行推送方式。继续沿用上述示例，将开播消息A推送至用户端设备1可以采用子进程1进行推送。将开播消息A推送至用户端设备2可以采用子进程2进行推送。将开播消息A推送至用户端设备3可以采用子进程3进行推送。

如图3所示，本发明第三实施例提供了一种服务器，该实施例的服务器包括：处理器301、存储器302以及存储在所述存储器中并可在所述处理器上运行的计算机程序，例如第一实施例中开播消息推送方法对应的程序。所述处理器执行所述计算机程序时实现上述第一实施例中开播消息推送方法中的步骤。或者，所述处理器执行所述计算机程序时实现上述第二实施例的服务器中各模块/单元的功能。

示例性的，所述计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器中，并由所述处理器执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述计算机装置中的执行过程。例如，所述计算机程序可以被分割成接收单元、第一确定单元、第二确定单元、推送单元的功能，各单元具体功能如下：

接收单元，用于接收至少一个开播消息；

第一确定单元，用于确定所述至少一个开播消息中每个开播消息对应的主播房间号；

第二确定单元，用于基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；

推送单元，用于基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备。

所述计服务器可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，所述示意图3仅仅是计算机装置的示例，并不构成对服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述服务器还可以包括输入输出设备、网络接入设备、总线等。

所称处理器301可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。

所述存储器302可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述计算机装置的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本发明第四实施例提供了一种计算机可读存储介质，其上存储有计算机程序，本发明第二实施例中的所述服务器集成的功能单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述第一实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

在本发明实施例的技术方案中，服务器在接收到多个主播设备端发送的至少一个开播消息时，针对每个开播消息，确定出该消息对应的房间号，由于直播的房间号与主播一一对应，并且房间号较为稳定，维护起来较为容易，通过房间号可以快速且准确地确定出关注该房间号对应主播的用户，进而将开播消息快速准确地推送至确定出的用户对应的用户端设备。可以确保开播消息推送的准确性与及时性。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (8)

1.一种开播消息推送方法，应用于直播应用程序的服务器，其特征在于，包括：

在接收到用户端设备发送的关注主播的信息时，将所述用户端设备与关注的主播对应的房间号绑定；

接收至少一个开播消息；

确定所述至少一个开播消息中每个开播消息对应的主播房间号；

基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；

基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备，包括：将所述至少一个开播消息通过生产进程写入消息队列；通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备。

2.如权利要求1所述的方法，其特征在于，所述将所述至少一个开播消息通过生产进程写入消息队列，包括：

提取所述至少一个开播消息中每个开播消息对应的开播时间；

所述生产进程将所述至少一个开播消息按开播时间的先后顺序写入所述消息队列。

3.如权利要求1所述的方法，其特征在于，所述通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备，包括：

所述消费进程每次从所述消息队列中读取预设数量的开播消息直至所述至少一个开播消息全部被读取；

将每次读取的所述预设数量的开播消息分配至至少一个子消费进程，每个子消费进程将分配到的开播消息推送至推送服务中心；

所述推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备。

4.如权利要求3所述的方法，其特征在于，所述每个子消费进程将分配到的开播消息推送至推送服务中心，包括：

每个子消费进程将分配到的开播消息封装为至少一种预设类型的封装消息，每种预设类型的消息与一种类型的用户端设备对应；

将至少一种预设类型的封装消息发送至推送服务中心。

5.如权利要求4所述的方法，其特征在于，所述推送服务中心将接收到的开播消息推送至该开播消息对应的用户端设备，包括：

所述推送服务中心在接收到与开播消息对应的至少一种预设类型的封装消息后，针对每一种预设类型的封装消息，将其推送至该开播消息对应的用户端设备中与该预设类型相匹配的用户端设备。

6.一种服务器，所述服务器与直播应用程序对应，其特征在于，所述服务器包括：

绑定单元，用于在接收到用户端设备发送的关注主播的信息时，将所述用户端设备与关注的主播对应的房间号绑定；

接收单元，用于接收至少一个开播消息；

第一确定单元，用于确定所述至少一个开播消息中每个开播消息对应的主播房间号；

第二确定单元，用于基于每个开播消息对应的主播房间号，确定每个开播消息对应的用户端设备；

推送单元，用于基于所述每个开播消息对应的用户端设备，将所述至少一个开播消息推送至各自对应的用户端设备，包括：将所述至少一个开播消息通过生产进程写入消息队列；通过消费进程将所述消息队列中的至少一个开播消息推送至各自对应的用户端设备。

7.一种服务器，其特征在于，所述服务器包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1-5中任一项所述的开播消息推送方法的步骤。

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

Images