CN112003711B

CN112003711B - 连麦方法及装置

Info

Publication number: CN112003711B
Application number: CN202010758073.2A
Authority: CN
Inventors: 谭培强
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2020-07-31
Filing date: 2020-07-31
Publication date: 2023-01-20
Anticipated expiration: 2040-07-31
Also published as: CN112003711A

Abstract

本公开关于一种连麦方法及装置，涉及移动通信技术领域，该方法包括：接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求；将基于上麦请求生成的直播间进入请求发送至信令服务器；以使信令服务器根据直播间进入请求从媒体控制服务器中获取配置信息；接收信令服务器返回的配置信息；返回配置信息至第一客户端，以使第一客户端根据配置信息，完成第一客户端与第二客户端之间的连麦。本公开实施例不需要主播同意上麦且能够直接通过API服务器下发配置信息，从而简化了申请上麦的流程，缩短了观众上麦时的等待时间。

Description

连麦方法及装置

技术领域

本公开涉及移动通信技术领域，尤其涉及一种连麦方法及装置。

背景技术

语音聊天室目前作为直播的一种产品，广泛受到大家的喜爱。在语音聊天室中，观众可以申请上麦，在经过主播同意后，观众即可以成为麦上的嘉宾，可以发出语音，与其他麦上的嘉宾以及主播进行聊天互动等。

但是相关技术中，观众想要上麦需要等待主播同意，并且在上麦过程中，聊天室系统内需要通过长连接服务器进行两次数据传输，观众等待上麦的时间长，观众体验差。

发明内容

本公开提供一种连麦方法、装置、设备、服务器、系统及存储介质，以至少解决相关技术中观众等待上麦的时间长，观众体验差的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种连麦方法，应用于API服务器，包括：

接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求；所述上麦请求包括所述第一客户端的第一端口信息；

将基于所述上麦请求生成的直播间进入请求发送至信令服务器，所述直播间进入请求包括所述第一端口信息；以使所述信令服务器根据所述直播间进入请求从媒体控制服务器中获取配置信息，且所述媒体控制服务器保存所述第一端口信息；所述配置信息包括所述目标直播间的房间地址；

接收所述信令服务器返回的所述配置信息；

返回所述配置信息至所述第一客户端，以使所述第一客户端根据所述房间地址上传第一音频流至所述媒体控制服务器，所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦。

一种可选的实施例中，

所述接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求之后，将基于所述上麦请求生成的直播间进入请求发送至信令服务器之前，还包括：

在所述目标麦位的分布式锁未被分配的情况下，将所述分布式锁分配给所述第一客户端；

所述将基于所述上麦请求生成的直播间进入请求发送至信令服务器，包括：

在所述第一客户端接收到所述分布式锁的情况下，将基于所述上麦请求生成的所述直播间进入请求发送至所述信令服务器。

一种可选的实施例中，所述接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求之后，还包括：

为所述第一客户端分配第一版本号；

所述返回所述配置信息至所述第一客户端之后，还包括：

接收所述第一客户端在得到所述配置信息后返回的进入成功响应；

根据所述进入成功响应，将所述第一客户端的第一用户状态信息发送至麦序表；其中，所述第一用户状态信息包括所述第一版本号；其中，所述第一版本号用于使所述麦序表更新麦位信息中所述目标麦位对应的目标版本号，以使所述第一客户端接收长连接服务器发送的麦位信令后，在所述麦位信令中包含的所述目标版本号大于所述第一版本号的情况下，利用所述麦位信令中所述目标麦位对应的客户端的用户头像，更新所述目标麦位上显示的用户头像；所述麦位信令为所述长连接服务器根据所述麦位信息生成的信令。

根据本公开实施例的第二方面，提供一种连麦方法，应用于第一客户端，包括：

向应用程序编程接口API服务器发送针对目标直播间内的目标麦位的上麦请求；所述上麦请求包括所述第一客户端的第一端口信息；

接收API服务器返回的配置信息；所述配置信息包括所述目标直播间的房间地址；

根据所述房间地址上传第一音频流至媒体控制服务器，以使所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦。

一种可选的实施例中，所述配置信息还包括所述目标直播间中的所述第二客户端的第二端口信息；所述接收API服务器返回的配置信息之后，还包括：

根据所述第二端口信息，从所述媒体控制服务器中获取所述第二客户端上传的第二音频流。

一种可选的实施例中，所述接收API服务器返回的配置信息之后，还包括：

在所述目标麦位上显示所述第一客户端的用户头像。

一种可选的实施例中，所述向应用程序编程接口API服务器发送针对目标直播间内的目标麦位的上麦请求之后，还包括：

接收所述API服务器分配的第一版本号；

所述接收API服务器返回的配置信息之后，还包括：

返回进入成功响应至所述API服务器；以使所述API服务器根据所述进入成功响应，将所述第一客户端的第一用户状态信息发送至麦序表；其中，所述第一用户状态信息包括所述第一版本号，所述第一版本号用于使所述麦序表更新麦位信息中所述目标麦位对应的目标版本号；

所述在所述目标麦位上显示所述第一客户端的用户头像之后，还包括：

接收长连接服务器发送的麦位信令后，在所述麦位信令中包含的所述目标版本号大于所述第一版本号的情况下，利用所述麦位信令中所述目标麦位对应的客户端的用户头像，更新所述目标麦位上显示的用户头像；所述麦位信令为所述长连接服务器根据所述麦位信息生成的信令。

根据本公开实施例的第三方面，提供一种连麦方法，应用于媒体控制服务器，包括：

接收信令服务器发送的针对目标直播间的信息获取请求；所述信息获取请求包括第一客户端的第一端口信息；

保存所述第一端口信息；

根据所述信息获取请求，向所述信令服务器返回配置信息，所述配置信息包括所述目标直播间的房间地址；以使所述信令服务器通过应用程序编程接口API服务器向所述第一客户端返回所述配置信息；

接收所述第一客户端根据所述房间地址上传的第一音频流；

广播所述第一端口信息，以使所述目标直播间内的第二客户端根据所述第一端口信息获取所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦。

一种可选的实施例中，所述配置信息还包括所述目标直播间中的所述第二客户端的第二端口信息；所述方法还包括：

接收所述第二客户端上传的第二音频流；以使所述第一客户端根据所述第二端口信息，从所述媒体控制服务器中获取所述第二音频流。

根据本公开实施例的第四方面，提供一种连麦方法，所述方法包括：

第一客户端向API服务器发送针对目标直播间内的目标麦位的上麦请求；所述上麦请求包括所述第一客户端的第一端口信息；

所述API服务器将基于所述上麦请求生成的直播间进入请求发送至所述信令服务器；所述直播间进入请求包括所述第一端口信息；

所述信令服务器将基于所述直播间进入请求生成的信息获取请求发送至所述媒体控制服务器；所述信息获取请求包括所述第一端口信息；

所述媒体控制服务器将配置信息通过所述信令服务器返回至所述API服务器，并保存所述第一端口信息；所述配置信息包括所述目标直播间的房间地址；

所述API服务器返回所述配置信息至所述第一客户端；

所述第一客户端根据所述房间地址上传第一音频流至媒体控制服务器；

所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦。

一种可选的实施例中，所述配置信息还包括所述目标直播间中的所述第二客户端的第二端口信息；所述API服务器返回所述配置信息至所述第一客户端之后，还包括：

所述第二客户端上传第二音频流至所述媒体控制服务器；

所述第一客户端根据所述第二端口信息，从所述媒体控制服务器中获取所述第二客户端上传的第二音频流。

一种可选的实施例中，所述API服务器返回所述配置信息至所述第一客户端之后，还包括：

所述第一客户端在接收到所述配置信息后，在所述目标麦位上显示所述第一客户端的用户头像。

一种可选的实施例中，所述第一客户端向API服务器发送针对目标直播间内的目标麦位的上麦请求之后，还包括：

所述API服务器为所述第一客户端分配第一版本号；

所述API服务器返回所述配置信息至所述第一客户端之后，还包括：

所述第一客户端在接收到所述配置信息后，返回进入成功响应至所述API服务器；

所述API服务器根据所述进入成功响应，将所述第一客户端的第一用户状态信息发送至麦序表；其中，所述第一用户状态信息包括所述第一版本号，所述第一版本号用于使所述麦序表更新麦位信息中所述目标麦位对应的目标版本号；

