Cache invalidation

Problem Description
The first classic problem with caching is cache invalidation. When the service system checks data, it will first check the cache. If the cached data does not exist, it will further check the DB. Finally, after finding the data, it will be seeded into the cache and returned. The performance of the cache is more than 50~100 times higher than that of the DB, so we hope that the data query hits the cache as much as possible, so that the system load is minimal and the performance is the best. The data storage in the cache is basically stored and retrieved with the key as the index. During business access, if a large number of keys expire at the same time, many cached data accesses will be missed, and then penetrate into the DB, and the pressure on the DB will increase significantly. Due to the poor performance of the DB, it is only below 1%~2% of the cache. In this way, the slow query rate of requests will increase significantly. This is the problem with cache invalidation.

Cause Analysis
The cause of cache invalidation, especially the failure of many keys together, is closely related to the expiration time of our daily write cache.

When writing the cache, we generally preset an expiration time for each type of business data according to the access characteristics of the business, and add this expiration time when writing the cache, so that the cached data is eliminated after this fixed expiration time. In general, because cached data is written gradually, it is also gradually expired and eliminated. However, in some scenarios, a large amount of data will be batch loaded from the DB by the system actively or passively, and then written to the cache. When these data are written into the cache, because the same expiration time is used, after this expiration time, the batch of data will expire together and be eliminated by the cache. At this time, all requests for this batch of data will have cache invalidation, which will penetrate to the DB. Due to the large amount of queries, the DB will easily increase the pressure and slow down the request.

Business scene
In many business scenarios, if you are not careful, there will be a large number of cache invalidations, which will lead to high pressure on the system DB and slow requests. For example, the same batch of train tickets and plane tickets will be loaded into the cache at one time when they can be sold. If the cache is written, the expiration time is based on the preset expiration value. After the expiration time expires, the system will be invalid due to the cache. There is a slowdown problem. For many businesses, when a new IDC is deployed or a new business goes online, the cache will be preheated, and a large amount of hot data will be loaded at one time.

solution
For the problem of batch key cache invalidation, since the reason is the preset fixed expiration time, the solution also starts from here. When designing the expiration time of the cache, use the formula: expiration time = baes time + random time. That is, when the same business data is written to the cache, a random expiration time is added on top of the basic expiration time, so that the data will slowly expire in the future, so as to avoid all expiration in an instant, which will cause excessive pressure on the DB, as shown in the following figure. .