Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of what are the four major problems that must be solved in the Java distributed cache system, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this article on the four major problems that must be solved in the Java distributed cache system. Let's take a look.

Distributed cache system is an indispensable part of the three-high architecture, which greatly improves the concurrency and response speed of the whole project, but it also brings new problems that need to be solved. they are: cache penetration, cache breakdown, cache avalanche and cache consistency.

Cache penetration

The first big problem is cache penetration. This concept is easy to understand and has something to do with hit rate. If the hit rate is low, the pressure is concentrated in the database persistence layer.

If we can find the relevant data, we can cache it. But the problem is that this request does not hit both the cache and the persistence layer, which is called cache penetration.

For example, as shown in the figure above, in a login system, there is an external attack that has been trying to log in with users that do not exist. These users are virtual and cannot be effectively cached, and they will query the database every time. Finally, it will cause a performance failure of the service.

There are many ways to solve this problem. Let's give a brief introduction.

The first is to cache empty objects. Isn't the persistence layer unable to find the data? Then we can set the result of this request to null and put it in the cache. By setting a reasonable expiration time, you can ensure the security of the back-end database.

Caching empty objects will take up extra cache space and there will be time windows with inconsistent data, so the second method is to use a Bloom filter to deal with large and regular key values.

A record exists and does not exist, which is a Bool value that can be stored using only 1 bit. The Bloom filter can compress this yes or no operation into a data structure. For example, data such as mobile phone number and user gender are very suitable for using Bloom filter.

Cache breakdown

Cache breakdown also refers to the situation where the user's request falls on the database, in most cases, due to the batch expiration of the cache time.

We usually set an expiration time for the data in the cache. If a large amount of data is fetched from the database at some point and the same expiration time is set, they will fail at the same time, causing a breakdown of the cache.

For hot data, we can set it not to expire; or update its expiration time when accessing it; and allocate a relatively average expiration time as far as possible for bulk cache items to avoid expiration at the same time.

Cache avalanche

The word avalanche looks terrible, but the actual situation is really serious. Caching is used to accelerate the system, and the back-end database is just a backup of the data, not as a highly available alternative.

When the cache system fails, the traffic is instantly transferred to the back-end database. Before long, the database will be overwhelmed by heavy traffic. This cascading service failure can be vividly called an avalanche.

The high availability construction of the cache is very important. Redis provides master-slave and Cluster modes, in which Cluster mode is easy to use, and each shard can be used as a master-slave mode to ensure high availability.

In addition, we have a general assessment of database performance bottlenecks. If the cache system fails, requests that flow to the database can be blocked out using a current-limiting component.

Cache consistency

After the introduction of cache components, another long-standing problem is cache consistency.

First of all, let's look at how the problem happened. For a cache item, there are four common operations: write, update, read, and delete.

Write: cache and database are two different components, and as long as double writes are involved, there is a possibility that only one write will succeed, resulting in data inconsistency.

Update: the update situation is similar and two different components need to be updated.

Read: read to ensure that the information read from the cache is up-to-date and consistent with what is in the database.

Delete: when deleting a database record, how to delete the data in the cache?

Because the business logic is more complex in most cases. The update operation is very expensive, such as the balance of a user, which is calculated by calculating a series of assets. If these associated assets flush the cache as they change everywhere, the code structure will be so messy that it cannot be maintained.

I recommend using trigger cache consistency and lazy loading to make cache synchronization very simple:

When reading the cache, if there is no relevant data in the cache, the relevant business logic is executed and the cached data is constructed and stored in the cache system.

When the resource associated with the cache item changes, first delete the corresponding cache item, then update the resource in the database, and finally delete the corresponding cache item.

In addition to the simplicity of the programming model, this operation has an obvious advantage. I only load this cache into the cache system when I use it. If resources are created and updated with each modification, there will be a lot of cold data in the cache system. This actually implements the Edge caching pattern (Cache-Aside Pattern), which loads data from the data store into the cache on demand, with the biggest effect being to improve performance and reduce unnecessary queries.

But there's still a problem. The next scene is also a question often mentioned in the interview.

The database update actions we mentioned above, and cache deletion actions, are obviously not in the same transaction. It may cause inconsistencies between the contents of the database and the contents of the cache during the update process.

In the interview, as long as you point out this question, the interviewer will give a thumbs up.

You can use distributed locks to solve this problem by isolating database operations and cache operations from other cache read operations and using locks to isolate resources. Generally speaking, the read operation does not need to be locked, and when it encounters a lock, it retries to wait until it times out.

This is the end of the article on "what are the four major problems that must be solved in the Java distributed cache system?" Thank you for reading! I believe you all have a certain understanding of the knowledge of "what are the four major problems that must be solved in the Java distributed cache system". If you want to learn more, you are welcome to follow the industry information channel.

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.