** Introduction: There are two core functions of ** live broadcast business, one is real-time audio and video push and pull flow, the other is the transmission and receiving of live broadcast message flow. This paper mainly introduces the design practice and evolution of message service system in Baidu live broadcast service.

The background,

Users chat and interact in the live broadcast room, which is a common IM message flow. But live news streams are more than just user chats. In addition to user chat, real-time reminders of interactive behaviors such as sending gifts, entering the site, clicking “like”, going to buy, recommending goods by anchors, and applying for connecting the mic, which are common in the live broadcast room, are also sent through messages. In addition, special scenarios such as closing of live broadcast room and switching of live stream also depend on real-time delivery of message flow. Message flow can be regarded as the basic ability of real-time interaction between anchors and users and real-time control in a live broadcast room.

Second, live news 1.0 – Lay the foundation

Let’s take a look at how to build a live messaging system and what challenges need to be addressed.

2.1 Scenario analysis of live broadcast messages

Live chat messages are often compared to group chats. Group chat is a more familiar instant messaging scenario, in-studio chat and group chat. There are similarities, but there are also essential differences.

Compare the characteristics of the two:

  1. At the same time, the number of participants is different: a group chat with thousands of participants is a large group; However, for large-scale live broadcast scenes with high popularity, such as National Day, military parade and Spring Festival Gala, the cumulative users of a single live broadcast room are millions or even tens of millions of people, and the number of online users at the same time can reach millions.

  2. The relationship between user and group and direct broadcast is different: user into group and out of group is a relatively low frequency operation, the user set is relatively fixed, the change frequency of user in and out is not particularly high; And users in and out of the direct broadcast room, is very frequent, high heat of the single direct broadcast room every second facing tens of thousands of users in and out of the change.

  3. Duration varies: Once a group chat is established, the duration of the chat may be quite long, ranging from days to months; Most broadcast rooms last no more than a few hours.

Based on the above analysis, two core issues are extracted:

Problem 1: Maintenance of users in the direct broadcast room

  1. Single broadcast room tens of thousands of users per second in and out of the change; The peak value of entering the live broadcast room is not more than 20,000 QPS, and the exit is not more than 20,000 QPS.

  2. Millions of people are online at the same time

  3. Single direct broadcast cumulative users up to tens of millions of magnitude

Support online million, accumulated ten million two sets, 40 thousand QPS updates per second, there is a certain pressure, but there is support for high read and write performance of storage should be able to solve, such as Redis.

Problem two: message delivery of millions of online users

In the face of millions of online users, there is a large amount of news up and down, which is analyzed from the perspective of live broadcast users:

  1. Real-time: If the message server performs simple peak elimination, the accumulation of peak messages will increase the overall message delay, and the delay may have a great cumulative effect, and the message and live video stream will have a great deviation on the time line, affecting the real-time interaction of users watching live broadcast.

  2. Terminal experience and performance: The terminal displays all kinds of user chats and system messages, usually no more than 10-20 on a screen; If more than 20 messages are sent per second, the messages displayed on the terminal will continue to flood the screen. Consider the special effects with gift messages, etc.; A large number of messages, processing and presentation on the other side, bring a constant high load. Therefore, for a client that watches live broadcast for a long time, if there is a continuous large number of messages, the message consumption of the client will have significant performance pressure, and too many messages will have a cumulative effect.

Since the first problem is not difficult to solve, the second problem is mainly discussed below.

2.2 Design objectives of live broadcast messages

Taking the live broadcast business scenarios into consideration, the demand targets for message services are as follows:

  1. Real-time, the end and end of the message to reach the second level;

  2. In terms of performance, message service can support online delivery of more than one million users in the same direct broadcast room at the same time.

  3. For too many messages at peak value, discarding is a reasonable and appropriate way to deal with them.

  4. Based on reasonable end user experience, the number of messages per second in a single direct broadcast is assumed to be no more than N.

Now, the core of the problem is how to deliver no more than N messages to millions of users in the live broadcast room in S seconds, assuming that N<=20, S<=2.

2.3 Stress analysis of ordinary group chat

