WO2017166485A1 - 对直播消息的发布进行优化的方法及系统 - Google Patents

对直播消息的发布进行优化的方法及系统 Download PDF

Info

Publication number
WO2017166485A1
WO2017166485A1 PCT/CN2016/088909 CN2016088909W WO2017166485A1 WO 2017166485 A1 WO2017166485 A1 WO 2017166485A1 CN 2016088909 W CN2016088909 W CN 2016088909W WO 2017166485 A1 WO2017166485 A1 WO 2017166485A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
queue
live broadcast
live
pool
Prior art date
Application number
PCT/CN2016/088909
Other languages
English (en)
French (fr)
Inventor
刘斌
Original Assignee
乐视控股（北京）有限公司
乐视云计算有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 乐视控股（北京）有限公司, 乐视云计算有限公司 filed Critical 乐视控股（北京）有限公司
Priority to US15/246,250 priority Critical patent/US20170289583A1/en
Publication of WO2017166485A1 publication Critical patent/WO2017166485A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26283—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for associating distribution time parameters to content, e.g. to generate electronic program guide data

Definitions

  • the embodiments of the present invention relate to the field of video live broadcast technologies, and in particular, to a method and system for optimizing broadcast of a live message.
  • the inventors have found that the prior art has at least the following problems:
  • the number of streams reaches tens of thousands, on the one hand, the number of local ports of the operating system is limited, on the other hand, The establishment of a large number of TCP sockets gradually increases the resource overhead of the operating system, which in turn leads to limited stand-alone service capabilities.
  • the connection challenge to the message publishing pool will become larger and larger, which will further drag down the ability of the message publishing pool to publish messages.
  • the embodiment of the invention provides a method and a system for optimizing the release of a live message, so as to solve the traditional live broadcast platform, each flow process or thread must establish a TCP long connection with the message release pool, and when there are many flow processes or threads,
  • the system resources are expensive, the single-node service capability is limited, and the problem of the ability of the message publishing pool to publish messages is greatly improved, which greatly improves the load capacity of the online device and the ability of the message publishing pool to release messages.
  • the embodiment of the invention provides a method for optimizing the release of a live message, including:
  • the component for producing a stream generates a live broadcast message, and sends the live broadcast message to the message relay station;
  • the message relay station sends the received live broadcast message to the message publishing pool.
  • the embodiment of the invention provides a system for optimizing the release of a live message, comprising a message publishing pool for publishing a live message and a component for a production stream, the message publishing pool and the component for the production stream. There is also a message transfer station between them,
  • the component generating live stream message is sent to the message relay station, and the message relay station receives the live broadcast message and sends the message to the message publishing pool.
  • the method and system for optimizing the release of a live message provided by the embodiment of the present invention effectively increase the load capacity and message release of the online device by adding a message transfer station between the component for producing the live message flow file and the message release pool.
  • the ability of the pool to publish messages to the outside world reduces the difficulty of docking between components of the production stream and the message publishing pool.
  • FIG. 1 is a structural diagram of a system for performing a live broadcast message release in the prior art
  • FIG. 2 is a schematic structural diagram of an embodiment of a system for optimizing broadcast of a live message according to the present invention
  • FIG. 3 is a flowchart of an embodiment of a method for optimizing broadcast of a live message according to the present invention.
  • FIG. 1 schematically shows a framework structure of a system for performing broadcast of a live broadcast message in the prior art. Since the production of one stream corresponds to a process or thread, as shown in Figure 1, the component 2 for the production stream is typically the process group 20 and the thread group 21 of the production stream, each process group 20 comprising a plurality of production streams.
  • the process 201 (for example, the Hls_creator process in the figure, that is, a production process that converts live streams of various protocols into a specific internal hls protocol, can generate an m3u8 file with ts), and each thread group 21 includes multiple The thread 211 of the production stream (for example, the Thread thread in the figure, that is, a carousel production thread that converts various live streams and on-demand files into a live hls protocol, and can generate an m3u8 file).
  • the hls (http live streaming, real-time streaming protocol) protocol is a streaming media protocol, which is implemented based on the HTTP protocol.
  • the transmission content includes two parts, one is a m3u8 description file, and the other is a ts media file.
  • each process 201 or thread 211 needs to establish a TCP long connection with the local message publishing pool 1 (ie, the message publishing pool) (each bidirectional in FIG. 1).
  • the arrows all represent a TCP connection), and the generated live message is sent to the message publishing pool 1 through the TCP long connection, and then the live message is published by the message publishing pool 1. Therefore, when the number of live streams of a single machine is increasing, especially after reaching tens of thousands, on the one hand, the number of native ports of the operating system is limited, and on the other hand, the establishment of a large number of TCP sockets.
  • the overhead of operating system resources will be increased, which will further limit the ability of single-server services, and the connection challenges to the message publishing pool will become larger and larger, and will drag down the ability of the message publishing pool to publish messages.
  • the present invention proposes a system and method for optimizing the release of a live message to solve the defects of the conventional publishing architecture and method.
  • FIG. 2 schematically shows a framework structure of a system for optimizing the distribution of a live message according to an embodiment of the present invention.
  • the system is further provided with a message relay station 3 between the message issuance pool 1 for distributing live messages and the component 2 for producing streams.
  • the process group 20 and the thread group 21 in the component 2 send the live broadcast message to the message transfer station 3 first, and the message transfer station 3 sends the live broadcast message to the message release pool. 1 to publish.
  • each process 201 and thread 211 will no longer need to establish a TCP connection directly with the message publishing pool 1, but will send a message to the message relay station 3.
  • the component 2 for the production stream sends a live broadcast message to the message relay station 3 through a PosixMQ (Portable Operating System Interface Message Queue).
  • the Posix message queue The component 2 for the production stream includes a message writing unit (not shown) for writing the generated live broadcast message to the local Posix message queue.
  • the message relay station 3 includes a message reading unit 30 for reading a live message from the Posix message queue and inserting the live message into the message relay queue.
  • the message writing unit in the embodiment of the present invention may be a process or a thread itself of each production stream, and the message reading unit 30 may be a thread opened separately by the message relay station 3.
  • Each process and thread can directly read and write to the local Posix message queue (the dotted arrow in the figure is the read and write operation of the Posix message queue by the thread or process), and does not need to establish a TCP connection for transmission.
  • the system overhead is minimal, which can greatly increase the load capacity of online devices.
  • the message relay station 3 further includes a message sending unit 31 for establishing a fixed number of TCP connections between the station 3 and the message issuing pool 1 in the message, and forwarding the message in real time or at regular intervals. All live messages in the message are sent to the message publishing pool 1 over a TCP connection.
  • the message sending unit 31 establishes a limited number of TCP connections with the message release pool, and sends all the live broadcast messages in the message transfer queue to the message release pool in real time. 1, issued by the message release pool 1.
  • the message sending unit 31 continuously sends the live broadcast message in the message transfer queue, and in order to ensure the performance of the system, it can be set to wait for the fixed time when the message transfer queue is empty. After the time interval is 200 milliseconds, it is detected whether there is content in the message relay queue. If there is content, all the live messages in the message relay queue are sent out. If there is no content, wait for a fixed time interval, such as 200 milliseconds, before detecting.
  • the number of TCP connections established between the message sending unit 1 and the message issuance pool 1 can be set according to requirements. For example, when the amount of data is large, five pieces are established, and the amount of data is established one hour. This can reduce system overhead. Preferably, the number of established TCP connections is one, and this time online The system overhead of the device is the smallest, that is, 1/N of the original deployment cost, and N is the total number of processes and threads in component 2 of the production flow.
  • each process or thread in the component 2 for the production stream writes the live message to the Posix message queue, for example,
  • the transmission format of the written live message is set to the json format. That is, the message writing unit first encapsulates the live message into the json format, and encapsulates the generation time, the serial number, the type of the m3u8 (including the live broadcast and the carousel) and the release theme of the m3u8 file corresponding to the live message in the json format message. Address (Which topic is to be sent to the message publishing pool, such as relay/hls/lunbo/lb_zonghe_1300).
  • the message writing unit can write the encapsulated live message to the Posix message queue in the order of the serial number, and the message reading unit can also read the data in the json format from the Posix message queue.
  • the live broadcast message is inserted into the message relay queue by serial number, so that the order of the live broadcast message can be guaranteed, the confusion or the skip broadcast can be prevented, and the fast and accurate release to the destination can be ensured.
  • the message release pool, the component of the user production stream, and the message relay station may be a server or a server cluster, wherein each unit may be a separate server or a server cluster.
  • the interaction between the above units is represented by an interaction between servers or server clusters corresponding to the units, and the plurality of servers or server clusters together constitute a system for optimizing the issuance of live messages according to the present invention.
  • the system in which the multiple servers or server clusters together constitute the optimization of the release of the live broadcast message of the present invention includes:
  • the message is written to the server or server cluster and configured to write the generated live message to the message queue of the component for the production stream;
  • a message reading server or a server cluster configured to read a live broadcast message from a message queue of a component for a production stream, and insert the live broadcast message into a message relay queue of the message relay station;
  • a message sending server or a server cluster configured to establish a fixed number of TCP connections between the relay station and the message publishing pool, and send the live broadcast message to the message publishing pool in real time through the TCP connection, or in the event that the message is detected
  • the message relay queue is detected again every fixed time interval, and when the message transfer queue is not empty, all the live messages in the message transfer queue are sent through the TCP connection. To the message publishing pool.
  • the message writing unit constitutes a first server or a first server cluster
  • the message reading unit and the message sending unit together form a second server or a second server cluster.
  • the interaction between the above units is represented by an interaction between the first server and each of the second servers or an interaction between the first server cluster and the second server cluster, the first server and the second server or the first
  • the server cluster and the second server cluster together constitute a system for optimizing the distribution of live messages of the present invention.
  • FIG. 3 is a schematic flowchart showing a method for optimizing the release of a live message according to an embodiment of the present invention. As shown in FIG. 3, the method includes:
  • Step S301 Configure a message relay station between the message publishing pool for publishing the live message and the component for the production stream.
  • the component used for the production stream generates a live message
  • the message publishing pool publishes the generated live message.
  • the component of the production stream is mainly a process group or a thread group
  • the message publishing pool is a module for message publishing.
  • a module (that is, a message relay station) is added between the component for the production stream and the message publishing pool, and is used for receiving the generated live message and sending the live message to the message publishing pool.
  • Step S302 Generate a live broadcast message, and send the generated live broadcast message to the message relay station.
  • Each process and thread of the component used to produce the stream generates a live broadcast message and sends a live broadcast message to the message relay station.
  • each process and thread generates a live broadcast message that is synchronously blocked, and the message transfer station is a non-blocking asynchronous relay module, so that the generated live broadcast message can be written into the Posix message queue.
  • the live broadcast message is sent to the message relay station.
  • each process and thread in the component that generates the stream generates a live broadcast message and writes to the Posix message queue, and the write process may be performed according to a specific rule.
  • the message relay station opens a separate thread responsible for reading live messages from the Posix message queue.
  • the message relay station includes a message relay queue for storing live messages read from the Posix message queue.
  • the specific rule for writing the live broadcast message may be, for example, setting the transmission format of the written live message to the json format, that is, first, the live message is encapsulated into the data of the json format, and the live message is encapsulated in the message of the json format.
  • the generation time of the m3u8 file, the serial number, the type of m3u8 (both live and carousel), and the topic location (which topic is to send the live message to the message publishing pool, such as relay/hls/lunbo/lb_zonghe_1300) From this, you can The live message is written to the Posix message queue in order and serialized into the message relay queue without confusion, and can be quickly and accurately published to the destination.
  • Step S303 The message relay station sends the received live broadcast message to the message publishing pool.
  • a limited number of TCP connections (such as one or more) are established between the relay station and the message publishing pool.
  • the message relay station sends a live message to the message publishing pool through the established TCP connection, and the message publishing pool can receive the live message. release. Under normal circumstances, the message relay station will send the data in the message relay queue to the message publishing pool in real time.
  • the message forwarding queue is detected to be empty, after waiting for a fixed time interval (for example, 200 milliseconds), the message forwarding queue is detected again, and if there is content, the message is transferred to the queue. All data in the data is sent to the message publishing pool through the TCP connection. If it is still empty, it will wait for a fixed time interval before detecting. As a result, unnecessary overhead can be reduced and system performance can be optimized.
  • the system and method of the embodiment of the present invention do not need to establish a TCP long connection between the message publishing pool and the processes and threads of the production stream, and only need to establish a limited number of TCP connections between the relay station and the message publishing pool.
  • the generated live message can be sent to the message publishing pool for publication in real time.
  • the processes and threads of the production stream no longer need to care about the TCP connection and the message notification protocol with the message publishing pool, and only need to continuously write the generated live message.
  • the local Posix message queue can effectively reduce the difficulty of connecting the threads and processes of the production stream with the message publishing pool, greatly improve the load capacity of the online devices, save deployment costs, and improve message publishing capabilities.
  • the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, ie may be located A place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without deliberate labor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明实施例提供一种对直播消息的发布进行优化的方法及系统，该方法包括：在用于发布直播消息的消息发布池与用于生产流的组件之间配置消息中转站；所述用于生产流的组件生成直播消息，并将所述直播消息发送至所述消息中转站；所述消息中转站将接收到的所述直播消息发送至所述消息发布池。本发明实施例的方法和系统提升了线上设备的负载能力和消息发布池对外发布消息的能力，降低了生产流的组件与消息发布池之间的对接难度。

