One , Cache processing flow

      Front desk request , The background fetches data from the cache first , Get the direct return result , If not, it will be retrieved from the database , Database fetches update cache , And return the result , We didn't get the database either , That returns the null result directly .



Two , Cache penetration

        describe :

  Cache penetration refers to data that is not in the cache or database , And users keep making requests , If initiated as id by “-1” Or id For very large non-existent data . The user is likely to be the attacker , Attacks can lead to excessive database pressure .

      Solution :

* Add verification to interface layer , Such as user authentication verification ,id Do basic verification ,id<=0 Direct interception of ;
Data not fetched from cache , It is not retrieved from the database , At this time, you can also key-value To write as key-null, The effective time of cache can be set as short as possible , as 30 second ( If the setting is too long, it can not be used under normal conditions ). The same user can prevent repeated attacks id Violent attacks

Three , Buffer breakdown

      describe :

Cache breakdown refers to the data not in the cache but in the database ( Generally, the cache time is expired ), At this time, there are many concurrent users , At the same time, no data was read from the read cache , At the same time go to the database to get data , Causes the database pressure to increase instantaneously , Cause too much pressure

      Solution :

* Set hotspot data to never expire .
* Add mutex lock , The mutex reference code is as follows :


          explain :

          1) Data in cache , Go directly to the above code 13 The result is returned after the line

 2) There is no data in the cache , The first 1 Incoming threads , Get the lock and fetch the data from the database , Before you release the lock , Other threads entering in parallel will wait 100ms, Then cache the data again . In this way, we can prevent repeated data fetching from the database , Repeatedly updating data to the cache .

3) This is, of course, a simplification , In theory, if we can key It would be better to lock the value , It's threads A Get from database key1 Does not interfere with threads B take key2 Data for , The above code obviously can't do this .


Four , Cache avalanche

      describe :

      Cache avalanche refers to a large number of data in the cache to the expiration time , The amount of query data is huge , It causes too much pressure on the database down machine . Unlike cache breakdown ,       
Cache breakdown refers to concurrent query of the same data , Cache avalanche means that different data are out of date , A lot of data can't be found, so check the database .

      Solution :

* The expiration time of cache data is set randomly , Prevent a large number of data expiration at the same time .
* If the cache database is a distributed deployment , The hot data is evenly distributed in different cache databases .
* Set hotspot data to never expire .