Cache usage

  When the cache is used in conjunction with the database , The general use process is as follows ： 

One 、 Cache breakdown ：

        It refers to a... In the cache key Cache of is very hot , Constantly carrying big concurrency , There are many requests for users at a certain time , But no data was fetched from the cache （ For example, cache failure ）, Only go to the database to check the data , Causes the database pressure to increase instantaneously , It's like cutting a hole in a barrier . The solution is ：

1、 Lock ：

① Distributed lock ：

        Using distributed locks , Guarantee for each key At the same time, there is only one thread to query the back-end database , Other threads do not have access to distributed locks , So just wait . In this way, the pressure of high concurrency is transferred to distributed locks , So the test of distributed locks is great .

② Local lock ：

        Through the local lock , Restrict only one thread to query data in the database , Other threads just wait , Wait for the previous thread to query the data before accessing the cache . However, this method can only limit the local service node to only one thread to query in the database , If the service has multiple nodes , There will also be threads on other nodes to query the database , That is to say, the problem of cache concurrency is not completely solved when there are a large number of nodes .

2、 Soft expiration ：

        It refers to setting the expiration time for the data in the cache , But do not use the expiration time provided by the cache service , Instead, the business layer stores expiration time information in the data , It is up to the business process to determine whether the cache is expired and update it . When it is found that the data is about to expire , Extend the aging of the cache , The program can send a thread to get the latest data in the database , Other threads see that the expiration time is extended , Will continue to use the old data in the cache , After the dispatched thread obtains the latest data and updates the cache, it can access the new data in the cache . You can also periodically read the database data and update it to the cache through a scheduled task , In this way, the application layer does not need to care about cache concurrency .

Two 、 Cache penetration ：

        There is no data to be queried in the cache or database , And users are constantly requesting , Each request must penetrate to the back-end database system for query , Put too much pressure on the database , Even the database service is crushed . The solution is ：

       1、 If you use the same... Every time key The query , And every time key Does not exist in cache . You can put the key Set the value of to null and put it in the cache , Avoid caching through query databases ;

       2、 If you use different... Each time key The query , these key Does not exist in the cache . It can be done to key check , Limit it to the extent that it exists in the cache , A direct rejection that is not within its scope .

3、 ... and 、 Cache avalanche ：

        It means that the cache server is restarted or a lot of different key The cache of values expires in a certain period of time . This causes the back-end database to be under the pressure of transient load increase , Even crushing the database . The solution is ：

       1、 For different key Use different expiration times , Even for the same data 、 Different requests use different expiration times . for example , We need to cache user data , Different cache expiration times will be set for each user's data , You can define a base time , hypothesis 10 second , Then add a random number within two seconds , The expiration date is 10～12 second , Will avoid cache avalanches ;

       2、 If the cache database is a distributed deployment , Distribute the hot data evenly among different cache databases ;

       3、 Set hotspot data never to expire ;

Four 、 Concurrency issues ：
         When one key expires , If you visit this key The number of requests is large , Multiple requests discover cache expiration at the same time , Therefore, multiple requests will access the database at the same time to query the data , And write back to the cache , This will increase the load on applications and databases , Performance degradation , It may even cause the database to be crushed .

         In theory , Set the expiration time for the cache , Is a solution that guarantees ultimate consistency . Because the expiration time is set for the cached data , All cached data is subject to the database , Just do your best to change the cache . That is to say, the database is updated successfully , Even if the cache update fails , As long as the cache expiration time is reached , The subsequent read request thread will naturally read the new value from the database and update the cache , Although the immediacy of data is sacrificed, the consistency of cache and database is improved , However, setting the cache expiration time will lead to cache breakdown 、 The problem of penetration and even avalanche .

         Sum up , If you do not set the cache expiration time , Cache breakdown 、 The problem of penetration and even avalanche has been solved . But when modifying data , You must ensure that both the cache and the database can be successfully modified . But in the case of high concurrency , It may cause inconsistency between the modified cache and database data . Data changes include ： increase 、 Change 、 Delete , Add and modify （ Whether it is to operate the cache first , Or operate the database first ） after , If the cache and database data are inconsistent （ Whether it is caused by high concurrency , Or the system problem ） Can be re requested until the cache and database data are consistent . But in the delete operation （ Logical deletion is not considered , Because both the cache and the database are set , Just like modification, the request can be re initiated until the cache and database data are consistent ） when , Suppose there is A、B Two threads ,A To clear data ,B And other threads' high concurrency requests to query data , Expect to clear the cache and specified data in the database , The following situations will occur ：

1、A The operation sequence is to clear the cache first , Then delete the database ：

              1> In the case of a single database , If the order of execution is ：

                     ① A： Clear cache

                     ② B： Look up data from cache , We found no data

                     ③ B： Look up the data from the database , Get data data

                     ④ B： take data Write to cache

                     ⑤ A： Delete data from the database data

              2> When the database is a read-write separated database cluster , If the order of execution is ：

                     ① A： Clear cache

                     ② A： Delete the data from the master database

                     ③ B： Look up data from cache , We found no data

                     ④ B： Look up data from the database , The master-slave synchronization has not been completed yet , So get the data data

                     ⑤ B： take data Write to cache

                     ⑥ A： Complete master-slave synchronization , Delete data from library

        In both cases , There is no data in the database , But there are still... In the cache data, Because the cache does not set an expiration time , The requesting thread of the query will look up the cache to get the data every time data, In fact, this data has been deleted , The cache and database data are inconsistent . What to do to avoid this ？ That's it A The thread adopts the double deletion strategy , That is to say B The thread deletes data from the database and then deletes the cache .

        We only consider abnormal situations , What if the second cache deletion fails ？ If there is no special treatment for this situation , There is no such data in the database , But there is still this data in the cache , At this time, we don't know which data in the cache to delete but failed to delete （ Because the data in the database has been physically deleted , Corresponding cached key The value cannot be known ）.

        So , We should decide whether to rollback the database deletion based on whether the cached data has been successfully deleted . in addition , Design the database for logical deletion , And cached key Values can generate fixed values from the database data content , In this way, even if the cache deletion is unsuccessful , It can also calculate the cached data from the data in the database key Value for manual deletion . You can also delete the cache key Values are stored in the database in advance , If the cache is deleted successfully, this record will be cleared , Otherwise, keep this record , According to these key Value to clear the cache , Or refer to the situation 2【 I'm going to modify the database , Then clear the cache 】.

2、A The operation sequence is to delete the database first , Then clear the cache ：

        Because the cache does not set the expiration time , And you don't clear the cache first , So there is always data in the cache , So it doesn't trigger B The behavior of a thread looking up data from the database and setting it to the cache , There is no inconsistency between cache and database data , Unless the database data is deleted successfully , However, the cache and database data are inconsistent due to the failure of clearing the cache . Here and now 1 The double deletion policy in the same way that the cache deletion fails for the second time , Some special remedial measures are also needed .