Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to start with 6000 requests per second". In daily operation, I believe many people have doubts about how to start with 6000 requests per second. The editor consulted all kinds of materials and sorted out simple and useful methods of operation. I hope it will be helpful for you to answer the doubts of "how to start with 6000 requests per second"! Next, please follow the editor to study!

Background

Behind the scenes of each film, you keep a record of your viewing, remembering in detail how many times you watched it, skipping that length of time, and it is said that according to these data you can analyze which Japanese star you like and use it as a directional push.

Although it looks like a simple function, it actually involves a very large amount of data, which is the product of the number of your users * videos in the ultimate case.

So how to deal with such a small amount of data when there are only two web servers and one sqlserver? Why write a request? Because you need to record every second the user watches the video, for example, the user watched the video in the tenth second. To get this done, you first need to define a few things:

Data definition that records how users watch videos

Data protocol that interacts with the client

The data format recorded in the database

How to solve the pressure of server writing (after all, the number of requests per server is still relatively large)

Definition of the progress of watching video by solution users

For a video, if there is a duration of 1 hour, these 3600 seconds correspond to whether 3600 states have been viewed or not. for viewing status, there are only two states: watching and not watching, so a bit is sufficient, and a byte has 8 bit, so a byte can represent a viewing state of 8 seconds. on this basis, the higher the number of characters, the more states the same number of characters will represent.

Each time the client uploads new data, it needs to perform bit operations with the data already existing on the server. For example, 01000 means viewed in the second second, and new upload on the client: 00011 means watched in 4 and 5 seconds. For users, the video has been viewed in 2, 4 and 5 seconds. Although it is only a simple operation, the consumption of cpu should not be underestimated when the amount is large.

First byte second byte 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 bit: 1 000 1 000 0 0 000 0 000 binary: 0x88 0x40 string: 8840 and client interaction protocol

Only the client knows the real-time information about the progress of the user watching the video. The client needs to upload the viewing progress data of the user, and the hexadecimal system that interacts with the server can choose the hexadecimal system with strong versatility. Of course, it doesn't matter if you choose binary 100, as long as both parties can support it at the same time and can parse it normally.

Database data format

The data types supported by each database are different, so it will not be described too much here. Of course, no matter what format, the less the space, the better, but it should also be considered comprehensively according to the amount of calculation of the business.

Resolve cpu performance issu

After all, it is necessary to merge the users' latest viewing data with the old data, which should not be underestimated in the case of a large number of users. After synthesizing various conditions, we finally use decimal to do the merging work. The client uploads hexadecimal data, then converts it into decimal, and then merges with the viewing record (decimal). This part of cpu cannot be omitted. The specific conversion program is as follows:

/ / the newly added data ConcurrentQueue AddQueue = new ConcurrentQueue () is required; / / the hexadecimal string is divided into a decimal array protected List ConvertToProgressArray (string progressString) {if (string.IsNullOrWhiteSpace (progressString)) {return null } / / verify whether the multiple length if (progressString.Length% 2! = 0) {return null;} var proStrSpan = progressString.AsSpan (); List ret = new List (); int I = 0; while (I)

< proStrSpan.Length) { ret.Add(int.Parse(proStrSpan.Slice(i, 2).ToString(), System.Globalization.NumberStyles.HexNumber)); ; i = i + 2; } return ret; }客户端请求数量问题 如果同时一万用户在同时观看视频，上传数据时间间隔为2秒，意味着每秒有5000请求。由于这个业务只是一个用户log型业务，何为log型，就是说可以容忍一部分数据丢失，针对这个数据形态，客户端可以先在本地做缓冲记录，没有必要一秒上传一次记录，例如现在约定的客户端30秒上传一次记录，如果用户关掉客户端，下次启动的时候会重新上传未成功的记录。 数据库压力 如果每次请求都单独更新数据库，按照第二条的计算每秒高达5000次update请求。用户观看每次视频都加载内存中缓存，仔细分析这种业务，由于是log型数据，所以每次你请求没有必要都去更新数据库，而是先更新了缓存，然后定时去更新数据库。 由于数据量的问题，所有的更新操作都会发送到一个任务队列，队列的执行者会根据配置批量更新数据库，这样比单条更新数据库性能要高很多，其实这种方案在很多log型的业务中都有使用，批量更新对数据库的压力要小很多,代码类似以下 public async Task AddUserVideoData(UserVideoInfo data, DBProcessEnum processType = DBProcessEnum.Update) { if(processType== DBProcessEnum.Add) { AddQueue.Enqueue(data); } return 1; } void MulProcessData() { //每次更新的条数 int maxNumber = 50; List data = new List(); while (true) { if (data == null) { data = new List(); } try { if (!AddQueue.Any() && !UpdateQueue.Any()) { System.Threading.Thread.Sleep(500); } else { //先处理 需要更新的 data.Clear(); while (data.Count s.UserId == value.UserId && s.VideoId == value.VideoId)) { var exsitItem = data.First(s =>

S.UserId = = value.UserId & & s.VideoId = = value.VideoId); exsitItem = value;} else {data.Add (value) }} if (data! = null & & data.Any ()) {var ret = UserVideoProgressProxy.Add (data) } catch (Exception err) {} this ends the study of "how to start with writing requests at 6000 per second". I hope I can solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.