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

This article will explain in detail the example analysis of the high concurrency architecture in web. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Server architecture

Business from the initial stage of development to gradually mature, the server architecture is also from a relatively single to cluster, and then to distributed services.

A service that can support high concurrency requires a good server architecture, a balanced load, a master-slave cluster for the database, a master-slave cluster for nosql cache, and a cdn for uploading static files. These are all powerful backing to make business programs run smoothly.

Most of the server needs operation and maintenance personnel to cooperate with the construction, I will not say more, so far.

The general server architecture that needs to be used is as follows:

Server

Load balancing (such as nginx, Aliyun SLB)

Resource monitoring

Distributed system

Database

Master-slave separation, cluster

DBA table optimization, index optimization, etc.

Distributed system

Nosql

Master-slave separation, cluster

Redis

Mongodb

Memcache

Cdn

Html

Css

Js

Image

Concurrent testing

High concurrency-related services need to be tested for concurrency, and the amount of concurrency that the whole architecture can support is evaluated through a large number of data analysis.

Testing high concurrency can use a third-party server or your own test server, use testing tools to test concurrent requests, and analyze test data to get an evaluation that can support the number of concurrency, which can be used as an early warning reference. as the saying goes, you can fight a hundred battles without defeat.

Third-party services:

Aliyun performance test

Concurrent testing tools:

Apache JMeter

Visual Studio performance load test

Microsoft Web Application Stress Tool

Actual combat plan

General scheme

The daily user traffic is large, but it is scattered, and occasionally there is a high concentration of users.

Scenario: user check-in, user center, user order, etc.

Server architecture diagram:

Description:

These services in the scenario are basically operated by users after entering APP. Except for the activity days (618, double 11, etc.), the number of users of these services will not be highly aggregated. At the same time, the tables related to these services are big data tables, and most of the businesses are query operations, so we need to reduce the number of queries that users directly hit DB; priority query cache, if the cache does not exist, then conduct DB queries to cache the query results.

Updating user-related caches requires distributed storage, such as using user ID for hash grouping to distribute users to different caches. The total amount of such a cache set will not be very large and will not affect query efficiency.

Options such as:

Users check in to get points

Find the user's check-in information in the key,redis hash that calculates the user distribution

If the check-in information is found, the check-in information is returned

If not, DB queries whether you have checked in today, and if so, synchronizes the check-in information to the redis cache.

If today's check-in record is not found in DB, check-in logic is performed, DB is used to add today's check-in record and check-in points are added (the whole DB operation is a transaction)

Cache check-in information to redis and return check-in information

Note that there will be logic problems in the case of concurrency, such as checking in multiple times a day and issuing multiple points to users.

My blog post [high concurrency in the eyes of liar programmers] has related solutions.

User order

Here, we only cache the order information on the first page of the user, with 40 pieces of data on one page, and users usually only look at the order data on the first page.

The user accesses the order list, if it is the first page read cache, if not the read DB

Calculate the key,redis hash of user distribution to find user order information.

If the user order information is queried, the order information is returned.

If it does not exist, query the order data on the first page by DB, then cache redis and return the order information.

User center

Calculate the key,redis hash of user distribution to find user order information.

If the user information is found, the user information is returned

If there is no user DB query, then cache the redis and return the user information

Other business

Most of the above examples are for user storage cache. If it is a common cache data, you need to pay attention to some problems, as follows

Note that common cached data needs to be considered that concurrency can lead to a large number of hits to DB queries. You can use the administrative background to update the cache, or lock operations on DB queries.

My blog [boast Redis Advanced] shares update caching issues and recommended solutions.

The above example is a relatively simple high concurrency architecture, which can be well supported when the concurrency is not very high, but with the growth of the business and the increase of user concurrency, our architecture will also be continuously optimized and evolved, such as service-oriented, each service has its own concurrency architecture, its own balanced server, distributed database, nosql master-slave cluster, such as user service, order service.

Message queue

For active services such as second kill and second grab, users pour in in an instant to produce high concurrent requests.

Scene: collect red packets regularly, etc.

Server architecture diagram:

Description:

Timed collection in the scenario is a highly concurrent service. For example, flash sale activity users will pour in at the arrival time, DB will receive a critical blow instantly, hold will go down continuously, and then the whole business will be affected.

For businesses like this, which are not only query operations but also have high concurrency to insert or update data, the general solution mentioned above cannot be supported. When concurrency occurs, it will directly hit DB.

Message queues are used when designing this business. You can add the information of participating users to the message queue, and then write a multithreaded program to consume the queue and give red packets to the users in the queue.

Options such as:

Collect red packets regularly

It is generally customary to use list of redis

When the user participates in the activity, push the user participation information to the queue

Then write a multithreaded program to pop data to carry out the business of handing out red packets.

In this way, users with high concurrency can participate in activities normally and avoid the risk of database server downtime.

Attach:

Many services can be done through message queuing.

For example: scheduled short message sending service, using sset (sorted set), sending timestamp as the sorting basis, short message data queue according to time ascending order, and then writing a program to read the first item in the sset queue in a regular cycle, whether the current time exceeds the sending time, and if it exceeds, send the short message.

First-level cache

The highly concurrent request connection cache server exceeds the number of request connections that the server can receive, and some users have the problem of being unable to read data when establishing a connection.

Therefore, there needs to be a solution that can reduce hitting the cache server when there is high concurrency.

At this time, there is a first-level cache scheme, the first-level cache is to use the site server cache to store data, pay attention to store only part of the data with a large number of requests, and the amount of data cached should be controlled. Do not excessively use the memory of the site server and affect the normal operation of the site application. The first-level cache needs to set the expiration time in seconds, which is set according to the business scenario. The purpose is to let the data acquisition hit the first-level cache when there are high concurrent requests, instead of connecting to the cache nosql data server, thus reducing the pressure on the nosql data server.

For example, the APP first screen commodity data interface, these data are public and will not be customized for users, and these data will not be updated frequently. If the number of requests for this API is relatively large, you can join the first-level cache.

Server architecture diagram:

Reasonable specification and use of nosql cache database, split the cache database cluster according to the business, which can basically support the business. After all, the first-level cache uses the site server cache, so you should make good use of it.

Static data

Under the condition that the high concurrency request data does not change, if you can not request your own server to obtain data, you can reduce the resource pressure on the server.

If the update frequency is not high, and the data allows a short delay, you can upload CDN by statically turning the data into JSON,XML,HTML and other data files. When pulling the data, you can first pull it to CDN. If you do not get the data, you can get it from the cache and the database. When the manager operates the background to edit the data, then re-generate the static file and upload it to CDN for synchronization. In this way, in the case of high concurrency, the data acquisition can be hit on the CDN server.

CDN node synchronization has a certain delay, so it is also important to find a reliable CDN server provider.

I specially sorted out the above technology. There are many technologies that can not be explained clearly by a few words, so I simply asked a friend to record some videos. Many questions are actually very simple, but the thinking and logic behind them are not simple. To know it, you need to know why. Share the fee with everyone.

Other options

For data that is not updated frequently, APP,PC browsers can cache the data locally, and then upload the version number of the current cached data each time the API is requested. The server receives the version number to determine whether the version number is consistent with the latest data version number. If it is different, it queries the latest data and returns the latest data and the latest version number. If the same, the status code is returned to tell the data is up-to-date.

This is the end of the article on "sample Analysis of High concurrency Architecture in web". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

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.