How do you use caching and how do you make it more sensible? Today’s topic, combined with my previous project scenarios, discusses the rationality of using caching.
Hot data, cache is valuable
For cold data, most of the data may be squeezed out of memory before it is accessed again, taking up memory and having little value.
For hot data, such as one of our IM products, birthday greeting module, and the list of birthday stars of the day, the cache may read hundreds of thousands of times. Another example is a navigation product where we cache the navigation information and then read it millions of times.
For frequently modified data, consider caching as appropriate
To make sense, the cache must be read at least twice before the data is updated. This is the most basic strategy, and if the cache fails before it can take effect, it won’t be of much value.
For the above two examples, both the birthday list and the navigation information have a characteristic that the information is not frequently modified and the scene is usually read very high.
What about scenarios that exist and have a high frequency of changes, but you have to worry about caching? There are! Read the interface to the database, for example, the pressure is very big, but it is hot spot data, this time will need to be considered by caching means, reduce the pressure of the database, such as our some assistant product, thumb up, collect number, the number of share is a hotspot of typical data, but also constantly changing, right now you need to save the data synchronization to Redis cache, Reduce database stress.
Data inconsistency
The cache is typically set to expire, and once the expiration time is exceeded, it is reloaded from the database, so the application tolerates data inconsistencies for a certain amount of time. Another option is to update the cache as soon as the data is updated, but this also has more overhead and transaction consistency issues.
Cache update mechanism
In the process of using cache, we often encounter inconsistencies and dirty reads of cached data. What are our solutions?
In general, we use the cache double flush mechanism, when updating the database to eliminate the cache. Also, set a timeout, such as 30 minutes. In extreme scenarios, dirty data is stored in the cache for a maximum of 30 minutes.
Cache availability
Caching improves data read performance, and cache data loss and cache unavailability do not affect application processing. Therefore, the general operation means is that if there is an exception in Redis, we manually catch the exception, log, and go to the database to query the data back to the user.
Cache service degradation
The purpose of service degradation is to prevent the Redis service failure from causing an avalanche of database problems. Therefore, for unimportant cached data, service degradation strategy can be adopted. For example, a common practice is that Redis does not query the database, but directly returns the default value to the user.
Cache warming
In the newly started cache system, if there is no data, the system performance and database replication are not very good in the process of rebuilding the cache data, then the best cache system starts to load the hot data well, for example, for the cache information, in the start cache load database all data to warm up. Normally, we will open an interface to synchronize data for cache preheating.
The cache to penetrate
If improper business, or malicious attacks continue to send requests for some non-existent data, because the cache does not save the data, all requests will fall on the database, will cause great pressure on the database, even crash. A simple countermeasure is to cache data that does not exist.
