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

This article mainly explains "how to solve the problem of server-side cache failure". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought. Let's study and learn how to solve the problem of server-side cache failure.

Examples of cache invalidation

Take a look at this pseudo code:

The code is as follows:

Local value = get_from_cache (key)

If not value then

Value = query_db (sql)

Set_to_cache (value, timeout = 100)

End

Return value

There seems to be no problem, and there will be no exceptions in the case of unit testing.

However, when you conduct stress tests, you will find that database queries peak every 100 seconds. If your cache failure time is set for a long time, the chances of this problem being detected will be reduced.

Why is there a peak? Imagine what would happen if 1000 concurrent requests reached query_db (sql) at the same time at the moment of cache failure? Yes, there will be 1000 requests to the database. This is the storm caused by cache invalidation. It has an English name, called "dog-pile effect".

How to solve it? The natural idea is to add a lock to control the database request when the cache is found to be invalid. The specific details, Chun elder brother in the lua-resty-lock document to do a detailed explanation, I will not repeat, please see here. By the way, the lua-resty-lock library itself has completed the wait for lock process for you, and you need to pay attention to this detail when looking at the code.

Traditional cache failure response strategy

In order to improve the speed of business access and improve business read concurrency, many users will introduce cache layer into the business architecture. All read requests of the service are routed to the cache layer, and the read performance of the service is greatly improved through the cached memory read mechanism. The data in the cache cannot be persisted, and once the cache exits abnormally, the data in memory will be lost, so in order to ensure the integrity of the data, the updated data of the business will fall into persistent storage, such as DB. Currently, the business architecture of cloud users is generally shown as follows:

In the figure above, you can see that the updated data of the user is directly persisted to the DB, and the business read request requests to cache the data directly, so the business needs to solve the problem of cache invalidation, that is, to solve the problem of invalidation of the data in the cache due to data changes. At present, the solution for business to solve the problem of cache invalidation is to implement DB and cache double write. To solve cache invalidation through business double write, the following problems exist:

The code is intrusive and needs to be double-written and stored. Any data changes to DB need to update the cache at the same time, and the degree of maintenance at the later stage of the code level is not high.

The cache is called synchronously in the user request thread. Since there is a strong cache, there is no way to effectively retry when an exception such as a cache timeout is encountered. When an exception is encountered, it returns information such as system error and operation failure to the user, which seriously affects the user experience.

Synchronous completion of DB and cache double writes in the user request thread, long change request link and large access delay, affecting the user experience

RDS data subscription consumption to easily solve cache invalidation

The problem of cache invalidation has also been encountered within Alibaba. With the continuous adjustment and optimization of the business architecture, we have precipitated a highly reliable and elegant cache invalidation architecture. That is, through the data subscription feature provided by data transmission, the incremental data of DB (such as RDS on public cloud) can be obtained asynchronously, and the cache will be invalidated according to the incremental data. The specific architecture is similar to the following figure:

In this architecture, the cache update process is as follows:

1. The request will be returned after the business has completed the DB update.

two。 Data subscription parses and subscribes the incremental update data of DB in real time through log parsing, and pushes the incremental data to downstream consumers when data updates are found in DB.

3. Once the downstream consumer business receives the incremental update data, it invokes the consumption thread to update the cache

At this point, the entire cache update process is completed.

From the cache invalidation process above, you can see this cache invalidation mechanism:

1. Short update path and low latency: cache invalidation is an asynchronous process, which is returned directly after the business update DB is completed. There is no need to care about the cache invalidation process. The whole update path is short and the update delay is low.

two。 The application is simple and reliable: the application does not need to implement complex double-write logic, just start the asynchronous thread to listen for incremental data and update the cached data

3. Application update has no performance consumption: because data subscription obtains incremental data by parsing the incremental logs of DB, the process of obtaining data is lossless to business and DB performance.

Thank you for your reading. the above is the content of "how to solve the problem of server-side cache invalidation". After the study of this article, I believe you have a deeper understanding of how to solve the problem of server-side cache invalidation. Specific use also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.