2.3.1 Analysis of sending and receiving messages of ordinary group chats

Figure 1: Group chat data flow and pressure point

First of all, make a detailed analysis of the message sending and receiving process of ordinary group chat:

  1. For group group-1, assign a group public message box group-mbox-1;

  2. User user-1 in group group-1 sends message MSG-1 on mobile APP-1;

  3. After receiving the message msG-1, the server checks whether user-1 has permission. If so, the server stores msG-1 in the group mailbox group-mbox-1 and generates the corresponding MSGID-1.

  4. The server queries the user list groupuserlist-1 corresponding to group-1.

  5. Groupuserlist-1, groupuserlist-1, groupuserlist-1, groupuserlist-1 User – n;

  6. For each user user-i, you need to query the device device-i-1, device-i-2, and device-i-m where user user-i resides (because one account may log in to multiple devices).

  7. For each device device-i-J, the long connection channel establishes an independent long connection connect-J to serve the device. However, since connect-j is connected to the long connection service by app-1 on the end, it is dynamic. Therefore, the query of the corresponding relationship between device-i-j and connect-j needs to rely on a routing service route to complete the query.

  8. After connect-j is found, groupmsg-notify-1 can be delivered through connect-j.

  9. If user user-i is using device-i-j’s mobile APP-1, user user-i can immediately receive the notification groupmsG-notify-1 from the long connection connect-j.

  10. After receiving groupmsG-notify-1, the message SDK in app-1 on the mobile end initiates the fetchMsg pull message request to the server according to the message ID of latestMsgID corresponding to the last message latestMsg recorded in the local message history on the end. Pull all messages from latestMsgID+1 to the latest in group-1;

  11. After receiving the fetchMsg request, the server retrieves all latestMsgID+1 and latest messages from group-mbox-1 and returns them to the server. If there are too many messages, you may need to end paging pull.

  12. End app-1 pulls all messages from latestMsgID+1 to the latest in group-1 for display; After the user reads in the session, the read status or session read status of all new messages needs to be set.

2.3.2 Main pressure of ordinary group chat

If the whole process of sending notifications to the end of ordinary group chat messages is fully reused, if a message msG-1 sent by User-1 needs to support a real-time million-magnitude group message, there are about the following challenges of million-magnitude per second:

First, split the user list groupuserList-1 in seconds, which requires reading millions of user list data in seconds, the first million-level challenge for storage and service.

Second, for splitting all the individual users in the group, user-i needs to query millions of device-i-j in seconds. For storage and services, this is the second million-level challenge.

Third, for all device-i-J, millions of connect-J are queried in seconds through the dynamic routing service Route, and the third million-level challenge is for storage and service.

Fourth, for long connection connect-j delivery, it is necessary to support sending millions of group messages in seconds to groupmsG-notify-1 to the corresponding connect-j, which is a million level challenge for long connection service.

Fifth, for all end app-1 receiving message notification, it needs to support one million QPS end to pull message request fetchMsg from the server. For message mailbox service, this is also a challenge of one million magnitude. Considering that the latestMsgID of each end may be different, the possible optimization method is more complex and has a greater impact on performance.

Sixth, if most users are chatting online, setting the read state can also put millions of QPS on the server.

Obviously, the total reuse of the group chat message flow puts enormous pressure on the message service and the long-connection service.

2.3.3 Optimization scheme of ordinary group chat

△ Figure 2: Pressure point after optimization of group chat data flow

Now, let’s analyze each of these challenges in the order of a million and see if there’s room for optimization.

  1. For ① split user list and ② query user corresponding device, if the storage of the two combined together, that is, optimize the storage of the user list in the live broadcast room, expand device information, can reduce a user->device millions of QPS query, can be optimized.

  2. For the reliable message pull mode of ④ downlink notification and ⑤ end pull fetchMsg, considering that live messages can be partially discounted and discarded, one-way message delivery can be performed instead of pull. It is also acceptable for most users whose connections remain online. So it can be optimized to keep only downstream notifications (containing the message body) and discard the end pull.

  3. For ⑥ message Settings have been read, it can be considered to simplify and discard in live broadcast scenarios.

