Q: What kind of cache is a good cache?
A cache that solves a problem is a good cache. This sentence is simply nonsense, equivalent to white cat, black cat, and the one that catches mice is a good cat.
So on the premise of solving the problem, which cache is the best cache? My answer to this question is: a cache with a high cache hit rate is a good cache.
Under the premise of solving the problem, a cache with a high hit rate may require less hardware investment than a cache with a low hit rate. At the same time, the number of caches may be smaller than the number of caches with a low hit rate. In this way, the addressing speed will definitely be faster. . So a cache with a high hit rate is a good cache.
Cache hit rate
After a cached entity is thrown into the cache, if it has not been used once by the outside world while the entity is cached (during the life cycle of the entity being cached), the hit rate of the cached entity is 0. The more times this entity is requested, the higher its cache hit rate.
What is mentioned above is the hit rate of an entity in the cache. For the cache as a whole, its hit rate is the hit rate distribution diagram of each cached individual above.
For caching: usually the most commonly used individuals are a very small part of the total. The least frequently used make up a large proportion of the whole.
So we often see data like this:
Of the 10,000 cached elements, 100 are used frequently, almost every minute. 2000 pieces of data, requested once an hour. 3000 pieces of data are requested once a day, and the remaining data has not been used even once after being thrown into the cache.
Nowadays, hardware is developing rapidly. If we only need to cache 10,000 data, we can completely throw all 10,000 data into the cache regardless of whether they are used. In this way, as long as we look for data, we will definitely have this data in the cache. There is no need to perform additional operations or make requests to the database.
However: hardware develops rapidly, and so does the amount of data. For a small website, if 10,000 pieces of data are cached, all of them will be cached. However, large websites have at least millions of data or T-level data. Obviously, all of this data cannot be thrown into the cache. At this time, it is very important to design a reasonable caching solution and improve the cache hit rate. And it is necessary.
Some common methods to improve cache hit rate
From a purely technical perspective, we only record the number of user requests per unit time, and cache the most commonly used data based on this information.
But more often than not, we improve the cache hit rate based on business logic. For example: Last year and the blog published the year before last, the browsing requests for this type of article were usually at least a few times a day. Generally should not be cached in memory.
For another example, a post with many replies will generally be viewed by more people than a post with fewer replies.
We should use the above logic and provide a caching algorithm based on our actual business logic to improve the cache hit rate. Let's cache appropriate data, rather than all data, as our hardware allows.
A negative example is: No matter what, a large blog site, when an article is requested by a user, it is found that it is not in the memory cache, so it is read from the database and then thrown into the cache.
You know, there are a lot of crawlers now. In addition, for search engine-friendly sites such as blogs, most of the access pressure comes from search engines. These visits are usually one hour or one day, with only a few or even one request for a certain article, and then never again. The hit rate of the above caching method will be very low.
Someone may ask here, Guo Hongjun, since you don't suggest me to cache the content of these blogs, but how can I improve the performance of my site? I must at least ensure that my blog site will not be too slow to respond to user requests.
There are many solutions to this problem. One of the simplest methods is to make these blogs into static Html pages, which is the cache of the file system. Due to the hard disk, the file system can be simply understood to be infinitely expandable, so that many Content with a low hit rate is cached.
If your page requires some dynamic logic judgment, you can cache the data into XML files, and then the server segment integrates these XML files, or includes files. This is also a good approach.
Having said so many issues about cache hit rate, let’s briefly summarize the views on cache hit rate:
Small websites can cache all data, and generally the pressure will not be great, so cache hit rate issues can be ignored.
Large services cannot cache all the data, but only part of the data. At this time, the architect needs to design a caching method suitable for the business logic to improve the cache hit rate as much as possible.
Most of the methods to improve the hit rate are tied to business logic and require detailed analysis of specific problems. For data that cannot be cached in memory, the simplest way to improve performance is to use file caching.
File caching can cache the entire content into a static file; it can also cache an area of the entire page into a file and then include it; it can also serialize an entity into an XML file for caching.
Let's look at a few other, less important aspects of caching:
Cache lifecycle activities
Content that never expires or changes forever should not be placed in the cache. Cache is temporary storage, not permanent, so the cache life cycle is limited.
In turn it may go through the following activities:
Enter cache. (When entering the cache, you may need to specify its future expiration policy. If not specified, you need to use the system default expiration policy)
Obtain it from the cache. Note that thread safety issues need to be dealt with at this time.
When updating the cache, note that you also need to consider thread safety issues when leaving the cache. This may be an external request, or the cache may clear it based on the expiration policy.
Cache expiration policy
Generally I would ask, what cache expiration strategies have you encountered in the caches you have come into contact with?
The most common expiration strategies are as follows:
If it has not been requested for a long time, it will expire. The most typical one is the Section function provided by ASP and ASP.net. In fact, it is a cache.
The cache that relies on file changes will expire once the file is modified, typically the Web.config of the WEB site. Once the file changes, not only will the cache be restarted, but the IIS process will also perform a release.
Based on this, you may see cache expiration policies for many dependencies. For example, cache expiration policy that relies on the database.
Of course, there may be more complex expiration strategies in the business logic. In the new version of the CSDN points system forum, the post list cache will clear it to 550 pieces of data when the list data cache reaches 600.
Another example is that the cache of new points-based forum posts expires when no list refers to the post, and the post expires.
Cache synchronization problem
Using cache means that multiple copies of the same data may coexist. If your code does not consider a certain situation, the two data will be inconsistent. This is when problems will occur.
The solution is simple. Think carefully about your business logic and code triggering situations, and don't leave any areas that haven't hit the bottom.
Simple methods can make your code logic very complex.
This is why some people recommend that you not use caching when it is not necessary. Once you start using caching, you should be prepared to add a lot of code to handle data synchronization.
Initialize and fill cache data
Sometimes after the cache is initialized, some data needs to be pre-populated into the cache. This is the initialization operation of cached data.
The following issues need to be considered during the initialization operation of cached data:
How long does it take to initialize? Generally, if it is a site, we may handle this initialization work in Application_OnStart of Global.asa. Initialization generally cannot take too long. At this time, our code optimization ability is tested.
During initialization, data is usually imported in batches, instead of processing one data at a time during normal use.
Summarize:
This article introduces some of my views on caching without going into specific caching technologies in depth. I hope that through the description of this article, people who only know the usage of caching but do not understand the idea of caching can have a preliminary understanding.
http://blog.csdn.net/ghj1976/archive/2007/09/01/1768676.aspx