所述第一客户端接收所述长连接服务器发送的麦位信令；

所述第一客户端在所述麦位信令中包含的所述目标版本号大于所述第一版本号的情况下，利用所述麦位信令中所述目标麦位对应的客户端的用户头像，更新所述目标麦位上显示的用户头像；所述麦位信令为所述长连接服务器根据所述麦位信息生成的信令。

根据本公开实施例的第五方面，提供一种数据处理方法，应用于第一服务器，所述第一服务器包括直播系统中存在数据访问需求的服务器；包括：

发送目标任务对应的数据请求至远程过程调用协议rpc服务器；

接收rpc服务器返回的目标任务数据，所述目标任务数据包括所述rpc服务器根据所述数据请求访问数据库后获取的数据；

根据所述任务数据执行所述目标任务。

一种可选的实施例中，所述第一服务器包括麦位清理服务器；所述发送目标任务对应的数据请求至远程过程调用协议rpc服务器之前，还包括：

为各个麦位清理进程分配不同的任务直播间；以使各个所述麦位清理进程并行执行对所分配的任务直播间的麦位状态清理操作。

根据本公开实施例的第六方面，提供一种数据处理方法，应用于远程过程调用协议rpc服务器，包括：

接收第一服务器发送的目标任务对应的数据请求；

根据所述数据请求访问数据库，得到目标任务数据；

将所述目标任务数据发送至所述第一服务器，以使所述第一服务器根据所述目标任务数据执行所述目标任务。

一种可选的实施例中，所述方法还包括：

监听分布式存储设备发布的所述数据库的消息通知；

根据所述消息通知更新自身保存的直播间状态和各个直播间内的用户状态，以使麦位清理服务器根据更新后的直播间状态和用户状态进行麦位状态清理。

根据本公开实施例的第七方面，提供一种连麦装置，应用于应用程序编程接口API服务器，包括：

上麦接收模块，被配置为接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求；所述上麦请求包括所述第一客户端的第一端口信息；

信令请求模块，被配置为将基于所述上麦请求生成的直播间进入请求发送至信令服务器，所述直播间进入请求包括所述第一端口信息；以使所述信令服务器根据所述直播间进入请求从媒体控制服务器中获取配置信息，且所述媒体控制服务器保存所述第一端口信息；所述配置信息包括所述目标直播间的房间地址；

第一配置接收模块，被配置为接收所述信令服务器返回的所述配置信息；

第一配置返回模块，被配置为返回所述配置信息至所述第一客户端，以使所述第一客户端根据所述房间地址上传第一音频流至所述媒体控制服务器，所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦。

一种可选的实施例中，所述连麦装置还包括：

锁分配模块，被配置为执行在所述目标麦位的分布式锁未被分配的情况下，将所述分布式锁分配给所述第一客户端；

所述信令请求模块，被配置为具体执行在所述第一客户端接收到所述分布式锁的情况下，将基于所述上麦请求生成的所述直播间进入请求发送至所述信令服务器。

一种可选的实施例中，所述连麦装置还包括：

版本号分配模块，被配置为执行为所述第一客户端分配第一版本号；

响应接收模块，被配置为接收所述第一客户端在得到所述配置信息后返回的进入成功响应；

第一状态发送模块，被配置为执行根据所述进入成功响应，将所述第一客户端的第一用户状态信息发送至麦序表；其中，所述第一用户状态信息包括所述第一版本号；其中，所述第一版本号用于使所述麦序表更新麦位信息中所述目标麦位对应的目标版本号，以使所述第一客户端接收长连接服务器发送的麦位信令后，在所述麦位信令中包含的所述目标版本号大于所述第一版本号的情况下，利用所述麦位信令中所述目标麦位对应的客户端的用户头像，更新所述目标麦位上显示的用户头像；所述麦位信令为所述长连接服务器根据所述麦位信息生成的信令。

根据本公开实施例的第八方面，提供一种连麦装置，应用于第一客户端，其特征在于，包括：

上麦请求模块，被配置为执行向应用程序编程接口API服务器发送针对目标直播间内的目标麦位的上麦请求；所述上麦请求包括所述第一客户端的第一端口信息；

第二配置接收模块，被配置为接收API服务器返回的配置信息；所述配置信息包括所述目标直播间的房间地址；

配置模块，被配置为执行根据所述房间地址上传第一音频流至媒体控制服务器，以使所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦。

一种可选的实施例中，所述装置还包括：

音频获取模块，被配置为执行根据所述第二端口信息，从所述媒体控制服务器中获取所述第二客户端上传的第二音频流。

一种可选的实施例中，所述装置还包括：

头像显示模块，被配置为执行在所述目标麦位上显示所述第一客户端的用户头像。

一种可选的实施例中，所述装置还包括：

版本号接收模块，被配置为接收所述API服务器分配的第一版本号；

响应返回模块，被配置为返回进入成功响应至所述API服务器；以使所述API服务器根据所述进入成功响应，将所述第一客户端的第一用户状态信息发送至麦序表；其中，所述第一用户状态信息包括所述第一版本号，所述第一版本号用于使所述麦序表更新麦位信息中所述目标麦位对应的目标版本号；

信令接收模块，被配置为接收长连接服务器发送的麦位信令；

头像更新模块，被配置为在所述麦位信令中包含的所述目标版本号大于所述第一版本号的情况下，利用所述麦位信令中所述目标麦位对应的客户端的用户头像，更新所述目标麦位上显示的用户头像；所述麦位信令为所述长连接服务器根据所述麦位信息生成的信令。

根据本公开实施例的第九方面，提供一种连麦装置，应用于媒体控制服务器，包括：

信息获取模块，被配置为执行接收信令服务器发送的针对目标直播间的信息获取请求；所述信息获取请求包括第一客户端的第一端口信息；

端口保存模块，被配置为执行保存所述第一端口信息；

第二配置返回模块，被配置为执行根据所述信息获取请求，向所述信令服务器返回配置信息，所述配置信息包括所述目标直播间的房间地址；以使所述信令服务器通过应用程序编程接口API服务器向所述第一客户端返回所述配置信息；

第一音频接收模块，被配置为执行接收所述第一客户端根据所述房间地址上传的第一音频流；

广播模块，被配置为执行广播所述第一端口信息，以使所述目标直播间内的第二客户端根据所述第一端口信息获取所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦。

一种可选的实施例中，所述装置还包括：

第二音频接收模块，被配置为执行接收所述第二客户端上传的第二音频流；以使所述第一客户端根据所述第二端口信息，从所述媒体控制服务器中获取所述第二音频流。

根据本公开实施例的第十方面，提供一种数据处理装置，应用于第一服务器，所述第一服务器包括直播系统中存在数据访问需求的服务器；包括：

数据请求模块，被配置为发送目标任务对应的数据请求至远程过程调用协议rpc服务器；

数据接收模块，被配置为接收rpc服务器返回的目标任务数据，所述目标任务数据包括所述rpc服务器根据所述数据请求访问数据库后获取的数据；

任务执行模块，被配置为根据所述任务数据执行所述目标任务。

一种可选的实施例中，所述第一服务器包括麦位清理服务器；所述装置还包括：

直播间分配模块，被配置为执行为各个麦位清理进程分配不同的任务直播间；以使各个所述麦位清理进程并行执行对所分配的任务直播间的麦位状态清理操作。

根据本公开实施例的第十一方面，提供一种数据处理装置，应用于远程过程调用协议rpc服务器，包括：

数据请求接收模块，被配置为接收第一服务器发送的目标任务对应的数据请求；

访问模块，被配置为执行根据所述数据请求访问数据库，得到目标任务数据；

数据发送模块，被配置为执行将所述目标任务数据发送至所述第一服务器，以使所述第一服务器根据所述目标任务数据执行所述目标任务。

一种可选的实施例中，所述装置还包括：

监听模块，被配置为监听分布式存储设备发布的所述数据库的消息通知；

状态更新模块，被配置为根据所述消息通知更新自身保存的直播间状态和各个直播间内的用户状态，以使麦位清理服务器根据更新后的直播间状态和用户状态进行麦位状态清理。

根据本公开实施例的第十二方面，提供一种服务器，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第一方面或第三方面中任一项所述的连麦方法，或者第五方面或第六方面中任一项所述的数据处理方法。

根据本公开实施例的第十三方面，提供一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第二方面所述的连麦方法。

根据本公开实施例的第十四方面，提供一种直播系统，包括：