The above optimization reduces the pressure requests of ②⑤⑥ by three million magnitude, but there are still three million magnitude steps to deal with: ① split user list, ③ dynamic routing query, and ④ long connection delivery.

For ① split user list, support millions of magnitude of user list query, the more general idea is to support batch query based on group groupID, for example, one can find 100 users, 10 thousand QPS query can support to millions; Based on group groupID, the storage of user data can be distributed to multiple master-slave instances and fragments to control the granularity of fragmentation and avoid hot spots. It can be basically done, but the storage resources may be consumed more.

For ③ dynamic route query, on the surface, the problem is similar to ①, but somewhat different. Because the user list of the group, is based on the group groupID to do the key, to establish a table or multiple broken table; The device-I-j query is completely decentralized, which also requires batch query capability. However, the fully decentralized device information query cannot be optimized only for specific keys, and dynamic routing service is required to support query performance of millions of QPS on the whole.

For the (4) long-connection service, the long-connection service does not depend on external storage services. To support the delivery capability of millions, if a single long-connection instance supports the delivery capability of 10,000, 100 instances can support the delivery capability of millions.

Based on the above analysis, support millions of messages, the beginning of the dawn. It seems that all you need to do is optimize user lists, store/query dynamic routes, and expand the capacity of long connections, but all of that requires a lot of storage and machine resources.

Considering the reality of the live streaming business, the reality is not optimistic:

On the one hand, when there is no hot live broadcast at ordinary times, the peak number of concurrent online users in a single live broadcast may not exceed 10,000 or even less than 1,000. In the early stage of the business, the total online users of live broadcast may not exceed 100,000. This means that resources as a whole are tens of times redundant in order to support million-dollar peaks.

On the other hand, if there is a very hot live broadcast suddenly, it may not only need to support the release of a message of magnitude 1 million, but may be more than 5 million (such as the National Day parade, Spring Festival Gala, etc.). In this case, the possible peak value of online users should be estimated in advance for each large live broadcast. If the current designed capacity is exceeded, the user list (1), dynamic route query (3) and long connection service (4) need to be expanded and tested respectively. Or, if acceptable, do downgrading or denial of service.

In fact, it is difficult to accurately estimate the peak value of online users. As a result, the actual resource utilization is low, capacity expansion or reduction is frequent, and O&M costs are high. Whether to choose this plan is also very confusing.

2.3.4 Common group chat multi-group solution

For example, if a group supports a maximum of 10,000 users, opening 100 groups can support a million users. It seems possible to create another virtual group, to connect these 100 groups together.

However, if carefully analyzed, it can be found that the problems mentioned above (1) split the user list, (3) dynamic route query, (4) long connection delivery, high pressure still exists, or inevitable.

In addition, multiple groups introduce other problems:

Fault 1: Messages in multiple groups are not synchronized. If two users watch a live broadcast together and belong to different groups, they will see completely different messages.

Problem 2: Users in and out of the live broadcast scene are dynamic, that is to say, group members are very unstable, and the peak fluctuation of online users is large. If a new group is dynamically opened according to the growth of the online population, the first group may have many users, while the second group has fewer users at the beginning. Or, during the peak period, more groups are opened. As the popularity decreases and users leave, users become scattered. Some groups may have fewer users and less chat interaction, so it is necessary to reduce the size and merge groups. How to balance multiple groups of users to achieve good business results is also more difficult to do.

Based on the above analysis, we did not choose the multi-group scheme.

2.4 Multicast McAst scheme

A live message architecture supporting real-time high concurrent millions of concurrent online users, the proposal and evolution of multicast McAst scheme.

2.4.1 Think outside the original framework

Should we use the group chat-based optimization above, or can we take a different approach?

Forget the group sending and receiving process for a moment. If there is one step that is absolutely necessary for message delivery, it is the long connection delivery step. Messages cannot reach users if they are not delivered over a long connection. Of course, some people say that polling pull can also replace long connection delivery to obtain messages, but obviously polling pull performance pressure and real-time performance is much worse than long connection delivery, so it is not the scope of discussion.

