How to deal with high concurrency issues during live streaming

For users who like to watch live broadcasts, being able to browse videos smoothly is a great enjoyment. But the actual situation is that when a large amount of user data floods in at a certain period of time (such as the increase in the number of viewers, the outbreak of barrage messages, etc.), if the concurrency structure is not optimized, it is difficult not to encounter the situation of screen freezes. So in the process of developing the source code of the live broadcast system, how to correctly deal with these stuck problems caused by high concurrency? 1. Anti-theft chain processing If it is a web live broadcast room, if the current site is not anti-leech, it is easy to suffer malicious requests. Too many malicious requests will cause a great burden to the live broadcast rooms that have relatively large traffic. For example, there are two live broadcast websites, A and B. Station A enjoys the resources of Station B, and the page embeds the pictures, JS, and CSS of Station B. Station A doesn't care what kind of traffic will be consumed by Station B, but for Station B, if the pictures, JS, and CSS of Station B are called. When a user visits station A, they will make some HTTP requests to station B, thereby taking the traffic and bandwidth of station B, and at the same time infringing on some copyright issues of station B. Speaking of this, when optimizing traffic on your own live broadcast website, you also need to consider reducing HTTP requests, such as combining CSS, JS, and images. In this way, the capacity of some web files will be slightly larger, but the number of requests will be reduced. 2. CDN acceleration This can be said to be a standard configuration in the development of the source code of the live broadcast system. Of course, even if it is an ordinary static page, it will be very lagging if the CDN is not used. Let’s briefly talk about the principle here: In more common terms, we can put some front-end files and front-end resources of the system into the CDN. When the user visits the page, it can be accessed through the CDN nearby, and in a certain sense Solve the problem of insufficient bandwidth. Three, server optimization Now most of the live broadcast source code is written in php, so you can do some page static processing for this, and cache some data directly into HTML code. It will be very effective to reduce the load of the local CPU and the server pressure. However, static page has some expiration time, it is impossible to display static data forever, so it is meaningless to create some dynamic content. But for some real-time content, it is not very reasonable to do staticization. At this time, we need to penetrate the staticization and do multi-threaded asynchronous processing of the access process to improve the response speed of the request. Fourth, database optimization Most webpages can be cached with Memcache, but for live source code development, Redis and mysql cache are the ones that do the most. But when we bypass these caches for real data access, in order to improve access efficiency, we can use some tools, such as mycat, to do some splitting work on the system data table, such as vertical or horizontal splitting, or data read and write separation. Wait. It is not difficult to see that in the process of developing the live source code, the handling of stuttering is actually not much different from the optimization process of most web pages. If you have any questions about this, please leave a message to the editor.