Description

对直播消息的发布进行优化的方法及系统 技术领域
本发明实施例涉及视频直播技术领域，尤其涉及一种对直播消息的发布进行优化的方法及系统。
背景技术
随着互联网技术的快速发展，流媒体技术已经广泛的应用于包括实时新闻、在线视频直播、在线视频录播、远程教育、实时视频会议等业务的直播平台。由于现有线上直播平台均是按照流为基本单位来生产数据的，一个流的生产对应一个进程或线程，因此当直播流的个数越来越多时，如果按照传统的消息发布方式，就需要每个进程或线程来与本机的消息发布池(MessagerPool，设备对外发布和接收消息的模块，可以接受订阅和发布请求)建立TCP长连接通讯。
在实现本发明的过程中，发明人发现现有技术至少存在以下问题：但在流的个数达到成千上万后，一方面受限于操作系统本机端口的个数有限，另一方面，大量TCP套接字的建立对于操作系统的资源开销逐步增大，进而导致单机服务能力受限。而且，随着单机的生产流的进程数和线程数逐步增多时，对消息发布池的连接挑战将越来越大，也会进一步拖累消息发布池对外发布消息的能力。
发明内容
本发明实施例提供一种对直播消息的发布进行优化的方法和系统，以解决传统的直播平台，每个流进程或线程都要与消息发布池建立TCP长连接，流进程或线程较多时，系统资源开销大，单机服务能力受限，且影响消息发布池对外发布消息的能力的问题，达到大幅提升线上设备的负载能力和消息发布池对外发布消息的能力的效果。
本发明实施例提供一种对直播消息的发布进行优化的方法，包括：
在用于发布直播消息的消息发布池与用于生产流的组件之间配置消息中转站；
所述用于生产流的组件生成直播消息，并将所述直播消息发送至所述消息中转站；
所述消息中转站将接收到的所述直播消息发送至所述消息发布池。
本发明实施例提供一种对直播消息的发布进行优化的系统，包括用于发布直播消息的消息发布池和用于生产流的组件，在所述消息发布池和所述用于生产流的组件之间还配置有消息中转站，其中，
所述用于生产流的组件生成直播消息发送至所述消息中转站，所述消息中转站接收所述直播消息发送至所述消息发布池。
本发明实施例提供的对直播消息的发布进行优化的方法及系统，通过在进行生产直播消息流文件的组件和消息发布池之间增设消息中转站，有效提升了线上设备的负载能力和消息发布池对外发布消息的能力，降低了生产流的组件与消息发布池之间的对接难度。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为现有技术中进行直播消息发布的系统的框架结构图；
图2为本发明对直播消息的发布进行优化的系统的实施例结构示意图；
图3为本发明对直播消息的发布进行优化的方法的实施例流程图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
以下结合附图，对本发明实施例做更详细的阐述。
图1示意性地显示了现有技术中进行直播消息的发布的系统的框架结构。由于一个流的生产对应一个进程或线程，如图1所示，用于生产流的组件2一般是生产流的进程组20和线程组21，每个进程组20包括多个用于生产流的进程201(例如图中的Hls_creator进程，即是一个将各种协议的直播流转换成特定内部hls协议的生产进程，可以生成一个带ts的m3u8文件)，每个线程组21包括多个用于生产流的线程211(例如图中的Thread线程，即是一个将各种直播流、点播文件模拟转换为直播hls协议的轮播生产线程，可以生成一个m3u8文件)。需要说明的是，hls(http live streaming，实时流传输协议)协议是一种流媒体协议，基于HTTP协议实现，传输内容包括两部分，一是m3u8描述文件，二是ts媒体文件。
按照传统的直播消息的发布方式，如图1所示，需要每个进程201或线程211都与本机的消息发布池1(即消息发布池)建立TCP长连接(图1中的每个双向箭头都代表一个TCP连接)，并通过TCP长连接将生成的直播消息发送到消息发布池1，然后由消息发布池1将直播消息进行发布。因此，当单机的直播流的个数越来越多时，特别是达到成千上万个之后，一方面受限于操作系统本机端口的个数有限，另一方面大量TCP套接字的建立会增大操作系统资源的开销，必将会进一步导致单机服务能力受限，而且对消息发布池的连接挑战也将越来越大，并会拖累消息发布池的对外发布消息的能力。
因而本发明提出一种对直播消息的发布进行优化的系统和方法，以解决传统发布架构和方式的缺陷。
图2示意性地显示了本发明实施例的对直播消息的发布进行优化的系统的框架结构。如图2所示，该系统在用于发布直播消息的消息发布池1和用于生产流的组件2之间还配置有消息中转站3。根据本发明实施例的系统，组件2中的进程组20和线程组21在生成直播消息之后，会将直播消息先发送到消息中转站3，由消息中转站3将直播消息发送至消息发布池1进行发布。由此，各个进程201和线程211将不再需要单独与消息发布池1直接建立TCP连接，而是将消息发送到消息中转站3即可。由于在直播中各生产流的进程和线程是同步阻塞的，而消息中转站3是异步非阻塞的，因而只需在 消息中站3和消息发布池1之间建立有限条数的TCP连接，就可以将直播消息有序发送到消息发布池1，然后再由消息发布池1进行发布。由此，可以降低生产流的组件2与消息发布池1之间的对接困难，提高消息发布池1对外发布消息的能力。
其中，在具体实现中，如图2所示，用于生产流的组件2将直播消息发送到消息中转站3的方式是通过PosixMQ(Portable Operating System Interface Message Queue，可移植操作系统接口消息队列，以下称为Posix消息队列)。用于生产流的组件2中包括消息写入单元(图未示出)，用于将生成的直播消息写入本地的Posix消息队列。消息中转站3包括消息读取单元30，用于从Posix消息队列中读取直播消息，并将直播消息插入消息中转队列中。由于用于生产流的组件2是进程或线程，本发明实施例中的消息写入单元可以是各个生产流的进程或线程本身，消息读取单元30可以是消息中转站3单独开通的一个线程，各进程和线程可以直接对本地的Posix消息队列进行读写操作(如图中的虚线箭头即为通过线程或进程对Posix消息队列进行读写操作)，并不需要建立TCP连接进行传输，因而系统开销极小，能够大幅提升线上设备的负载能力。
如图2所示，消息中转站3中还包括消息发送单元31，用于在消息中转站3与消息发布池1之间建立固定数量的TCP连接，实时或每隔固定时间间隔将消息中转队列中的全部直播消息，通过TCP连接发送至消息发布池1。当消息中转站3将直播消息插入自己的消息中转队列中后，就通过消息发送单元31与消息发布池建立有限条数的TCP连接，实时将消息中转队列中的全部直播消息发送给消息发布池1，由消息发布池1进行发布。其中，为了保证实时性，正常情况下，消息发送单元31会持续地发送消息中转队列中的直播消息，而为了保证系统的性能，可以设置为当检测到消息中转队列为空时，则等待固定时间间隔如200毫秒后，再检测消息中转队列是否有内容，如果有内容则将消息中转队列中的直播消息全部发送出去，如果没有内容则再等待固定时间间隔如200毫秒后再进行检测。
其中，消息发送单元31建立的与消息发布池1之间的TCP连接的数量，可以根据需求进行设置，如数据量大时建立五条，数据量小时建立一条等。由此可以减少系统开销。优选地，建立的TCP连接的数量为一条，此时线上 设备的系统开销为最小，即为原有部署成本的1/N，N为生产流的组件2中的进程和线程的总条数。
其中，为了更清楚地标记各直播消息和方便快速将直播消息有序地发布给用户，用于生产流的组件2中的各进程或线程将直播消息写入Posix消息队列时，例如可以是将写入的直播消息的传输格式设置为json格式。即消息写入单元首先将直播消息封装为json格式，并在json格式的消息中封装直播消息对应的m3u8文件的生成时间、序列号、m3u8的类型(包括直播和轮播两种)以及发布主题地址(即将该直播消息发送到消息发布池中的哪个主题，例如relay/hls/lunbo/lb_zonghe_1300)。由此，可以消息写入单元就可以将封装后的直播消息按序列号的顺序写入到Posix消息队列，消息读取单元在从Posix消息队列中读取到json格式的数据后，也可以将直播消息按序列号插入至消息中转队列中，这样就能够保证直播消息的有序性，防止发生混乱或跳播，并且能保证快速准确地发布到目的地。
本实施例的对直播消息的发布进行优化的系统中，消息发布池、用户生产流的组件及消息中转站可以是一个服务器或者服务器集群，其中每个单元可以是单独的服务器或者服务器集群，此时，上述单元之间的交互表现为各单元所对应的服务器或者服务器集群之间的交互，所述多个服务器或服务器集群共同构成本发明的对直播消息的发布进行优化的系统。
具体地，所述多个服务器或服务器集群共同构成本发明的对直播消息的发布进行优化的系统包括：
消息写入服务器或者服务器集群，配置以将生成的直播消息写入用于生产流的组件的消息队列；
消息读取服务器或者服务器集群，配置以从用于生产流的组件的消息队列中读取直播消息，并将所述直播消息插入消息中转站的消息中转队列中；
消息发送服务器或者服务器集群，配置以在消息中转站与消息发布池之间建立固定数量的TCP连接，通过所述TCP连接，实时发送所述直播消息至消息发布池，或在检测到消息中转站的消息中转队列为空时，每隔固定时间间隔对所述消息中转队列进行再次检测，并在所述消息中转队列不为空时，通过所述TCP连接发送所述消息中转队列中的全部直播消息至消息发布池。
在一种替代实施例中，可以是上述多个单元中的几个单元共同组成一个 服务器或者服务器集群。例如：消息写入单元构成第一服务器或者第一服务器集群，消息读取单元和消息发送单元共同组成第二服务器或者第二服务器集群。
此时，上述单元之间的交互表现为第一服务器和各第二服务器之间的交互或者第一服务器集群和第二服务器集群之间的交互，所述第一服务器和第二服务器或第一服务器集群和第二服务器集群共同构成本发明的对直播消息的发布进行优化的系统。
图3示意性地显示了本发明实施例的对直播消息的发布进行优化的方法流程。如图3所示，该方法包括：
步骤S301：在用于发布直播消息的消息发布池与用于生产流的组件之间配置消息中转站。
用于生产流的组件生成直播消息，消息发布池将生成的直播消息发布出去，生产流的组件主要为进程组或线程组，消息发布池为消息发布的模块。在用于生产流的组件和消息发布池之间新增一个模块(即消息中转站)，用于接收产生的直播消息和将直播消息发送给消息发布池。
步骤S302：生成直播消息，并将生成的直播消息发送至消息中转站。
用于生产流的组件的各进程和线程生成直播消息，并将直播消息发送给消息中转站。由于在直播或轮播中，各进程和线程生成直播消息是同步阻塞的，而消息中转站作为中转模块，是异步非阻塞的，因而可通过将生成的直播消息写入Posix消息队列来实现将直播消息发送至消息中转站。具体为，生成流的组件中的各进程和线程产生直播消息，写入Posix消息队列，该写入过程可以是根据特定规则执行。消息中转站开通一个独立的线程，负责从Posix消息队列读取直播消息。消息中转站中包括一个消息中转队列，用于存储从Posix消息队列读取的直播消息。
其中，写入直播消息的特定规则例如可以是，将写入的直播消息的传输格式设置为json格式，即首先将直播消息封装为json格式的数据，并在json格式的消息中封装直播消息对应的m3u8文件的生成时间、序列号、m3u8的类型(包括直播和轮播两种)以及发布主题位置(即将该直播消息发送到消息发布池中的哪个主题，例如relay/hls/lunbo/lb_zonghe_1300)。由此，可以 将直播消息按序列号有序写入到Posix消息队列和插入到消息中转队列，不会发生混乱，并且能保证快速准确发布到目的地。
步骤S303：消息中转站将接收到的直播消息发送到消息发布池。
在消息中转站和消息发布池之间建立有限数量的TCP连接(如一条或多条)，消息中转站通过建立的TCP连接将直播消息发送到消息发布池，消息发布池收到直播消息就可以进行发布。正常情况下，消息中转站会实时发送消息中转队列中的数据给消息发布池。在本发明另一实施例中，可以设置为在检测到消息中转队列为空时，等待固定时间间隔(如200毫秒)后，再次检测消息中转队列是否有内容，如果有内容则将消息中转队列中的全部数据通过TCP连接发送给消息发布池，如果依然为空，则再次等待固定时间间隔后再进行检测。由此，就可以减少不必要的开销，优化系统性能。
通过本发明实施例的系统和方法，不需要在消息发布池与生产流的各进程及线程之间逐一建立TCP长连接，只需要在消息中转站与消息发布池之间建立有限数量的TCP连接，即可将生成的直播消息实时发送到消息发布池进行发布，生产流的各进程及线程不再需要关心与消息发布池的TCP连接及消息通知协议，只需源源不断地将生成的直播消息写入本地的Posix消息队列，能够有效降低生产流的线程及进程与消息发布池间的对接难度，大幅提升线上设备的负载能力，节约部署成本，提升消息发布能力。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台 计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

  1. 一种对直播消息的发布进行优化的方法，其特征在于，包括：
    在用于发布直播消息的消息发布池与用于生产流的组件之间配置消息中转站；
    所述用于生产流的组件生成直播消息，并将所述直播消息发送至所述消息中转站；
    所述消息中转站将接收到的所述直播消息发送至所述消息发布池。
  2. 根据权利要求1所述的方法，其中，所述用于生产流的组件将所述直播消息发送至所述消息中转站包括：
    所述用于生产流的组件将生成的所述直播消息写入本地的消息队列；
    所述消息中转站从所述消息队列中读取直播消息，并将所述直播消息插入消息中转队列中。
  3. 根据权利要求2所述的方法，其中，所述用于生产流的组件将生成的所述直播消息写入本地的消息队列包括：
    所述用于生产流的组件将生成的直播消息进行封装，封装的内容包括所述直播消息对应的m3u8的生成时间、序列号、m3u8的类型及发布主题位置，并将封装后的数据按序列号写入消息队列；
    所述消息中转站从所述消息队列中读取直播消息，并将所述直播消息插入消息中转队列中包括：
    所述消息中转站开设单独的线程从所述消息队列中读取直播消息，并将直播消息按序列号插入所述消息中转队列。
  4. 根据权利要求2或3所述的方法，其中，所述消息中转站将接收到的所述直播消息发送至所述消息发布池包括：
    在所述消息中转站与所述消息发布池之间建立固定数量的TCP连接；
    通过所述TCP连接，实时发送所述直播消息至所述消息发布池，或在检测到所述消息中转队列为空时，每隔固定时间间隔对所述消息中转队列进行再次检测，并在所述消息中转队列不为空时，通过所述TCP连接发送所述消 息中转队列中的全部直播消息至所述消息发布池。
  5. 根据权利要求4所述的方法，其特征在于，所述固定数量的TCP连接为一条。
  6. 一种对直播消息的发布进行优化的系统，包括用于发布直播消息的消息发布池和用于生产流的组件，其特征在于，在所述消息发布池和所述用于生产流的组件之间还配置有消息中转站，其中，
    所述用于生产流的组件生成直播消息发送至所述消息中转站，所述消息中转站接收所述直播消息发送至所述消息发布池。
  7. 根据权利要求6所述的系统，其特征在于，所述用于生产流的组件包括消息写入单元，用于将生成的直播消息写入本地的消息队列；
    所述消息中转站中包括消息读取单元，用于从所述消息队列中读取直播消息，并将所述直播消息插入消息中转队列中。
  8. 根据权利要求7所述系统，其中，所述消息写入单元用于将生成的直播消息封装的内容包括所述直播消息对应的m3u8的生成时间、序列号、m3u8的类型及发布主题位置，并将封装后的数据按序列号写入消息队列；
    所述消息读取单元用于开设单独的线程从所述消息队列中读取直播消息，并将直播消息按序列号插入所述消息中转队列。
  9. 根据权利要求7或8所述的系统，其特征在于，所述消息中转站还包括消息发送单元，用于在所述消息中转站与所述消息发布池之间建立固定数量的TCP连接，通过所述TCP连接，实时发送所述直播消息至所述消息发布池，或在检测到所述消息中转队列为空时，每隔固定时间间隔对所述消息中转队列进行再次检测，并在所述消息中转队列不为空时，通过所述TCP连接发送所述消息中转队列中的全部直播消息至所述消息发布池。
  10. 根据权利要求9所述的系统，其特征在于，所述固定数量的TCP连 接为一条。
