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

In the development of Internet projects, the application of caching is very common. Caching can help pages load faster and reduce the load on servers or data sources.

1. Why do I need caching?

Generally speaking, the most performance-consuming part of a project is the database of the back-end service. However, the frequency of reading and writing in the database is often unevenly distributed, most of which are read more and write less, and there will be some complex judgment conditions for select, such as like, group, join and so on. These grammars consume performance very much, so there will be a lot of slow queries, so the database is easy to encounter bottlenecks in the read operation.

Then by placing a cache service in front of the database, we can effectively absorb uneven requests and resist traffic peaks.

In addition, if the application and the data source are not on the same server, there will be a lot of network consumption in the middle, which will also have a great impact on the response speed of the application. If the current application has less real-time requirements for data, adding cache on the application side can quickly improve efficiency.

2. What problems will you encounter when using caching?

Although caching can improve overall performance, it can also cause other problems. For example, after using the cache, it is equivalent to storing two copies of the data, one in the database and the other in the cache. When there is new data to write or old data to update, if we update only one of the data sources, the data on both sides will be inconsistent. Therefore, there is a problem of how to effectively and quickly synchronize the cached data with the database data in order to ensure the final consistency of the data.

In addition, the caching service actually introduces the complexity of the system architecture, because additional attention needs to be paid to the following problems caused by caching itself:

Cache expiration time problem: designing cache expiration time requires great skill and must be combined with the actual situation of the business. Because if the expiration time of the design is too short, it will lead to poor cache effect and frequent write of data from the database to the cache. If the cache design expires for too long, it will lead to a waste of memory.

Cache hit rate: this is also a very important point in designing what data needs to be stored in the cache. If the design is not good, it may cause the cache hit rate to be too low and lose the cache effect. Generally speaking, for hot spot data, it is best to ensure that the hit rate is more than 70%.

Cache penetration / avalanche problem: if the cache service goes down or is completely lost, it is possible that all traffic will be sent directly to the back-end database in an instant, which may cause a chain reaction. The instantaneous peak of requests is very likely to cause the database to fail to carry.

3. What are the cache update strategies?

Typical caching modes are as follows:

Cache Aside

Read/Write Through

Write Behind

Each model has different characteristics and adapts to different project scenarios. Let's take a look at this in turn:

Cache Aside mode

This is a strategic model that people often use. The main process of this model is as follows:

When querying data, the application first reads the data from the cache Cache, and if it is not in the cache, it reads the data from the database. After getting the data from the database, the data is also put into the cache Cache.

If the application wants to update a certain data, it is also necessary to update the data in the database first. After the update is completed, the data in the cache Cache is invalidated by instructions.

Why not let the update operation change the data in the cache Cache immediately after writing the database?

The main reason is that if you do so, there will be two write events, worried that it will lead to dirty data in the case of concurrency, for example: if there are two requests at the same time, request An and request B, concurrent execution. Request An is to read the data, request B is to update the data. There is no data in the initial state cache. When request A reads the data and is ready to write back, request B is about to update the data. After updating the database, request B updates the cache again. Then request A writes old data to the cache, which belongs to dirty data.

So there is no dirty data problem with the Cache Aside schema? No, dirty data may also be generated in extreme cases, such as:

If there are two requests at the same time, request An and request B are executed concurrently. Request An is to read the data, request B is to write the data. If there is no such data in the initial state cache, request A will read the data in the database when it finds that there is no data in the cache, and read that the data is ready to be written back to the cache. At this time, request B will write the data. Request B sets cache invalidation after writing the data in the database. At this time, request A begins to write data to the cache because it has read the previous old data in the database. At this time, the old data is also written. Then eventually, the data in the cache is inconsistent with the data in the database, resulting in dirty data.

But this probability is much smaller than the above one. Therefore, on the whole, Cache Aside mode is still a relatively simple and practical way.

Read/Write Through mode

In fact, this pattern takes the cache service as the main storage, and all read and write requests of the application deal directly with the cache service, regardless of the last database, the data of the database is maintained and updated by the cache service. However, when the data in the cache changes, the database is updated synchronously, and there is only the cache service in the eyes of the application.

The process is quite simple:

Both the data to be read and the updated data of the application directly access the cache service

The cache service updates data to the database synchronously

The probability of dirty data in this mode is relatively low, but it strongly depends on the cache, which requires the stability of the cache service. In addition, there will be the problem of empty data in the initial state when adding new cache nodes.

Write Behind mode

This pattern is a variation of the Read/Write Through pattern. The difference is that the Read/Write Through mode cache is synchronous when writing to the database, while the Write Behind mode cache operation database is asynchronous.

The process is as follows:

Both the data to be read and the updated data of the application directly access the cache service

The cache service updates data to the database asynchronously (through asynchronous tasks)

The characteristic of this model is that the speed is very fast, the efficiency will be very high, but the consistency of the data is relatively poor, there may be data loss, and the implementation logic is more complex.

These are the three mainstream cache update strategies at present, and the Refrsh-Ahead mode is not introduced in detail because it is not very common.

Caching is a very common way to improve efficiency in Internet projects. There are many uses, but also more critical, we can communicate together.

This article is transferred from the official account of Wechat: more than thinking. Author: Quigo.

Original link: https://mp.weixin.qq.com/s/GhTJ0rbxDrVO_Q5YRcKb0w

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.