If a similar groupID can be specified when sending messages to the long connection service, the long connection service can be directly split into the long connection connect-j related to all group users, and the million-magnitude query of user list splitting and dynamic route query can be omitted.

In this case, the pressure of message delivery will mainly be borne by the long-connection service, and the server does not need to expand multiple systems, so the optimization of live message may be greatly simplified.

According to this idea, it is equivalent to the concept of a group for connect in the long connection service. Based on the idea of connection group, we design a set of multicast McAst mechanism for long connection.

2.4.2 Basic Concepts of Long-link multicast McAst

  1. Each long-link multicast McAst has a globally unique identifier, McAstID.

  2. You can create, delete, modify, and query the long-link multicast McAst.

  3. Long-link multicast McAst is a set of connections connected by several long-link online users.

  4. A user user-i on the device device-i-j establishes a unique long connection connect-j-k for a specific application app-k; (There is no distinction between logged-in and non-logged-in users.)

  5. The relationship between long-link multicast McAst and connect-J-K does not require additional independent storage and is maintained on each instance of the long-link service.

2.4.3 Routing Concepts of long-link multicast McAst

The route of multicast McAst-m, route-m, is a collection of long connection service instances LcsList, which records the long connection service instance LCS-j of all long connection connect-I added to McAst-m.

2.4.4 Record maintenance of long-link multicast McAst routes

Join multicast McAst:

  1. The client calls the message SDK to join McAst-m.

  2. The message SDK sends an upstream request McAstJoin (McAst-m) through a long connection.

  3. The service layer receives the McAstJoin request from connect-I on LCS -I to verify the validity of McAst-m.

  4. The request routing layer of the service layer establishes the multicast route McAstroute-m based on the multicast McAst-m, and adds the long connection instance LCS-I to the multicast route McAstroute-m.

  5. The service layer requests the long connection service layer, requests the long connection instance LCS -i where McAstJoin resides, and adds the connection connect-i to McAstConnectList -m.

Leaving the multicast McAst is similar to joining the multicast McAst. The client invokes the message SDK to leave McAst-m and sends an upstream request McAstLeave (McAst-m). The long-connect server updates the route and McAstconnectlist-m information.

2.4.5 Multicast McAst Message Push

△ Figure 3: Multicast McAst data flow and pressure points

The long connection message push process based on multicast McAst is a 1:M * 1:N diffusion and amplification process, and the specific process is described as follows:

  1. A message is pushed to msG-1. The destination is multicast McAst-m.

  2. According to the destination McAst-m, the back-end service module makes a consistent hash to select the McAst route distribution module instance McAstrouter-i and sends msG-1 to McAstrouter-i.

  3. McAst distributes the routing module instance McAstroute-i. According to the multicast route McAstroute-m of McAst-m, McAstLcsList searches for the corresponding access instance routing record list McAstLcsList, and splits all the long connection access instance LCS-1 of McAst-m.. Lcs-m, send MSG-1 to the long connection instance concurrently;

  4. After receiving the message msG-1, the long connection service instance LCS-j searches the multicast connection list McAstConnectList -m according to the multicast McAst-m, and finds all connections connect-m-1 in McAst-m.. Connect-m-n, push MSG-1 to message client SDK-m-1 concurrently.. The SDK – m – N;

  5. After receiving MSG-1, the message client SDK-M-O submits it to upper-layer services (such as live streaming SDK).

2.4.6 Performance evaluation of the multicast McAst mechanism

Now let’s analyze the performance pressure of the above multicast McAst mechanism:

  1. The main pressure of multicast McAst route maintenance lies in McAstJoin and McAstLeave, while the peak request of Join can hardly exceed 20,000 QPS. The access pressure is two orders of magnitude lower than millions.

  2. The message push process of multicast McAst is generally divided into a long connection instance with tens to hundreds of orders of magnitude and a very low cost.

  3. The message push of multicast McAst in a single instance of long connection is sent concurrently by multiple connections in a single process. After optimization, it is measured online. Under the condition that the single instance maintains 25W long connection, the McAst with pressure measurement up to 8Wqps is delivered stably, and the capacity of 5Wqps is evaluated conservative. Multiple long-connected instances are fully concurrent and can be easily expanded horizontally.

  4. In summary, for the delivery of 100Wqps, 20 long connection instances can be fully loaded (20*5W=100W) with a certain margin. If 500Wqps is delivered, there are no more than 100 instances; If the delivery of 1000W is carried by a larger load of 8W single instances, 125 instances can support it.