应用程序编程接口API服务器，被配置为执行如第一方面所述的连麦方法；

第一客户端，被配置为执行如第二方面所述的连麦方法；

媒体控制服务器，被配置为执行如第三方面所述的连麦方法；

第二客户端，被配置为根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流；

信令服务器，被配置为将基于所述直播间进入请求生成的信息获取请求发送至所述媒体控制服务器；所述信息获取请求包括所述第一端口信息；接收所述媒体控制服务器返回的配置信息，并将所述配置信息发送至所述API服务器；

长连接服务器，被配置为从麦序表获取麦位信息；根据所述麦位信息生成麦位信令；将所述麦序信令发送至所述目标直播间内的各个客户端；所述麦位信令中包括目标麦位对应的目标版本号；

分布式存储设备，被配置为存储所述麦序表，所述麦序表中保存有所述麦位信息，所述麦位信息中包括所述目标麦位对应的所述目标版本号；

第一服务器，所述第一服务器包括直播系统中存在数据访问需求的服务器；所述第一服务器被配置为执行如第五方面所述的数据处理方法；

远程过程调用协议rpc服务器，被配置为执行如第六方面所述的数据处理方法；

数据库，被配置为存储所述直播系统中的数据，接收rpc服务器发送的数据请求；返回所述数据请求对应的目标任务数据至所述rpc服务器。

根据本公开实施例的第十五方面，提供一种存储介质，当所述存储介质中的指令由服务器的处理器执行时，使得所述服务器能够执行如第一方面或第三方面中任一项所述的连麦方法或第五方面至第六方面中任一项所述的数据处理方法；当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如第二方面所述的连麦方法。

根据本公开实施例的第十六方面，提供一种计算机程序产品，包括程序或指令，以使程序或指令被执行时，实现如第一方面至第三方面中任一方面的连麦方法或者第五方面至第六方面的数据处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

在本实施例中，在API服务器接收到第一客户端发送的针对目标麦位的上麦请求后，API服务器会通过信令服务器向媒体控制服务器获取配置信息，之后直接返回配置信息至第一客户端，第一客户端能够根据配置信息完成直播间配置，从而完成与第二客户端之间的连麦，实现上麦的目的。即本实施例中，能够直接通过API服务器下发配置信息，不需要根据长连接服务器下发的网络电话信令完成直播间配置，简化了客户端上麦过程中，长连接服务器下发网络电话信令的步骤，缩短了上麦路径；并且，API服务器也不需要在主播同意后再下发配置信息，简化了观众申请上麦的流程，缩短了观众上麦时的等待时间，提高了观众的上麦体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的相关技术中观众申请上麦的架构示意图。

图2是根据一示例性实施例示出的一种直播系统的框图。

图3是根据一示例性实施例示出的一种连麦方法的架构图。

图4是根据一示例性实施例示出的长连接服务器的工作示意图

图5是根据一示例性实施例示出的另一种连麦方法的流程图。

图6是根据一示例性实施例示出的数据库访问示意图。

图7是根据一示例性实施例示出的一种数据处理方法的流程图。

图8是根据一示例性实施例示出的一种rpc服务器增量更新的流程示意图。

图9是根据一示例性实施例示出的一种API服务器侧的连麦方法的流程图。

图10是根据一示例性实施例示出的一种第一客户端侧的连麦方法的流程图。

图11是根据一示例性实施例示出的一种媒体控制服务器侧的连麦方法的流程图。

图12是根据一示例性实施例示出的一种第一服务器侧的数据处理方法的流程图。

图13是根据一示例性实施例示出的一种rpc服务侧的数据处理方法的流程图。

图14是根据一示例性实施例示出的一种API服务器侧的连麦装置框图。

图15是根据一示例性实施例示出的一种第一客户端侧的连麦装置框图。

图16是根据一示例性实施例示出的一种媒体控制服务器侧的连麦装置框图。

图17是根据一示例性实施例示出的一种第一服务器侧的数据处理装置框图。

图18是根据一示例性实施例示出的一种rpc服务器侧的数据处理装置框图。

图19是根据一示例性实施例示出的一种服务器的框图。

图20是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

本公开中的各个客户端，可以是各种终端，如手机、平板电脑、PC、智能手环等智能设备，也可以是安装在这些终端上的应用程序。

目前，在语音聊天室中，主要包括三种用户身份，即主播、嘉宾和观众。主播用于创建聊天室，进行麦位管理等，这里的麦位管理主要包括是否允许观众上麦、闭麦、锁麦等。观众指的是未处在麦位上的用户，观众能够听到嘉宾和主播的声音，但是无法进行发言，如果观众想要发言的话，则需要申请上麦，在主播同意后，观众上到麦位之后，观众与主播以及其他麦位上的嘉宾实现了连麦，此时该观众才能够进行发言。嘉宾指的是处在麦位上的用户。

语音聊天室作为直播的一种产品，是应用于直播系统内的，基于用户持有的客户端以及直播系统内的服务器来实现，各个客户端通过与直播系统中的服务器进行交互，来实现多个客户端之间多对多的语音通信。作为示例，直播系统的架构图可以如图1所示，其包括：观众客户端105、主播客户端103、嘉宾客户端101、应用程序编程接口(ApplicationProgramming Interface，API)服务器107(也可称为直播服务器或麦序服务器)、信令服务器109、长连接服务器115、媒体控制服务器111(Media Control Unit，MCU)、用于支持麦序表113实现的分布式存储设备(Redis)等。

为了方便了解目前观众客户端105申请上麦时的工作流程以及上述直播系统中各个组成部分的具体功能，可参见图1，图1示出了相关技术中观众申请上麦的架构示意图，该架构包括：

S100，观众客户端105发送申请上麦的请求至API服务器107(即图1中的直播服务)；该申请上麦的请求携带有观众客户端105的第一端口信息；

S102，主播客户端103发送同意上麦的指令至API服务器107；

S104，在接收到主播客户端103发送的同意上麦的指令后，API服务器107发送申请进入直播间的直播间进入请求至信令服务器109；该直播间进入请求包括上述第一端口信息；

S106，信令服务器109根据直播间进入请求告知媒体控制服务器111(即图1中的MCU直播间)用户申请进入目标直播间；媒体控制服务器111会保存第一端口信息；

S108，信令服务器109返回申请结果至API服务器107；

S110，API服务器107发送用户状态准备的信息至麦序表113；用户状态准备指的是用户处于进入准备阶段；

S112，API服务器107返回申请结果至观众客户端105；

S114，长连接服务器115发送网络电话(Voice over Internet Protocol，VoIP)信令至各个客户端；网络电话信令包含房间地址和房间状态信息，房间状态信息包括观众客户端105的第一端口信息以及其他麦上客户端的端口信息，因此，通过房间状态信息即能够获取直播间内所有麦上客户端上传的音频流。

S116，观众客户端105根据网络电话信令下发的房间地址，进初始化直播连麦软件集成开发包(arya)配置；其中，初始化直播连麦软件集成开发包配置包括记录房间地址，并根据该房间地址将自身的音频流上传至媒体控制服务器111等操作。

嘉宾客户端101和主播客户端103根据网络电话信令下发的第一端口信息获取观众客户端105上传的音频流；

S118，观众客户端105发送进入成功响应至API服务器107；

S120，API服务器107发送用户状态完成的信息至麦序表113；用户状态完成指的是用户完成上麦配置，上麦配置包括记录房间地址等操作。

S122，麦序表113根据用户状态完成的信息更新自身保存的麦位信息；

S124，长连接服务器115定时拉取麦序表113中的麦位信息，并根据麦位信息生成麦位信令，

S126，长连接服务器115将麦位信令发送至各个客户端；各个客户端根据接收到的麦位信令，更新自身播放器中各个麦位上显示的用户头像。

在上述过程中，观众客户端105想要实现上麦的目的，需要等待主播同意才能进行后续流程，若主播当前没有及时同意上麦的话，则需要等待较长时间；并且整个过程中需要经历两次长连接进行麦位信令以及网络电话信令的传输，而长连接传输的时间较长，导致整体上麦时间过长，至少需要8s左右(两轮长连接耗时6s)，观众体验差，上麦意愿不高。

