Preface:

From the notes I took earlier, just to summarize

1. The question is:

When the peak number of requests reaches 1000-2000, the online memory starts to be tight and the memory usage starts to rise. Peak, THE CPU turns very fast, CPU load began to increase, even reached 60-80%;

The database is about to break down, disk I/O drops, and SQL starts running slowly

2. Solutions

**1. The first step of the system split, ** split the system into multiple, respectively access their own databases, deployed on three servers, three databases; What if I triple my request?

2**. (cache) Start to use cache, ** use cache to resist read requests, a large number of read requests (5000/s requests) and 1000 write requests to the database (write requests will delete the corresponding cache first, and then modify the database data); Many requests are read requests, browse requests, etc. Redis can resist many requests with tens of thousands of concurrent requests per second

**3. (MQ) ** If users continue to increase, 100 million users, 10000/s requests; Write requests are high and MQ can be added between the system and the database; Although there are 2000 write requests per second, a large number of requests are backlogged in MQ, where the database consumes 1000 requests per second and MQ is used to whittle the peak

** If you can’t solve the problem by using MQ, the user continues to increase, 20,000 requests per second, this time the write request increases exponentially, MQ may not be able to carry, database may need to consume 2000 requests per second, this time need to split database into 3 databases; Add an asynchronous system between MQ and the database to distribute 600 requests per second to the database, spreading the concurrency burden

** If the number of users continues to increase, there is a problem because the data in the cache may be invalid, and the system will continue to read from the database and write to the cache at 1000 requests per second; At this time, we need to separate the read and write of the database. When writing, we need to write the master database, and when reading, we need to read the data from the slave database. When the cache fails, we need to read the data from the slave database, which can relieve the pressure

6. About the search problem, if it is a stand-alone search engine can be based on Lucence package package, the data volume is increasing, the stand-alone Lucence can not put, and the stand-alone can not support so much concurrency, you can use the distributed search engine ES, directly go to the ES cluster can put billions of data volume, with 20 machines, It can support tens of thousands of requests per second

Summary: the actual truly complex system, high concurrency is far more complex than this figure many times, which services need to be divided into tables, which data need to be slowed down to save, which data can resist high concurrency requests, after the completion of business analysis to gradually add high concurrency system architecture structure, this system is very complex.