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

This article mainly introduces how to design a high concurrency system, which has a certain reference value. Interested friends can refer to it. I hope you will gain a lot after reading this article.

Interview questions

How to design a high concurrency system?

Psychological analysis of interviewer

To be honest, if the interviewer asks you this question, then you have to work hard. Why? Because you don't see what is said in the JD recruited by many companies nowadays, those with high concurrency experience are preferred.

If you do have real talent and knowledge and work in highly concurrent systems in an Internet company, then you can basically take offer as a bag, no problem. The interviewer would never ask you like that, otherwise he would be stupid.

Suppose you work in a well-known e-commerce company with hundreds of millions of users, billions of traffic a day, and tens of thousands, or even 100,000, during peak periods. Then people will interrogate your system architecture carefully, what is the architecture of your system? How is it deployed? How many machines are deployed? How do you use the cache? How does MQ work? How do you use the database? Is to dig deep into how you can withstand high concurrency.

Because people who really do too much concurrency must know that the system architecture that is separated from the business is all on paper. When the system architecture is really complex business scenarios and high concurrency, the system architecture must not be so simple. It can be done with a redis and mq. Of course not, when the real system architecture is matched with the business, it will be many times more complex than this simple so-called "high concurrency architecture".

If an interviewer asks you a question, how to design a high concurrency system? So I'm sorry, it must be because you haven't actually worked on a highly concurrent system. When the interviewer looks at your resume, it doesn't look good, so he will ask you, how to design a high concurrency system? In fact, to put it bluntly, the essence is to see if you have studied it yourself and whether you have accumulated a certain amount of knowledge.

The best thing, of course, is to recruit a really high-level concurrent buddy, but the number of such buddies is scarce and difficult to recruit. So maybe the next thing is to recruit a friend who has studied by himself, which is better than a friend who doesn't know anything.

So at this time you have to do a personal show to show all your knowledge about high concurrency!

Analysis of interview questions

In fact, the so-called high concurrency, if you want to understand this problem, in fact, we have to start from the root of high concurrency, why is there high concurrency? Why is the high concurrency so powerful?

I said a little simple, very simple, because at the beginning of the system is connected to the database, but you should know that the database support to two or three thousand concurrency per second, it is almost over. That's why it is said that many companies, when they first started, the technology was more low. As a result, the business developed too fast, and sometimes the system failed because it could not bear the pressure.

Of course I will. Why don't I hang up? If your database instantly carries 5000,8000 or even tens of thousands of concurrency per second, it will definitely go down, because mysql, for example, simply cannot handle such a high number of concurrency.

So why is the concurrency so high? Because more and more people are using the Internet now, many app, websites and systems carry high concurrent requests, which may be thousands of concurrent requests per second during the peak period. If it is something like Singles Day holiday, it is possible to concurrently tens of thousands or hundreds of thousands per second.

So such a high concurrency, coupled with the already so complex business, how to play? What is really good must be the people who play with overly concurrent architectures in complex business systems, but you don't, so I'll tell you how to answer this question:

Can be divided into the following six points:

System split

Caching

MQ

Sub-database sub-table

Separation of reading and writing

ElasticSearch

System split

Divide a system into multiple subsystems and use dubbo to do it. Then each system is connected to a database, so it is originally a database, and now multiple databases can also carry high levels of parallel development.

Caching

Caching, you must use caching. Most of the high concurrency scenarios are read more and write less, so you can write a copy in both the database and the cache, and then read a lot of cache. After all, there are tens of thousands of concurrency of redis on a single machine. So you can consider how to use caching to resist high concurrency in read scenarios that carry major requests in your project.

MQ

MQ, you have to use MQ. You may still have scenarios of high concurrent writes, such as frequently doing database dozens of times in a business operation, adding, deleting, deleting and deleting, crazy. That high concurrency will definitely fail your system. If you use redis to host and write, you can't do it. The data is cached, the data will be LRU at any time, and the data format is incomparably simple, without transaction support. So you have to use mysql as well as mysql. So what do you do? With MQ, a large number of write requests are poured into MQ, wait in line to play slowly, and the later system writes slowly after consumption, which is controlled within the load range of mysql. So you have to consider how to use MQ to write asynchronously and improve concurrency in your project, in scenarios that carry complex business logic. MQ stand-alone anti-tens of thousands of concurrency is also ok, this has been specifically said before.

Sub-database sub-table

At the final database level, it may be inevitable to resist high concurrency at the database level. OK, then split a database into multiple databases to carry higher concurrency; then split a table into multiple tables to keep the amount of data in each table a little less to improve the performance of sql.

Separation of reading and writing

Read-write separation, that is to say, most of the time, the database may also read more and write less, so it is not necessary for all requests to be concentrated in one library. You can set up a master-slave architecture, write to the master library, read from the library, and make a read-write separation. When there is too much read traffic, you can add more slave libraries.

ElasticSearch

Elasticsearch, abbreviated as es. Es is distributed and can be expanded at will, and distribution can naturally support high concurrency, because it is easy to expand capacity and add machines to carry higher concurrency. Then some relatively simple query, statistical class operations, you can consider using es to carry, there are some full-text search operations, you can also consider using es to carry.

The above six points are basically some things that must be done in a high concurrency system. You can carefully consider it in combination with the knowledge mentioned before. At that time, you can systematically elaborate on this piece, and then what problems you should pay attention to in each part. I've talked about it before, and you can explain it, which shows that you have accumulated a little bit about this piece.

To tell you the truth, after all, what is really good about you is not to figure out some technology, or roughly know what a highly concurrent system should look like? In fact, in a truly complex business system, high concurrency is far more complex than the points mentioned above. You need to consider what needs to be divided into databases and tables, which do not, how to join single database and table, which data should be put in the cache, and which data can withstand high concurrency requests. You need to complete the analysis of a complex business system, and then gradually add the transformation of the system architecture with high concurrency. This process is extremely complex, once done once and done well. You will be very popular in this market.

In fact, what most companies really value is not that you have some basic architectural knowledge related to high concurrency. Some technologies in the architecture, such as RocketMQ, Kafka, Redis, Elasticsearch, high concurrency, can only be second-class talents if you understand them. For a complex distributed system with hundreds of thousands of lines of code, this experience is commendable for those who build, design, and practice a highly concurrent architecture step by step.

Thank you for reading this article carefully. I hope the article "how to Design a High concurrency system" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.