为了解决上述问题，本公开提供了一种直播系统，如图2所示，图2是根据一示例性实施例示出的一种直播系统的框图。该直播系统组成部分与前述描述的直播系统类似，主要包括：第一客户端200(即观众客户端)、第二客户端202(即主播客户端或嘉宾客户端)、API服务器204、信令服务器206、长连接服务器208、媒体控制服务器210、分布式存储设备212、数据库((Data Base，DB))、远程过程调用协议(Remote Procedure Call Protocol，rpc)服务器、第一服务器等。第一服务器，包括直播系统中存在数据访问需求的服务器，例如麦序清理服务器等。

其中，数据库、rpc服务器、第一服务器并未在图2中示出。

其中，分布式存储设备212用于存储本公开中的麦序表，并支持麦序表的功能。

直播系统中的各个组成部分的具体功能可参见后续方法实施例中的详细描述，在此不再赘述。

图3是根据一示例性实施例示出的一种连麦方法的架构图。

其中，图2和图3中的API服务器204与图1中的API服务器107可以为相同的服务器。图2和图3中的信令服务器206与图1中的信令服务器109可以为相同的服务器。图2和图3中的长连接服务器208与图1中的长连接服务器115可以为相同的服务器。图2和图3中的媒体控制服务器210与图1中的媒体控制服务器111可以为相同的服务器。

如图3所示，连麦方法用于上述直播系统中，包括以下步骤。

S300，第一客户端200向API服务器204发送针对目标直播间内的目标麦位的上麦请求。

该上麦请求包括第一客户端的第一端口信息，这里的第一端口信息可以包括IP地址或者端口号等，第一端口信息用于表征第一客户端的身份信息以及地址信息等。上麦请求的功能是告知API服务器204，第一客户端200想要在目标直播间内的目标麦位上进行上麦，因此上麦请求中需要包含第一客户端200的第一端口信息、目标直播间的标识以及目标麦位的标识等，这些标识的具体形式本公开不作限定，此外上麦请求中还可以包含一些其他的内容，例如辅助客户端与API服务器204之间进行通信的一些信息等，本公开不限定上麦请求的具体内容。

其中，上麦请求的生成过程可以包括：第一客户端200接收到用户对目标麦位的上麦控件(例如图标)的第一输入后，生成针对目标麦位的上麦请求。这里的第一输入可以为点击输入、长按输入、特定手势输入等，本公开对此不作限定。

S302，API服务器204将基于上麦请求生成的直播间进入请求发送至信令服务器206；该直播间进入请求内也会包括上述第一端口信息。

其中，这里的直播间进入请求可以与上麦请求相同，也可以与上麦请求不同。例如，直播间进入请求内除了包含上麦请求所包含的内容之外，还可以包括API服务器204的硬件标识符、网络地址或者IP地址、API输入接口编码等相关的信息，用于方便信令服务器206返回数据至API服务器204。或者直播间进入请求中还可以去除上麦请求中的一些无关信息，例如辅助客户端与API服务器204之间进行通信的一些信息等。本公开不限定直播间进入请求的具体内容。

API服务器204不需要等待主播发送同意上麦的指令。通过去除主播发送同意上麦的步骤，简化了整体上麦流程，缩短了上麦所需要等待的时间。在此情况下，主播若想要对麦位进行控制的话，可通过闭麦或锁麦进行控制。闭麦指的是关闭麦克风，即控制该麦位上的嘉宾不能发言；锁麦指的是锁定麦位，即控制该麦位不能进行申请，观众不能申请上麦至该麦位。

S304，信令服务器206将基于直播间进入请求生成的信息获取请求发送至媒体控制服务器210；该信息获取请求内也包括上述第一端口信息。

信令服务器206在接收到API服务器204发送的直播间进入请求后，即能够得知第一客户端200的用户想要进入的直播间，基于此，信令服务器206向媒体控制服务器210获取目标直播间的配置信息。

S306，媒体控制服务器210将配置信息通过信令服务器返回至API服务器，并保存第一端口信息；配置信息包括目标直播间的房间地址；这里的房间地址可以为IP地址等用于表征目标直播间的地址信息。

S308，信令服务器206返回配置信息至API服务器204；

S310，API服务器204发送用户状态准备的信息至麦序表；

发送用户状态准备的信息至麦序表的目的，是为了告知麦序表此时第一客户端200准备对目标麦位进行上麦，但是当前并未上麦成功。麦序表在接收到用户状态准备的信息后，不会对自身保存的麦序信息中目标麦位的相关信息进行更新。

S312，API服务器204返回配置信息至第一客户端200；

其中，API服务器204可以通过API接口返回配置信息。即本实施例中直接通过API服务器204返回配置信息，而不需要通过长连接服务器208发送的网络电话信令返回配置信息，由于API服务器204与第一客户端200之间的连接属于短连接，因此传输路径短，所需传输时间少。

S314，媒体控制服务器210广播上述第一端口信息。媒体控制服务器210可以通过媒体服务进行广播。

其中，S322和S314之间并行执行，没有先后顺序的限制。

若第二客户端202为嘉宾客户端，则第二客户端202在获取自身用户的音频流后，会首先发送至主播客户端；若第二客户端202为主播客户端，则第二客户端202会汇总各个嘉宾客户端发送的音频流，并推送至媒体控制服务器210。第二客户端202可以根据广播的第一端口信息以及自身之前记录的其他麦上客户端的端口信息，来获取直播间内各个麦上客户端上传的音频流。

通过将网络电话信令一拆为二，分为配置信息和直播间状态，分别由API服务器204和媒体控制服务器210发送，整个步骤在ms级别，相比通过长连接服务器208发送的方式，缩短了传输路径，通过减少一轮长连接的耗时，减少了信息传输所需的时间。

S316，第一客户端200根据房间地址上传第一音频流至媒体控制服务器。

第一客户端200在接收到配置信息后，会初始化直播连麦软件集成开发包配置，具体是对于第一客户端200的播放器进行配置，配置过程可以包括记录目标直播间的房间地址等。

目标直播间内的第二客户端根据媒体控制服务器广播的第一端口信息获取媒体控制服务器中的第一音频流，完成第一客户端与第二客户端之间的连麦。此时，目标直播间内的第二客户端能够获取第一客户端上传的音频流，即其他第二客户端的用户能够听到第一客户端的用户发出的声音。

S318，第一客户端200发送进入成功响应至API服务器204；

进入成功响应用于告知API服务器204第一客户端200已经完成了直播连麦软件集成开发包配置，以及第一客户端200的当前状态。

S330，API服务器204发送第一用户状态信息至麦序表；

第一用户状态信息包括用户状态完成的信息，麦序表在接收到用户状态完成的信息后，即了解第一客户端200已经完成了上麦所需的配置操作，因此可以根据第一客户端200的状态信息对目标麦位的信息进行更新。

S322，麦序表根据第一用户状态信息更新自身保存的麦位信息；

具体的，麦序表主要根据第一用户状态信息，更新麦位信息中目标麦位对应的用户标识，这里的用户标识可以包括用户账号以及用户头像等，使得后续各个客户端能够根据更新后的信息确定新上麦的用户，进而更新自身播放器上目标麦位向显示的用户头像。

S324，长连接服务器208定时拉取麦序表中的麦位信息，并根据麦位信息生成麦位信令；

由于麦序表会根据用户的上麦导致更新，因此为了保证各个客户端上显示的上麦用户时正确的，长连接服务器208也需要及时向客户端推送新的麦序指令，出于此目的，长连接服务器208需要定时向麦序表拉取麦位信息生成麦位信令。其中，长连接服务器208的拉取周期不宜过长，例如，拉取周期可以为1s。

S326，长连接服务器208将麦位信令发送至各个客户端；各个客户端根据接收到的麦位信令，更新自身播放器中各个麦位上显示的用户头像。例如，自身播放器中麦位A显示的是用户A的头像，接收到的麦位信令中麦位A对应的是用户B，因此将播放器中麦位A显示的头像更新为用户B的头像。

在本实施例中，在API服务器204接收到第一客户端200发送的针对目标麦位的上麦请求后，API服务器204会通过信令服务器206向媒体控制服务器210获取配置信息，之后直接返回配置信息至第一客户端200，第一客户端200能够根据配置信息完成直播间配置，从而完成与第二客户端202之间的连麦，实现上麦的目的。即本实施例中，能够直接通过API服务器204下发配置信息，不需要根据长连接服务器208下发的网络电话信令完成直播间配置，简化了客户端上麦过程中，长连接服务器208下发网络电话信令的步骤，缩短了上麦路径；并且，API服务器204也不需要在主播同意后再下发配置信息，简化了观众申请上麦的流程，缩短了观众上麦时的等待时间，提高了观众的上麦体验。