PCT/CN2016/088909 2016-03-30 2016-07-06 对直播消息的发布进行优化的方法及系统 WO2017166485A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/246,250 US20170289583A1 (en) 2016-03-30 2016-08-24 Method and system for optimizing publication of live broadcasting message

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610191728.6A CN105872574A (zh) 2016-03-30 2016-03-30 对直播消息的发布进行优化的方法及系统
CN201610191728.6 2016-03-30

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/246,250 Continuation US20170289583A1 (en) 2016-03-30 2016-08-24 Method and system for optimizing publication of live broadcasting message

Publications (1)

Publication Number Publication Date
WO2017166485A1 true WO2017166485A1 (zh) 2017-10-05

Family

ID=56627526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/088909 WO2017166485A1 (zh) 2016-03-30 2016-07-06 对直播消息的发布进行优化的方法及系统

Country Status (2)

Country Link
CN (1) CN105872574A (zh)
WO (1) WO2017166485A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109698960A (zh) * 2017-10-20 2019-04-30 阿里巴巴集团控股有限公司 直播消息的展示方法、装置及系统
CN110996141B (zh) 2019-11-05 2022-03-25 北京字节跳动网络技术有限公司 一种直播间中信息的发送方法、装置及电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101184112A (zh) * 2007-12-20 2008-05-21 腾讯科技（深圳）有限公司 多媒体信息传输发布系统及其传输发布多媒体信息的方法
US20110296049A1 (en) * 2008-12-25 2011-12-01 Zte Corporation Method and system for realizing massive terminals access of a streaming media server
CN103199968A (zh) * 2012-01-09 2013-07-10 卓望数码技术（深圳）有限公司 一种消息的发送方法和系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101569190B (zh) * 2006-12-13 2012-12-26 汤姆森许可贸易公司 Tdma mac层中的自适应时间分配
US8141102B2 (en) * 2008-09-04 2012-03-20 International Business Machines Corporation Data processing in a hybrid computing environment
CN101771567A (zh) * 2009-11-10 2010-07-07 南京联创科技集团股份有限公司 自主内存数据库基于日志的数据持久或双机热备方法
CN102255794B (zh) * 2010-05-17 2014-07-30 塔塔咨询服务有限公司 远程消息收发吞吐量优化和等待时间缩短用系统和方法
CN102006309A (zh) * 2010-12-16 2011-04-06 新余钢铁集团有限公司 一种mes系统与pcs系统之间实时通信的方法及中间件
CN105007238B (zh) * 2015-07-22 2018-04-24 中国船舶重工集团公司第七0九研究所 轻量级跨平台消息中间件的实现方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101184112A (zh) * 2007-12-20 2008-05-21 腾讯科技（深圳）有限公司 多媒体信息传输发布系统及其传输发布多媒体信息的方法
US20110296049A1 (en) * 2008-12-25 2011-12-01 Zte Corporation Method and system for realizing massive terminals access of a streaming media server
CN103199968A (zh) * 2012-01-09 2013-07-10 卓望数码技术（深圳）有限公司 一种消息的发送方法和系统