It seems that, based on the above multicast McAst mechanism, we have established a set of efficient long connection delivery mechanism that supports millions of QPS, and the current capacity of long connection service can be supported, basically without expansion. However, whether it can fully meet the requirements of live broadcast business scenarios needs further discussion.

2.4.7 Message peak problem

For 1 message per second, spread to 100W users, or even 500W users, the above multicast McAst mechanism seems to be able to handle it.

However, the actual situation of the messages in the live broadcast room is that there are a lot of popular live broadcast users’ uplink messages per second. In addition to the chat messages, there are also many kinds of system messages sent regularly or irregularly, such as the number of people, entering, liking and sharing.

If we assume that there are 100 kinds of messages in peak value per second, 100W*100= 100 million, and if we simply calculate according to single instance 5Wqps, 2000 instances are needed to support it. Although it is much better than the old group chat system, the system still encounters a lot of resource redundancy or needs a lot of capacity expansion to cope with peak value. Is there a better solution?

2.4.7.1 Delayed aggregation

Here we consider a common optimization idea, is through the batch aggregation pattern to improve system performance. If the 100 messages are aggregated and packaged once per second for unified delivery, the QPS is still 100W. The QPS delivered by the long-connected system remains unchanged, but the magnitude of messages delivered per second can reach 100 million. This aggregation scheme is actually feasible. In the aggregation mode, the cost we pay is the increase of message delay. The average delay of 1-second aggregation increases by 500ms. The loss of user experience is not great, but the magnitude of message delivered by the system can be increased by a hundred times. Considering the actual scenarios of live broadcast, second-level aggregation and delay are acceptable in most scenarios.

2.4.8 Message bandwidth Problems

The QPS problem of long connection single instance is solved by aggregation delay delivery, and then the bandwidth pressure problem of long connection single instance delivery is solved. For example, if 10000 long connection instances need to send 100 messages per second, the average message bandwidth is 2K*100*10000*8=15625 Mbit/s, which exceeds the bandwidth capacity of the 10 MBIT/s NIC on a single physical machine.

On the other hand, the global bandwidth is as high as 1.5Tbps, which puts pressure on the egress of the equipment room. Therefore, the bandwidth cost is too high, and you need to reduce the bandwidth usage or find a better alternative.

  • The compression

Faced with the problem of high bandwidth consumption of delivered data, we adopted a data compression solution without changing service data. Compression is cpu-intensive operation. Due to the real-time performance of live broadcast services, the compression ratio cannot be simply considered. After comprehensively balancing the compression ratio, compression delay and compression CPU consumption, the measured average compression ratio after tuning the compression library reaches 6.7: 1, the amount of data is compressed to about 15% of the original, so 15625Mbps*15%=2344Mbps=2.29Gbps; The bandwidth capacity of a single 10-gigabit network card can bear up to 42,700 long connections. Although it does not reach 50,000, it is basically acceptable.

From the global bandwidth point of view, the peak is also reduced to no more than 230Gbps, the benefits are significant.

2.4.9 Client Performance Problems

Further, in the live broadcast scenario, there is not only a high peak message magnitude, but also a continuous high message magnitude pressure during the live broadcast. This is not only stressful for the server, but also challenging for the client. On the one hand, there is obvious pressure on the client to receive, display, and so on; On the other hand, too much and too fast news refresh on the live broadcast interface is also harmful to user experience.

  • The speed limit

So, user experience and comprehensive balance in the client performance, on the basis of the message server adds the combination of message priority classification speed limit frequency control mechanism, single-user client does not need to bear the pressure of 100 per second, cutting issued news every second, and 5-80000 connections per second single instance allots long connection, CPU and bandwidth can be stable support.