其中，上面提到的长连接(即长连接服务器208发送的信息)由拉取线程(pullerThread)和推送线程(TickerThread)两部分组成。pullerThread用于定时从麦序表中拉取麦序信息，tickerThread用于将整合后的信息发送给客户端，如图4所示，图4是根据一示例性实施例示出的长连接服务器208的工作示意图。为了进一步减少上麦的时间，可选的，可以将长连接服务器208拉取麦序信息的周期由3s改为1s，从而使得整体上麦流程的时间降低。但是由于降低拉取周期会成倍的增加麦序表的访问和服务压力，因此通常无法将周期降低至1s以下。

由于想要实现完整的连麦，除了需要使第二客户端能够获取到第一客户端的音频流，还需要使第一客户端也能够得到其他第二客户端的音频流。基于此，在本公开一些实施例中，上述配置信息还可以包括目标直播间中的第二客户端的第二端口信息。在S312之后，该方法还包括：

第二客户端202上传第二音频流至媒体控制服务器210；

第一客户端200根据第二端口信息，从媒体控制服务器210中获取第二客户端202上传的第二音频流。

本实施例中，第一客户端200能够通过配置信息来获取目标直播间中其他第二客户端的第二端口信息，后续第一客户端200能够根据第二端口信息来获取第二客户端202上传的第二音频流。这种情况下，使得目标直播间内的麦上客户端均能够获取对方发送的音频流并能够将自身音频流发送至对方，从而实现连麦的目的。

由于在目前的观众必须等待麦序信令到来更新状态，才能看到自己上麦，基于此，在本公开一些实施例中，S316之后，还可以包括：

第一客户端200在接收到配置信息后，在目标麦位上显示第一客户端200的用户头像。具体的，也可以在第一客户端200在自身播放器内记录下配置信息，完成直播连麦软件集成开发包配置之后，再显示第一客户端200的用户头像。

即本实施例中，第一客户端200在接收到配置信息后，不需要等待麦位信令，而是可以直接将用户头像显示至目标麦位上，使得用户点击即上麦成为现实，提高了用户的上麦体验。

在本公开一些实施例中，基于图3所示的方法实施例，如图5所示，图5是根据一示例性实施例示出的另一种连麦方法的流程图。该连麦方法中可以设置版本号，用来辅助用户头像的上麦，该实施例可以包括：

S500，第一客户端200向API服务器204发送针对目标直播间内的目标麦位的上麦请求；该步骤与图3中的S300相似。

S502，API服务器204为第一客户端200分配第一版本号。即API服务器204接收到第一客户端200发送的上麦请求后，即可为API服务器204分配一个第一版本号。

S504，第一客户端200根据API服务器204返回的配置信息进行配置；

S506，第一客户端200返回进入成功响应至API服务器204；进入成功响应中可以携带有第一版本号；

S508，API服务器204将第一客户端200的第一用户状态信息发送至麦序表；第一用户状态信息包括第一版本号；第一版本号用于使麦序表更新麦位信息中目标麦位对应的目标版本号；

S510，麦序表根据第一版本号更新麦位信息中目标麦位对应的目标版本号；

S512，长连接服务器208定时拉取麦序表中的麦位信息，并根据麦位信息生成麦位信令；该步骤与图3中的S324相似。

S514，长连接服务器208将麦位信令发送至各个客户端；

S516，第一客户端200接收长连接服务器208发送的麦位信令后，在麦位信令中包含的目标版本号大于第一版本号的情况下，利用麦位信令中目标麦位对应的客户端的用户头像，更新目标麦位上显示的用户头像。

其中，这里的版本号是按照从小到大进行分配的，例如，第一个发送上麦申请的客户端，为其分配的第一版本号为1，第二个发送上麦申请的客户端，为其分配的版本号为2，依次递增。第一版本号可以仅包括数字，例如1,2,3，或者还可包括字母和数字的组合，例如no.1，no.2等。本公开不限定第一版本号的具体内容。

在本实施例中，在第一客户端200向API服务器204发送上麦申请后，API服务器204即会给第一客户端200下发一个第一版本号，当第一客户端200完成直播连麦软件集成开发包配置后，第一客户端200会将自身用户头像显示至目标麦位上，并将第一用户状态信息发送给麦序表，麦序表能够利用第一用户状态信息中携带的第一版本号更新自身麦位信息中目标麦位对应的目标版本号。若是在麦序表利用第一版本号更新目标版本号之前，即S222完成之前，长连接服务器208即拉取了麦序表中的麦序信息，此时麦序信息中目标麦位对应的目标版本号为之前保存的版本号，因此小于第一版本号，这种情况下，后续第一客户端200接收到长连接服务器208发送的麦位信令后，由于麦位信令中包含的目标版本号小于第一版本号，因此第一客户端200的用户头像可以保持显示在目标麦位上，不会消失。在长连接服务器208下一次拉取麦位信息后，由于麦位信息中的目标版本号已更新，目标版本号等于第一版本号，因此也不会导致用户头像下麦。可见，本实施例的方式可以保证自第一客户端200的用户头像显示至目标麦位后，即使长连接服务器208发送的麦位信令是基于麦序表未更新时的麦位信息生成的，也不会导致用户头像从目标麦位上消失，避免了出现用户头像在本次接收到麦位信令后消失，下次接收到麦位信令后出现的“闪烁”情况，提高了用户的上麦体验。

在多个客户端对同一个麦位申请上麦时，会触发麦位竞争的情况，由于每个客户端想要上麦需要通过一系列的流程才能实现，在此过程中可能有其他用户申请同一个麦位，导致两者发生冲突，影响程序的顺利执行。

基于此，在本公开的再一些实施例中，可以利用Redis在API服务器204内为每个麦位设置分布式锁，API服务器204接收到第一客户端200针对目标麦位的上麦请求后，在目标麦位的分布式锁未被分配的情况下，将分布式锁分配给第一客户端200，此时目标麦位被第一客户端200锁定，在第一客户端200接收到分布式锁的情况下，才能够基于第一客户端200发送的上麦请求生成的直播间进入请求发送至信令服务器206。

后续API服务器204再接收到其他客户端针对目标麦位的上麦请求时，由于分布式锁已被分配，因此后续的客户端无法获取分布式锁，也就无法在目标麦位上进行上麦。其他客户端若想要在目标麦位上进行上麦的话，需要等待第一客户端200下麦，释放分布式锁之后，才能进行。这种方式下，能够避免多个客户端申请同一个麦位导致的麦位竞争的问题，进而避免麦位竞争导致的程序错误的情况出现。

由于直播系统中的各个服务器会执行各种任务，通常需要向直播系统内的数据库进行访问，来获取相关的数据，如图6所示，图6是根据一示例性实施例示出的数据库访问示意图。为了减小多个任务进程同时对数据库进行访问时，给数据库造成的较大压力。

基于此，图7是根据一示例性实施例示出的一种数据处理方法的流程图，如图7所示，数据处理方法用于上述直播系统中，包括以下步骤。

S700，第一服务器705发送目标任务对应的数据请求至rpc服务器701；

这里的目标任务以及数据请求与第一服务器705的类型有关。例如，第一服务器705为麦序清理服务器，目标任务为麦序清理任务，则数据请求为查询直播间状态数据和用户状态数据的请求。

S702，rpc服务器701根据数据请求访问数据库703；

S704，数据库703返回数据请求对应的目标任务数据至rpc服务器701；

这里的目标任务数据为数据库703根据数据请求返回的数据，例如直播间状态数据和用户状态数据。

此外，可选的，rpc服务器701在接收到数据请求后，还可首先查询自身是否保存有数据请求对应的目标任务数据，若有，则rpc服务器701不需要访问数据库703，直接将自身保存的目标任务数据返回第一服务器705即可，若rpc服务器701未保存有目标任务数据，才需要执行上述S702的步骤。

S706，rpc服务器701将目标任务数据发送至第一服务器705；

S708，第一服务器705根据任务数据执行目标任务。

在本实施例中，各个第一服务器705发送的数据请求均发送至rpc服务器701，而非数据库703，数据库703仅需要接收rpc服务器701发送的请求即可，因此这种方式减少了数据库703需要接收请求的对象数量，降低了数据库703的服务压力。

