Website Optimization----Homepage Optimization---App to access server data

High concurrency often occurs at a point where there is a large active user volume to access a site, such as a user's high-aggregated business scenario, such as snapping up, promotions, etc. In order to allow users to smooth access to the site, according to their own business design suitable for the system's processing plan.

For the App site home page data, there is usually an app requesting server-side data to be drawn natively. The fewer apps the app requests, the less server pressure: resources and bandwidth.

1. The less data the server sends to the app, the fewer useless fields are issued. is what the app needs, what the server sends.

2.APP each request server-side data, the server issued the latest data and data version number, the app can be cached locally, each time the interface request data, upload the current cached data version number, the server also calculates the latest data version number, compare, if the version number is not issued data, The app directly transfers local data, instead, the server sends the latest data and data version to the app.

3. The design of the server-side architecture is not passive REDIS data or caching operations when the interface is requested by the app. Instead, the server actively fetches MySQL data and brushes the Redis,app request interface to read data only from Redis

Here is a schematic diagram of the service side of the data design for Api->app, which I am currently using in my project.

Logical aspects:

There is a cron request MySQL data, to refresh the Redis data, the app through the API interface request Redis data.

Because Cron is a timed task script, the active request time can not be too short, frequently request MySQL data, this will give the MySQL resources pressure. Preferably within 5-10 minutes. But then there's a problem. Data is out of sync, such as back-end update data to Mysql,cron 5-10 minutes to proactively request a refresh of redis. Stability and performance are better, so the refactoring time to adopt such a scheme.

This is the problem of designing a policy that refreshes the cache

1. Active Refresh

1) When background update, delete cache, actively trigger cron script, refresh cache

This removes the cache and then writes. The user request is that access to the data is not present. affect the user experience.

2) When the background update, actively trigger cron script, refresh the cache

For this, the background of a large number of data updates, may be written to a key multiple times redis, would like Redis to brush into the uncertain data, affecting the correctness of the data display

3) Background update, the initiative to trigger Cron script, generate data version number, version number as key to save data, the version number stack, the top is the latest version of the data, the bottom is the original data version number, when the app request, the app upload version number and the original data version number, if the same does not send data, Different words, pop up the stack top version number, the latest data, delete the old version number data (will cause the accumulation of garbage data), version number stack rewrite.

Why did not use it, because at that time did not think ...

4) The Cron script actively requests the database, refresh the data, the frequency can not be too high.

The data has a certain delay

2. Passive Refresh

The task of refreshing the data to the app request, if the app request when there is no data in Redis, then request each interface to fetch database data, issued data and version number, refresh the Redis cache.

When a large number of accesses occur, concurrent access is generated, causing blocking.

App Access overall diagram

Optimization of the site----Home optimization---App to pick up server data