In high-concurrency application scenarios, the front-end needs faster rendering speed, while the back-end not only needs faster interface speed, but also needs to ensure data consistency.
In the front-end design, there may be optimization methods such as static pages and cdn. In the back-end architecture, it is usually necessary to refer to the solution of high concurrent programs. The following mainly talks about the back-end processing scheme.
Layered
There are two main parts in the background, one is the database and the other is the business block. Of course, the business layer may also include calls to other services.
Optimizations used by the database layer
1. Sub-library and sub-table. However, when designing, it is best to consider that the library table can be expanded without downtime.
2.Optimization of sql. Specify column names when querying, use indexes, replace in with between...
Business layer optimization
1. Data sources
This layer is the main point of explanation. In fact, it can be subdivided into many sub-categories. For the time being, you think that from the front-end request to the end of the request is the business layer, of course, the data source needs to be removed here.
There are three types of data sources: database data , other interface data , and data in the cache .
For database data, the corresponding solutions have been given above.
For calling other interface data, of course, the faster the dependent interface responds, the better, but it should be noted that if the downstream interface has no response result, a timeout or retry mechanism needs to be implemented. To put it bluntly, it is necessary to cut off the current request, and not let this request cause the entire server to crash (of course, this is a bit exaggerated).
For the data in the cache, the freshness of the cache needs to be considered, but generally, data that changes infrequently is suitable for caching. It is also necessary to take into account the size of the cached data and an evaluation should be made in advance, so as not to cause insufficient memory. The solution is also very simple, either reduce the cache or increase the machine memory. There is one suggestion that needs to be mentioned. Try to cache the same data once. For example, if there is a user object, the name and gender are used as the key, the name and age are used as the key, and then again. . . Such a data has been cached many times, occupying the memory size in vain, and the user id can be used to cache the data directly. The judgment logic should not be used as the key, but should be judged in the program. Caching also needs to pay attention to cache penetration, cache avalanche, and of course, sometimes hot data is used.
In the process of its own program processing, it is necessary to distinguish business scenarios. In some scenarios, data needs to be returned in time, such as the product list page of X Bao and the product list page of X East. In some scenarios, it is not necessary to respond in a timely manner, for example, there is a text message notification within half an hour after placing an order.
For scenarios that require a timely response, the data returned by the interface should be as simple as possible. For example, it can be returned by paging, and the same message can be extracted.
For scenarios that do not require timely response, in high concurrency scenarios, message queues can be used. Well-known mqs in the industry include kafka, rabbitmq, rocketmq, zonemq, activemq, etc. They should handle 1w/s insertion without any problems. Specific needs to be based on their own business to do further evaluation.
2. Transaction consistency
But there is a problem that seems to be overlooked, how to ensure the consistency of the transaction?
In distributed transactions, there is a well-known cap (consistency, availability, partition tolerance ) theory. The facts tell us that it is difficult to satisfy all three characteristics. Generally, mq is used most in the industry to ensure the final consistency of transactions ( There may be a delay, but the final correct result can still be seen by the user); of course, there is also Xbao's GTX solution, which is based on 2pc at the bottom, and is also very strong in solving distributed transactions.
In code design, it is best not to use locks if you can, and optimistic locks are given priority if you want to use them.
3. Control requests
It is possible that the traffic volume is very large, and your service can only withstand 10 million traffic at most. For other requests, you can use the queue for delayed processing (preferably considering the timeliness), or you can discard the request. If a user maliciously brushes traffic, you can limit ip access through code, or you can limit control through nginx.
4. Service downtime
Sometimes the service is not 100% reliable, which requires the fuse processing of the service. If the service cannot respond to requests sent within a certain period of time, the service should be set to an incomplete state from the server cluster. Send its own health status to the cluster through a timing mechanism. If the service is good after a period of time, it can respond by dividing a portion of the traffic from the cluster. If the response is normal, it will rejoin the cluster and become available. If the service is still not good after a period of time, the cluster will completely delete it from the service and issue a warning email!
5. Response speed
In high concurrent access, the response speed of the interface needs to be as fast as possible. Let's discuss this issue from two aspects:
1. JVM layer
Try not to trigger full gc. This process is very time-consuming. At the same time, the time of young gc needs to be as short as possible. If it exceeds 1s, you need to find the time-consuming point.
2. Code layer
Use a cache service (local cache, redis...), call it asynchronously (thread pool...).
3. System layer
Cluster....