在本公开一些实施例中，第一服务器705可以包括麦位清理服务器；麦位清理服务器用于执行麦位清理操作，麦位清理操作是用于定时检测直播系统中未关闭的各个聊天室直播间的状态以及每个直播间内的各个用户的状态，例如通过心跳连接检测用户的网络连接状态等，并对已经掉线的用户或直播间进行清理。

在直播间数量较多的情况下，若仅设置一个麦位清理进程的话，会导致整个麦位清理需要较长的时间，严重影响了麦位状态，基于此，在麦位清理服务器发送麦位清理请求至rpc服务器701之前，还可以包括：

麦位清理服务器为各个麦位清理进程分配不同的任务直播间；以使各个麦位清理进程并行执行对所分配的任务直播间的麦位状态清理操作。

在本实施例中，采用分片任务框架，设置多个麦位清理进程，分别并行清理不同的任务直播间，实现分片清理的目的，从而提高麦位清理的效率，缩短每个周期内的麦位清理时间，尽可能避免对麦位状态造成影响。其中，麦位清理进程的数量可以根据直播间数量进行动态设置，即直播间数量较多的情况下，则麦位清理进程也设置较多，直播间数量较少的情况下，麦位清理进程也可以设置较少。

rpc服务器701会利用定时任务来对自身保存的数据进行全量更新，但是由于全量更新数据量大，因此需要较长的时间，基于此，在另一些实施例中，参见图8所示，图8是根据一示例性实施例示出的一种rpc服务器701增量更新的流程示意图。该方法还包括：

数据库703(DB)输出消息通知binlog；消息通知用于指示数据库703中的更新情况，即哪些内容进行了更新，更新后的内容是什么等。

分布式存储设备(Redis pub/sub，即分布式存储设备的发布/订阅功能)获取数据库703输出的binlog，并进行发布；

rpc服务器701监听分布式存储设备发布的数据库703的消息通知；具体利用RedissubClient功能进行订阅监听；

rpc服务器701根据消息通知更新自身保存的直播间状态和各个直播间内的用户状态；此过程即为增量更新；puller Thread功能进行全量更新。

麦位清理服务器根据更新后的直播间状态和用户状态进行麦位状态清理。

本实施例中，rpc服务器701会根据数据库703的消息通知进行增量更新，即仅更新消息通知中提到的部分，这种情况下，由于更新的数据量小，因此缩短了数据更新的时间，使得麦位清理服务器能够尽可能准确的获取直播间状态和用户状态，从而提高了麦位清理过程的准确性，避免了无效的清理操作，提高了清理效率。

举例来看，假设rpc服务器701全量更新的周期为10s，若在上一次全量更新后2s内，发生了直播间状态变化，但是由于没有到下一全量更新的时间，故此时麦位清理服务器还是利用上一周期的旧数据进行麦位清理，从而导致清理出现错误；此时若rpc服务器701根据数据库703的消息通知进行了增量更新，在自身保存的数据中，修改了发生变化的直播间的状态信息，这样使得麦位清理服务器能够根据正确的数据进行麦位清理。

基于上述连麦方法，以下分别对直播系统中各个组成部分的具体工作内容介绍；其中部分内容已在上述连麦方法实施例中进行阐述，因此在后续各个组成部分的工作内容介绍中，不再重复介绍。

图9是根据一示例性实施例示出的一种API服务器侧的连麦方法的流程图，如图9所示，该方法包括以下步骤。

S900，接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求；上麦请求包括第一客户端的第一端口信息；

S902，将基于上麦请求生成的直播间进入请求发送至信令服务器；直播间进入请求包括第一端口信息；以使信令服务器根据直播间进入请求从媒体控制服务器中获取配置信息，且媒体控制服务器保存第一端口信息；

S904，接收信令服务器返回的配置信息；配置信息包括目标直播间的房间地址；

S906，返回配置信息至第一客户端，以使第一客户端根据房间地址上传第一音频流至媒体控制服务器，目标直播间内的第二客户端根据媒体控制服务器广播的第一端口信息获取媒体控制服务器中的第一音频流，完成第一客户端与第二客户端之间的连麦。

在一些实施例中，S900之后，S902之前，还可以包括：

在目标麦位的分布式锁未被分配的情况下，将分布式锁分配给第一客户端；

S902可以包括：在第一客户端接收到分布式锁的情况下，将基于上麦请求生成的直播间进入请求发送至信令服务器。

这种方式下，能够避免多个客户端申请同一个麦位导致的麦位竞争的问题，进而避免麦位竞争导致的程序错误的情况出现。

在另一些实施例中，S900之后，还可以包括：为第一客户端分配第一版本号；

S906之后，还可以包括：

接收第一客户端在得到配置信息后返回的进入成功响应；

根据进入成功响应，将第一客户端的第一用户状态信息发送至麦序表；其中，第一用户状态信息包括第一版本号；其中，第一版本号用于使麦序表更新麦位信息中目标麦位对应的目标版本号，以使第一客户端接收长连接服务器发送的麦位信令后，在麦位信令中包含的目标版本号大于第一版本号的情况下，利用麦位信令中目标麦位对应的客户端的用户头像，更新目标麦位上显示的用户头像；麦位信令为长连接服务器根据麦位信息生成的信令。

本实施例的方式可以保证自第一客户端的用户头像显示至目标麦位后，即使长连接服务器发送的麦位信令是基于麦序表未更新时的麦位信息生成的，也不会导致用户头像从目标麦位上消失，避免了出现用户头像在本次接收到麦位信令后消失，下次接收到麦位信令后出现的“闪烁”情况，提高了用户的上麦体验。

图10是根据一示例性实施例示出的一种第一客户端侧的连麦方法的流程图，如图10所示，该方法包括以下步骤。

S1000，向API服务器发送针对目标直播间内的目标麦位的上麦请求；上麦请求包括第一客户端的第一端口信息；

S1002，接收API服务器返回的配置信息；配置信息包括目标直播间的房间地址；

S1004，根据房间地址上传第一音频流至媒体控制服务器，以使目标直播间内的第二客户端根据媒体控制服务器广播的第一端口信息获取媒体控制服务器中的第一音频流，完成第一客户端与第二客户端之间的连麦。

在本实施例中，在API服务器接收到第一客户端发送的针对目标麦位的上麦请求后，API服务器会通过信令服务器向媒体控制服务器获取配置信息，之后直接返回配置信息至第一客户端，第一客户端能够根据配置信息完成直播间配置，从而完成与第二客户端之间的连麦，实现上麦的目的。即本实施例中，能够直接通过API服务器下发配置信息，不需要根据长连接服务器下发的网络电话信令完成直播间配置，简化了客户端上麦过程中，长连接服务器下发网络电话信令的步骤，缩短了上麦路径。

在一些实施例中，上述配置信息还包括目标直播间中的第二客户端的第二端口信息；S1002之后，还可以包括：

根据第二端口信息，从媒体控制服务器中获取第二客户端上传的第二音频流。

本实施例中，第一客户端能够通过配置信息来获取目标直播间中其他第二客户端的第二端口信息，后续第一客户端能够根据第二端口信息来获取第二客户端上传的第二音频流。这种情况下，使得目标直播间内的麦上客户端均能够获取对方发送的音频流并能够将自身音频流发送至对方，从而实现连麦的目的。

在另一些实施例中，S1004之后，还可以包括：

在目标麦位上显示第一客户端的用户头像。

即本实施例中，第一客户端在不需要等待麦位信令，而是可以直接将用户头像显示至目标麦位上，使得用户点击即上麦成为现实，提高了用户的上麦体验。

在另一些实施例中，S1000之后，还可以包括：

接收API服务器分配的第一版本号；

S1004之后，还可以包括：

返回进入成功响应至API服务器；以使API服务器根据进入成功响应，发送第一客户端的第一用户状态信息至麦序表；其中，第一用户状态信息包括第一版本号；第一版本号用于使麦序表更新麦位信息中目标麦位对应的目标版本号；

上述在目标麦位上显示第一客户端的用户头像之后，还可以包括：

接收长连接服务器发送的麦位信令；麦位信令为长连接服务器根据麦位信息生成的信令；

在麦位信令中包含的目标麦位的目标版本号大于第一版本号的情况下，利用麦位信令中目标麦位对应的客户端的用户头像，更新目标麦位上显示的用户头像。

