50 million pv applet, high concurrency and cache optimization, into the pit

The daily average pv of the applet is 50 million, which is beyond imagination. The traffic is rising all the way, the server pressure is too high, and various downtimes have to start various optimizations.

First of all, the upgrade of hardware is essential and the capital of the revolution. The hardware upgrade is as follows

1 Standalone

2 single machine + cloud database

3 single machine + cloud database + 6G redis cache

4 Load balancing of five servers + multiple master-slave read-write separation of cloud database + 16G redis cache

5 load balancing of ten servers + multiple master-slave read-write separation of cloud database + 32G redis cache

Because our applet has very few picture files, we do not consider CDN and oss ​​file storage

If the hardware is not enough, you can upgrade it, but you can buy it every month, otherwise it will be too expensive

The following are written one by one, where you want to write.

1. Analyze the bottleneck. The small program was made by a novice of a brother company, but the effect is quite good. It was brought to us to promote it. I didn't expect the traffic to rise all the way. When there is a lot of traffic, the bottleneck of the system first appears in the database, and the query is very slow. I looked at the table and found that the index is not well done, and even some key places have no index, so add the index quickly.

The pressure on the database has just eased for a while, but the CPU usage of the server has been above 90%, and there is even a downtime. After analyzing the business, our applet is mainly for social question answering, and it does not have high computing requirements. There will be computing pressure at the place where the last user generates and shared pictures. Sure enough, after expanding from a single machine to load balancing, the server's cpu has no more pressure. From then on, the pressure mainly revolves around the reading and storage of data, that is, the pressure of database and redis

2. Redis is a good thing. Every time the commonly used data can be correctly cached, the pressure on the database can be reduced a lot. Redis has two caching ideas. One is for database caching. When users write data, such as questions and answers, they are written to both the database and redis. When querying, the data of redis is inserted first, and if not, it is fetched from the database. ; Second, for the interface cache, the json data returned by the interface is directly cached, and the user checks the same content again and returns the json data directly. I personally prefer the second caching method, which is simple and efficient, but for the interface where the data does not change much, generate a reasonable redis key value according to the query conditions, and also set a reasonable expiration time, otherwise the amount of data is too large. For example, there is an interface for users to query their previous questions and the correct answers, because the questions they have asked cannot be changed, they are cached according to the id of this set of questions;

3. Load balancing, distributing traffic to different servers for processing, greatly reducing the pressure on the CPU, but because the data of the database needs to be shared, only the cloud database can be used, and the help to the database is not obvious.

To be continued

4. Mini Program Matrix

5. Business code optimization

6. Database table structure problem

7. Data filtering submitted in the previous paragraph

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325006361&siteId=291194637