REVIEW
Use Redis Redis cache will inevitably encounter penetration breakdown cache, cache avalanche, Hot Key issues.
First, we use Redis of logic is this
|
Cache penetration
It is for the data in the database and cache are not. Scene: When a client initiates a query, the cache will not have to check the library, the library does not, it will return an error message to the client. This is no problem, it seems logical to be perfect, but there is a loophole here that no matter what kind of Key over the investigation, we have to accept its request, which may be caught hackers, launched a large number of requests, and Key are not in our system, the library can not find the corresponding value, such Key called illegal Key. So when a large number of such requests are not coming will not hit Redis, and then will hit the DB, DB when the instantaneous received so many connections, DB is likely to barely hang. This is the existence of a hidden flaw, a hacker or a malicious attacker will seize on this attack your system and make your system down.
The actual development must take this into account, you can add a layer of filtering at the system level, the system is considered to be a key illegal interception, returned directly to the client an error message. Specifically how to add this layer of filtering, which is illegal Key should be based on actual business logic, just to give Solution.
Cache breakdown
But there is no database for some data cache. The scene is, when Key fails, if the instant sudden influx of a large number of requests, with a Key to the request, these requests are not hit Redis, will request to DB, the database resulting in excessive pressure, even could not carry, hang up.
The solution to the problem is this:
1, a hot Key, Key automatically detect hot spots, the hot Key expiration time to increase or to never expire, or set to a logical never expires, the specific setting method will be said.
2, plus mutex. When they find no hits Redis, to check the database when performing an update on the operation of the cache lock, the lock who is who gets to update, and then get a start if there is a cache returns received after the lock, not on the investigation and then update the database. (Double check)
Cache avalanche
Key refers to a large number of simultaneous failure of these requests will hit the Key of DB, the database will also lead to excessive pressure or even hang.
The solution to this problem is to allow time to failure Key's spread out, you can add a random value in a unified time to failure, or to use more sophisticated algorithms dispersed expiration time.
Hot Key issues
For hot data, we can set the expiration time great hot Key, or never expire on logic. What does it mean?
His point is that if we set the hot data expiration time of 24 hours, then we can use sniffers to monitor this hot data, when it is detected it is about to expire, since asynchronous thread to update the hotspot data. Logically never expire can achieve results.
In addition, we have a mechanism to automatically detect hot data. That there is a monitoring platform to monitor the number of requests for each key a certain time period, the number of expired, check the number of libraries, to analyze the key data is not hot, when it reaches a certain threshold will be key to upgrade to a hot key, then go hot logical data.
Here are just ideas, not repeat them how to achieve specific. If there is a better way, welcome message exchange.