图11是根据一示例性实施例示出的一种媒体控制服务器侧的连麦方法的流程图，如图11所示，该方法包括以下步骤。

S1100，接收信令服务器发送的针对目标直播间的信息获取请求；信息获取请求包括第一客户端的第一端口信息；

S1102，保存第一端口信息；

S1104，根据信息获取请求，向信令服务器返回配置信息，配置信息包括目标直播间的房间地址；以使信令服务器通过应用程序编程接口API服务器向第一客户端返回配置信息。

其中，S1102和S1104之间没有先后顺序的限定。

S1106，接收第一客户端根据房间地址上传的第一音频流；

S1108，广播第一端口信息，以使目标直播间内的第二客户端根据第一端口信息获取第一音频流，完成第一客户端与第二客户端之间的连麦。

本实施例中，第一客户端的第一端口信息由媒体控制服务器发送，通过长连接服务器发送的方式，缩短了传输路径，通过减少一轮长连接的耗时，减少了信息传输所需的时间。

在一些实施例中，上述配置信息还包括目标直播间中的第二客户端的第二端口信息；方法还包括：

接收第二客户端上传的第二音频流；以使第一客户端根据第二端口信息，从媒体控制服务器中获取第二音频流。

图12是根据一示例性实施例示出的一种第一服务器侧的数据处理方法的流程图，如图12所示，该方法包括以下步骤。

S1200，发送目标任务对应的数据请求至远程过程调用协议rpc服务器；

S1202，接收rpc服务器返回的目标任务数据，目标任务数据包括rpc服务器根据数据请求访问数据库后获取的数据；

S1204，根据任务数据执行目标任务。

在本实施例中，各个第一服务器发送的数据请求均发送至rpc服务器，而非数据库，数据库仅需要接收rpc服务器发送的请求即可，因此这种方式减少了数据库需要接收请求的对象数量，降低了数据库的服务压力。

可选的，第一服务器包括麦位清理服务器；S1200之前，还可以包括：

为各个麦位清理进程分配不同的任务直播间；以使各个麦位清理进程并行执行对所分配的任务直播间的麦位状态清理操作。

在本实施例中，采用分片任务框架，设置多个麦位清理进程，分别并行清理不同的任务直播间，实现分片清理的目的，从而提高麦位清理的效率，缩短每个周期内的麦位清理时间，尽可能避免对麦位状态造成影响。

图13是根据一示例性实施例示出的一种rpc服务侧的数据处理方法的流程图，如图13所示，该方法括以下步骤。

S1300，接收第一服务器发送的目标任务对应的数据请求；

S1302，根据数据请求访问数据库，得到目标任务数据；

S1304，将目标任务数据发送至第一服务器，以使第一服务器根据目标任务数据执行目标任务。

可选的，上述方法还包括：

监听分布式存储设备发布的数据库的消息通知；

根据消息通知更新自身保存的直播间状态和各个直播间内的用户状态，以使麦位清理服务器根据更新后的直播间状态和用户状态进行麦位状态清理。

本实施例中，rpc服务器会根据数据库的消息通知进行增量更新，即仅更新消息通知中提到的部分，这种情况下，由于更新的数据量小，因此缩短了数据更新的时间，使得麦位清理服务器能够尽可能准确的获取直播间状态和用户状态，从而提高了麦位清理过程的准确性，避免了无效的清理操作，提高了清理效率。

基于同一发明构思，图14是根据一示例性实施例示出的一种API服务器侧的连麦装置框图。参照图14，该装置包括上麦接收模块1400，信令请求模块1402，第一配置接收模块1404和第一配置返回模块1406。

上麦接收模块1400，被配置为接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求；上麦请求包括第一客户端的第一端口信息；

信令请求模块1402，被配置为将基于上麦请求生成的直播间进入请求发送至信令服务器，直播间进入请求包括第一端口信息；以使信令服务器根据直播间进入请求从媒体控制服务器中获取配置信息，且媒体控制服务器保存第一端口信息；配置信息包括目标直播间的房间地址；

第一配置接收模块1404，被配置为接收信令服务器返回的配置信息；

第一配置返回模块1406，被配置为返回配置信息至第一客户端，以使第一客户端根据房间地址上传第一音频流至媒体控制服务器，目标直播间内的第二客户端根据媒体控制服务器广播的第一端口信息获取媒体控制服务器中的第一音频流，完成第一客户端与第二客户端之间的连麦。

在本实施例中，能够直接通过API服务器下发配置信息，不需要根据长连接服务器下发的网络电话信令完成直播间配置，简化了客户端上麦过程中，长连接服务器下发网络电话信令的步骤，缩短了上麦路径；并且，API服务器也不需要在主播同意后再下发配置信息，简化了观众申请上麦的流程，缩短了观众上麦时的等待时间，提高了观众的上麦体验。

可选的，上述连麦装置还包括：

锁分配模块，被配置为执行在目标麦位的分布式锁未被分配的情况下，将分布式锁分配给第一客户端；

信令请求模块1402，被配置为具体执行在第一客户端接收到分布式锁的情况下，基于上麦请求生成的直播间进入请求发送至信令服务器。

可选的，上述连麦装置还包括：

版本号分配模块，被配置为执行为第一客户端分配第一版本号；

响应接收模块，被配置为接收第一客户端在得到配置信息后返回的进入成功响应；

第一状态发送模块，被配置为执行根据进入成功响应，将第一客户端的第一用户状态信息发送至麦序表；其中，第一用户状态信息包括第一版本号；其中，第一版本号用于使麦序表更新麦位信息中目标麦位对应的目标版本号，以使第一客户端接收长连接服务器发送的麦位信令后，在麦位信令中包含的目标版本号大于第一版本号的情况下，利用麦位信令中目标麦位对应的客户端的用户头像，更新目标麦位上显示的用户头像；麦位信令为长连接服务器根据麦位信息生成的信令。

基于同一发明构思，图15是根据一示例性实施例示出的一种第一客户端侧的连麦装置框图。参照图15，该装置包括上麦请求模块1500，第二配置接收模块1502和配置模块1504。

上麦请求模块1500，被配置为执行向应用程序编程接口API服务器发送针对目标直播间内的目标麦位的上麦请求；上麦请求包括第一客户端的第一端口信息；

第二配置接收模块1502，被配置为接收API服务器返回的配置信息；配置信息包括目标直播间的房间地址；

配置模块1504，被配置为执行根据房间地址上传第一音频流至媒体控制服务器，以使目标直播间内的第二客户端根据媒体控制服务器广播的第一端口信息获取媒体控制服务器中的第一音频流，完成第一客户端与第二客户端之间的连麦。

可选的，上述装置还包括：

音频获取模块，被配置为执行根据第二端口信息，从媒体控制服务器中获取第二客户端上传的第二音频流。

可选的，上述装置还包括：

头像显示模块，被配置为执行在目标麦位上显示第一客户端的用户头像。

本实施例中，第一客户端不需要等待麦位信令，而是可以直接将用户头像显示至目标麦位上，使得用户点击即上麦成为现实，提高了用户的上麦体验。

可选的，上述装置还包括：

版本号接收模块，被配置为接收API服务器分配的第一版本号；

响应返回模块，被配置为返回进入成功响应至API服务器；以使API服务器根据进入成功响应，将第一客户端的第一用户状态信息发送至麦序表；其中，第一用户状态信息包括第一版本号，第一版本号用于使麦序表更新麦位信息中目标麦位对应的目标版本号；

头像更新模块，被配置为在麦位信令中包含的目标版本号大于第一版本号的情况下，利用麦位信令中目标麦位对应的客户端的用户头像，更新目标麦位上显示的用户头像；麦位信令为长连接服务器根据麦位信息生成的信令。

基于同一发明构思，图16是根据一示例性实施例示出的一种媒体控制服务器侧的连麦装置框图。参照图16，该装置包括信息获取模块1600，第二配置返回模块1602和广播模块1604。

信息获取模块1600，被配置为执行接收信令服务器发送的针对目标直播间的信息获取请求；信息获取请求包括第一客户端的第一端口信息；

端口保存模块1602，被配置为执行保存第一端口信息；

第二配置返回模块1604，被配置为执行根据信息获取请求，向信令服务器返回配置信息，配置信息包括目标直播间的房间地址；以使信令服务器通过应用程序编程接口API服务器向第一客户端返回配置信息；