Also Published As

Publication number Publication date
CN105872574A (zh) 2016-08-17

Similar Documents

Publication Publication Date Title
US8655945B2 (en) Centralized rendering of collaborative content
JP6164747B2 (ja) 協働環境におけるフロー制御のためのおよび信頼性のある通信のための方法
WO2016169308A1 (zh) 视频云存储方法及系统、预览云存储的视频的方法及系统
Lazidis et al. Publish–Subscribe approaches for the IoT and the cloud: Functional and performance evaluation of open-source systems
US10331613B2 (en) Methods for enabling direct memory access (DMA) capable devices for remote DMA (RDMA) usage and devices therof
US11221981B2 (en) Asynchronous channel based bus architecture enabling decoupled services
CN112291293B (zh) 任务处理方法、相关设备及计算机存储介质
US20170289583A1 (en) Method and system for optimizing publication of live broadcasting message
US10609125B2 (en) Method and system for transmitting communication data
CN103139051A (zh) 一种基于Websocket协议的即时通讯方法
US10133696B1 (en) Bridge, an asynchronous channel based bus, and a message broker to provide asynchronous communication
CN115865874A (zh) 一种会议消息推送方法、会议服务端及电子设备
WO2017166485A1 (zh) 对直播消息的发布进行优化的方法及系统
CN108011795B (zh) 一种实现通信设备中多板卡和多数据通道管理的方法及系统
US10579577B2 (en) Bridge and asynchronous channel based bus to provide UI-to-UI asynchronous communication
CN113259408A (zh) 数据传输方法和系统
TU et al. Key technologies and application of edge computing
US20170187773A1 (en) Technologies for wireless transmission of digital media
CN114666640B (zh) 一种边缘网关接入服务器
CN103312808B (zh) 一种云操作系统总线及通信方法
WO2019210667A1 (zh) 屏幕画面传输方法、装置、服务器、系统及存储介质
JP2008108116A (ja) 双方向通信システム、サーバ装置、中継装置、双方向通信方法及びプログラム
US20180255157A1 (en) Network service chains using hardware logic devices in an information handling system
WO2019230228A1 (ja) 情報処理システム、情報処理装置、および情報処理システムの制御方法
CN104635661A (zh) 数据传送装置以及数据传送方法

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16896258

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16896258

Country of ref document: EP

Kind code of ref document: A1