2.4.10 Real-time Message Problems

  • priority

We provide a real-time message delivery mechanism based on message priority. The aggregation delivery can be triggered immediately for high-priority messages without increasing the aggregation delay. For ordinary medium and low – optimal messages, or do delayed aggregation delivery.

2.4.11 Online User Problems

The starting point of multicast McAst mechanism is to ensure the arrival of messages from online users, allow offline users to receive partial loss of messages, pay reasonable technical complexity and cost, and achieve a balance between service quality and performance under the scenario of millions of concurrent online users.

And for the message arrival of online users, another key problem is how to ensure the long connection of users online.

In order to improve the access stability and reachability of the long connection service, we have optimized the following aspects.

  • Access point

The long connection service has deployed access points in north, East and South China regions of the three major domestic operators. For the live broadcast scenes of some foreign users, the independent access point entrance of the Computer room in Hong Kong is added.

  • HTTPDNS

For DNS hijacking and resolution errors of some users, the MESSAGE SDK connects to the HTTPDNS service and optimizes the local cache, forming a multi-level domain name resolution guarantee system, improving the reliability of domain name resolution and reducing the DNS hijacking and error rate.

  • The heartbeat optimization

Long-link heartbeat is an important means to keep alive and detect alive. In view of the real-time characteristics of live broadcast scenes, in order to find long-link broken chain as soon as possible, after multicast McAstJoin, the long-link heartbeat is also adjusted to an intelligent heartbeat with shorter interval and dynamic control of the server. This allows the messaging SDK to quickly and proactively re-establish the connection if a connection exception is detected in time.

  • Broken back

If a multicast McAst member has been added to the multicast McAst, if the long link breaks, the long link server automatically or passively clears the multicast McAst member. When the long connection reconstruction connection is recovered, the live broadcast service layer also needs to listen to the connection recovery signal and rejoin the multicast McAst to recover the message path of the multicast McAst.

2.4.12 Multicast McAst summary

To sum up, the multicast McAst mechanism effectively solves the problem of real-time message delivery of millions of concurrent online users. For short chain break and too many messages, part of the messages are allowed to be discarded. It meets the design goal of live scene message.

The characteristics of multicast McAst mechanism are:

  1. The message service and routing layer have light pressure, and the overall pressure is only borne by the long connection layer, which is easy to expand horizontally.

  2. Based on delayed aggregation delivery and compression speed limiting, the performance problems of downlink QPS and bandwidth can be solved well.

  3. The overall downlink QPS and bandwidth of the system are completely controllable. The maximum downlink QPS of a 100W online user is 100W, and that of a 500W online user is 500W. The delivery capacity of a single instance is stable at 50-80,000 QPS. Therefore, you can easily determine whether the overall system capacity needs to be expanded in special scenarios.

  4. Although the McAst mechanism is proposed for live broadcast scenarios, it has universal design and can be applied to other message push scenarios where a large number of users are grouped online in real time.

3. Live news 2.0 – Sustainable development

After the multicast McAst mechanism solves the problem of real-time message delivery for millions of online users, the scene of live message continues to expand, and new message demands are constantly put forward by innovative live message services. Accordingly, the service mechanism of multicast McAst also needs to keep pace with The Times and continuously expand and optimize in depth and breadth. The following highlights the historical and gift news.

3.1 Historical Information

For users who just enter the live broadcast room, they need to see some recent chat records to enhance the interactive atmosphere of chat and help understand the progress of live broadcast. Users interested in historical chat history can also trace more message history. This creates a need for chat history.

To support such historical messages, the solution is to open a multicast public message box McAst-mbox service for each multicast McAst request.

  1. For user messages and other messages that need persistence, all are written to this message box.

  2. You can specify the multicast McAstID to obtain historical multicast McAst messages based on the time interval and the number of messages to be pulled.

The concept and application of message information are explained.