第一音频接收模块1606，被配置为执行接收第一客户端根据房间地址上传的第一音频流；

广播模块1608，被配置为执行广播第一端口信息，以使目标直播间内的第二客户端根据第一端口信息获取第一音频流，完成第一客户端与第二客户端之间的连麦。

可选的，上述装置还可以包括：

第二音频接收模块，被配置为执行接收第二客户端上传的第二音频流；以使第一客户端根据第二端口信息，从媒体控制服务器中获取第二音频流。

基于同一发明构思，图17是根据一示例性实施例示出的一种第一服务器侧的数据处理装置框图。参照图17，该装置包括数据请求模块1700，数据接收模块1702和任务执行模块1704。

数据请求模块1700，被配置为发送目标任务对应的数据请求至rpc服务器；

数据接收模块1702，被配置为接收rpc服务器返回的目标任务数据，目标任务数据包括rpc服务器根据数据请求访问数据库后获取的数据；

任务执行模块1704，被配置为根据任务数据执行目标任务。

可选的，第一服务器包括麦位清理服务器；装置还包括：

直播间分配模块，被配置为执行为各个麦位清理进程分配不同的任务直播间；以使各个麦位清理进程并行执行对所分配的任务直播间的麦位状态清理操作。

基于同一发明构思，图18是根据一示例性实施例示出的一种rpc服务器侧的数据处理装置框图。参照图18，该装置包括数据请求接收模块1800，访问模块1802和数据发送模块1804。

数据请求接收模块1800，被配置为接收第一服务器发送的目标任务对应的数据请求；

访问模块1802，被配置为执行根据数据请求访问数据库，得到目标任务数据；

数据发送模块1804，被配置为执行将目标任务数据发送至第一服务器，以使第一服务器根据目标任务数据执行目标任务。

可选的，上述装置还包括：

监听模块，被配置为监听分布式存储设备发布的数据库的消息通知；

状态更新模块，被配置为根据消息通知更新自身保存的直播间状态和各个直播间内的用户状态，以使麦位清理服务器根据更新后的直播间状态和用户状态进行麦位状态清理。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图19是根据一示例性实施例示出的一种服务器的框图。

基于同一发明构思，在示例性实施例中，还提供了一种服务器190，包括：处理器1900、通信接口1906、用于存储所述处理器1900可执行指令的存储器1904和通信总线1902；其中，所述处理器1900被配置为执行所述指令，以实现上述方法中服务器190实现的步骤。其中，处理器1900、通信接口1906和存储器1904通过通信总线1902完成相互间的通信。

图20是根据一示例性实施例示出的一种电子设备的框图。

基于同一发明构思，在示例性实施例中，还提供了一种电子设备，包括：处理组件2002，存储器2004，电力组件2006，多媒体组件2008，音频组件2010，输入/输出(I/O)的接口2012，传感器组件2014，以及通信组件2016。

处理组件2002可以包括一个或多个处理器2020来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件2002可以包括一个或多个模块，便于处理组件2002和其他组件之间的交互。例如，处理组件2002可以包括多媒体模块，以方便多媒体组件2008和处理组件2002之间的交互。

存储器2004被配置为存储各种类型的数据以支持在电子设备的操作。这些数据的示例包括用于在装置2000上操作的任何应用程序或方法的指令。存储器2004可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件2006为装置2000的各种组件提供电力。电源组件2006可以包括电源管理系统，一个或多个电源，及其他与为装置2000生成、管理和分配电力相关联的组件。

基于同一发明构思，在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器，上述指令可由上述服务器或电子设备的处理器执行以完成上述方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims

1.一种连麦方法，应用于应用程序编程接口API服务器，其特征在于，包括：

接收所述信令服务器返回的所述配置信息；

返回所述配置信息至所述第一客户端，以使所述第一客户端根据所述房间地址上传第一音频流至所述媒体控制服务器，所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦；

所述接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求之后，还包括：

为所述第一客户端分配第一版本号；

所述返回所述配置信息至所述第一客户端之后，还包括：

2.根据权利要求1所述的方法，其特征在于，所述接收第一客户端发送的针对目标直播间内的目标麦位的上麦请求之后，将基于所述上麦请求生成的直播间进入请求发送至信令服务器之前，还包括：

3.一种连麦方法，应用于第一客户端，其特征在于，包括：

根据所述房间地址上传第一音频流至媒体控制服务器，以使所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦；

所述接收API服务器返回的配置信息之后，还包括：

在所述目标麦位上显示所述第一客户端的用户头像；

所述向应用程序编程接口API服务器发送针对目标直播间内的目标麦位的上麦请求之后，还包括：

接收所述API服务器分配的第一版本号；

所述接收API服务器返回的配置信息之后，还包括：

4.根据权利要求3所述的方法，其特征在于，所述配置信息还包括所述目标直播间中的所述第二客户端的第二端口信息；所述接收API服务器返回的配置信息之后，还包括：

5.一种连麦方法，所述方法包括：

所述API服务器将基于所述上麦请求生成的直播间进入请求发送至信令服务器；所述直播间进入请求包括所述第一端口信息；

所述信令服务器将基于所述直播间进入请求生成的信息获取请求发送至媒体控制服务器；所述信息获取请求包括所述第一端口信息；

所述API服务器返回所述配置信息至所述第一客户端；

所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦；

所述第一客户端在接收到所述配置信息后，在所述目标麦位上显示所述第一客户端的用户头像；

所述第一客户端向API服务器发送针对目标直播间内的目标麦位的上麦请求之后，还包括：

所述API服务器为所述第一客户端分配第一版本号；

所述第一客户端接收长连接服务器发送的麦位信令；

6.根据权利要求5所述的方法，其特征在于，所述配置信息还包括所述目标直播间中的所述第二客户端的第二端口信息；所述API服务器返回所述配置信息至所述第一客户端之后，还包括：

所述第二客户端上传第二音频流至所述媒体控制服务器；

7.一种连麦装置，应用于应用程序编程接口API服务器，其特征在于，包括：

第一配置返回模块，被配置为返回所述配置信息至所述第一客户端，以使所述第一客户端根据所述房间地址上传第一音频流至所述媒体控制服务器，所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦；

所述连麦装置还包括：

8.根据权利要求7所述的连麦装置，其特征在于，所述连麦装置还包括：

9.一种连麦装置，应用于第一客户端，其特征在于，包括：

配置模块，被配置为执行根据所述房间地址上传第一音频流至媒体控制服务器，以使所述目标直播间内的第二客户端根据所述媒体控制服务器广播的所述第一端口信息获取所述媒体控制服务器中的所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦；

所述连麦装置还包括：

头像显示模块，被配置为在所述目标麦位上显示所述第一客户端的用户头像；

10.根据权利要求9所述的连麦装置，其特征在于，所述配置信息还包括所述目标直播间中的所述第二客户端的第二端口信息，所述装置还包括：

11.一种服务器，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1或2所述的连麦方法。

12.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求3或4所述的连麦方法。

13.一种直播系统，其特征在于，包括：

应用程序编程接口API服务器，被配置为执行如权利要求1或2所述的连麦方法；

第一客户端，被配置为执行如权利要求3或4所述的连麦方法；

媒体控制服务器，被配置为接收信令服务器发送的针对目标直播间的信息获取请求；所述信息获取请求包括第一客户端的第一端口信息；保存所述第一端口信息；根据所述信息获取请求，向所述信令服务器返回配置信息，所述配置信息包括所述目标直播间的房间地址；以使所述信令服务器通过应用程序编程接口API服务器向所述第一客户端返回所述配置信息；接收所述第一客户端根据所述房间地址上传的第一音频流；广播所述第一端口信息，以使所述目标直播间内的第二客户端根据所述第一端口信息获取所述第一音频流，完成所述第一客户端与所述第二客户端之间的连麦；

长连接服务器，被配置为从麦序表获取麦位信息；根据所述麦位信息生成麦位信令；将所述麦位信令发送至所述目标直播间内的各个客户端；所述麦位信令中包括目标麦位对应的目标版本号；

分布式存储设备，被配置为存储所述麦序表，所述麦序表中保存有所述麦位信息，所述麦位信息中包括所述目标麦位对应的所述目标版本号。

14.一种存储介质，其特征在于，当所述存储介质中的指令由服务器的处理器执行时，使得所述服务器能够执行如权利要求1或2所述的连麦方法；当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求3或4所述的连麦方法。