Java Interview Assault Series (11): Design a High Concurrency System

How to design a high concurrency system

Preface

Suppose you work on a high-concurrency system in a well-known e-commerce company, with hundreds of millions of users, billions of traffic per day, and tens of thousands, even 100,000, at peak concurrency. Then people will ask your system architecture carefully, what architecture is your system? How is it deployed? How many machines are deployed? How is the cache used? How is MQ used? How is the database used? It is to dig deep into how you resist high concurrency.

Because people who have really done high concurrency must know that the system architecture that is separated from the business is all on paper. When it is really in a complex business scenario and high concurrency, the system architecture must not be that simple. Use redis and use mq. Can it be done? Of course not. After the real system architecture is combined with the business, it will be many times more complicated than this simple so-called "high concurrency architecture".

If an interviewer asks you a question, how to design a high concurrency system? So sorry, it must be because you have not actually done a high concurrency system. The interviewer looks at your resume and doesn’t look good, and it feels bad, 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 done your own research and have accumulated a certain amount of knowledge.

Analysis of Interview Questions

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

To be simple, it is very simple, because the system is connected to the database at the beginning, but you must know that when the database supports two or three thousand concurrent connections per second, it is almost finished. That's why it is said that many companies have relatively low technology when they first started, and as a result, the business develops too fast, and sometimes the system fails to withstand the pressure.

Of course it will hang up, why not hang up? If your database instantly carries 5000, 8000, or even tens of thousands of concurrency per second, it will definitely be down, because for example, mysql cannot handle such a high amount of concurrency at all.

So why is high concurrency so powerful? It is because there are more and more people using the Internet. Many apps, websites, and systems carry high concurrent requests, which may be several thousand concurrent requests per second during the peak period, which is normal. If it's Double Eleven, tens of thousands and hundreds of thousands of concurrent transactions per second are possible.

So how do you play with such a high amount of concurrency, coupled with such a complicated business? The really powerful ones must be those who play too high a concurrent architecture in a complex business system, but you don’t have one, so let me tell you how you can answer this question:

• System split, split a system into multiple subsystems, use dubbo to do it. Then each system is connected to a database, so that there is originally a database, but now multiple databases can resist high concurrency.

• Cache, cache must be used. In most high-concurrency scenarios, you read more and write less, so you can write a copy in both the database and the cache, and then use the cache when you read. After all, redis can easily concurrency of tens of thousands of single machines. no problem. So you can consider how to use the cache to resist high concurrency in the read scenarios that carry the main request in your project.

• MQ, MQ must be used. Maybe you still have high-concurrency writing scenarios. For example, in a business operation, you have to frequently engage in database dozens of times, adding, deleting, modifying, adding, deleting, and modifying, which is crazy. The high concurrency will definitely jeopardize your system. If you use redis to carry and write, it will definitely not work. People are caching, and the data is LRU at any time. The data format is extremely simple and there is no transaction support. So if you should use mysql, you have to use mysql. What about you? Use MQ, a large number of write requests are poured into MQ, queue up and play slowly, and write slowly after the system consumes, and control it within the scope of mysql. So you have to consider how to use MQ to write asynchronously to improve concurrency in your projects, in scenarios that carry complex writing business logic. It is also ok for MQ single machine to resist tens of thousands of concurrency, which I have specially said before.

• Sub-database and sub-tables may not avoid the requirement of anti-high concurrency at the final database level. Well, then split a database into multiple databases and multiple databases to resist higher concurrency; then split a table into Multiple tables, the amount of data in each table is kept a little less, which improves the performance of SQL running.

• Read and write separation, this means that most of the time the database may read more and write less. It is not necessary that all requests are concentrated on one library. You can create a master-slave architecture, write from the main library, read from the library, and do a read Write separation. When the read traffic is too much, you can add more slave libraries.

• Elasticsearch, you can consider using es. es is distributed and can be expanded at will. Distributed can naturally support high concurrency, because you can expand the capacity and add machines to resist higher concurrency at any time. Then some simple query and statistical operations can be considered to be carried by es, and some full-text search operations can also be considered to be carried by es.

The above 6 points are basically some things that a high-concurrency system must do. You can carefully consider the knowledge mentioned before, and then you can explain this systematically, and then what issues should be paid attention to in each part , I have talked about it before, and you can elaborate on it to show that you have accumulated a bit of this area.

To be honest, after all, what is really good about you is not to understand some technologies, or to know what a high-concurrency system should look like? In fact, in a truly complex business system, high concurrency is far more complicated than my picture by dozens to hundreds of times. You need to consider which ones need to be divided into databases and tables, which ones do not need to be divided into tables, how to join a single database and a single table to a database and table, which data should be stored in the cache, and which data can be stored to resist high concurrency You need to complete the analysis of a complex business system, and then gradually join the transformation of the high-concurrency system architecture. This process must be complicated. Once done once, once done, you are in this market It will be very popular.

In fact, what most companies really value is not to say that you have some basic architectural knowledge related to high concurrency, some of the technologies in the architecture RocketMQ, Kafka, Redis, Elasticsearch, high concurrency, this is the second-class talent. For a complex distributed system with hundreds of thousands of lines of code, this experience is commendable for those who have step-by-step architecture, design, and practice of high-concurrency architecture.