3.1.1 Concept of MAILBOX Service

  1. A message MSG in a message box with a unique message identifier msgID.

  2. MSG of a message, including sender information, recipient information, message type, message content and other fields, can be ignored here.

  3. You can set the expiration time for each message. After the expiration time, the message cannot be accessed.

  4. Each message can be set to read status.

  5. A message box, mbox, has a unique mailbox identifier, mboxID.

  6. An mbox is a container that stores an ordered list of messages. The message list msgList is sorted by msgID.

  7. Message mailbox service: supports single message or batch message writing to the specified mailbox mbox.

  8. Message mailbox service, supports single message or batch message search based on msgID for specified mailbox mbox.

  9. Mbox service: supports mbox search in the range from msgID-begin to msGID-end.

In fact, the most common is pulling messages based on the MSGID range; The message mailbox service here is the timeline model. Interested students can refer to the timeline timeline model for further information.

3.2 Gift Message

△ Figure 4: Gift message

Gift message scenario analysis:

  1. When a user gives a gift to an anchor, the anchor side needs to receive the gift message notification as soon as possible and reliably so as to give feedback to the user in a timely manner.

  2. Send a gift to the user, local can timely display the gift effect, no message notification strong appeal.

  3. Other users in the live broadcast room need to receive the gift message to show the gift effect, improve the interactive atmosphere in the live broadcast room, and inspire other users to give gifts.

  4. Gift messages involve user orders and purchase actions and need to be acknowledged by the server.

  5. Gift messages have a higher priority than other chat messages and system messages.

Based on the above analysis, the following technical solutions are proposed for live broadcast news:

  1. An independent reliable message multicast McAst channel (multicast McAst-2 in FIG. 4) is added for sending and receiving of high-quality reliable messages. Isolated from other common messages and system messages at the data flow level to reduce mutual interference;

  2. For the common user side end message SDK, although the gift message multicast McAst channel is a new independent channel, the message sending and receiving logic is consistent with the common message multicast McAst channel.

  3. For the host side, the end message SDK needs to support the combination of push and pull mode for the gift message multicast McAst channel to ensure the arrival of all the gift messages. Even if there is a short drop, you need to get all the gift messages;

  4. For the host side, in extreme cases, if there is an anomaly in the long connection connection, the message SDK can poll through the short connection interface to pull the gift multicast McAst mailbox message.

Based on the above independent reliable message multicast McAst channel scheme, the gift message reach rate has reached more than 99.9% without excluding some abnormal scenarios, such as the anchor offline broadcast, data accidental loss, etc.

3.3 Development of other aspects of live broadcast news

In the course of development of Baidu Live broadcast, the live broadcast news service also faces many other basic problems and other challenges brought by innovative business. Now there are better solutions to these problems. Here are some for your reference:

  1. How to support multiple client scenarios, Android, iOS, H5, applets, PC.

  2. How to support the same live broadcast message in Baidu APP and good-looking, national, post bar matrix APP through.

  3. How to support non-logged-in users. IM generally supports login users, and live broadcast scenarios also need to support non-login users.

  4. If there is a serious problem with the long connection service, whether there is a degraded channel for the end to get messages.

  5. The machine censor of live broadcast news review how to do, how to support pre – and post-review and post – before – review.

  6. How to support messages across multiple live broadcast stations.

  7. How does the live news service support innovative business, such as answer live, live with goods, live with mics and so on?

Limited by space, the above questions are not discussed in detail here. If you are interested, please contact us directly.

Fourth, review the outlook

In the past few years since the launch of Baidu Live Broadcast, the live broadcast message service has braved difficulties, escorted Baidu Live and provided solid technical support and guarantee for baidu Live.

In the future, in terms of supporting innovation business of live broadcast, finer granularity message classification service, stability and performance of basic services of live broadcast news, the live broadcast news service will continue to make efforts to consolidate the foundation and innovate continuously to support better and faster development of live broadcast business.

The original link: mp.weixin.qq.com/s/3tk986HvM…

Recommended reading

Vientiane: Baidu’s massive multimedia information processing system

———-  END  ———-

Baidu Architect

Baidu official technology public number online!

Technical dry goods, industry information, online salon, industry conference

Recruitment information · Internal push information · technical books · Baidu surrounding

Welcome students to pay attention to!