Cache avalanche
For the system A, the peak period per day, assuming the request 5000, the peak may have been cached Kangzhu 4000 requests per second, but the overall cache accident machine downtime. Cache hung up, then one second off the 5000 request for all database, which inevitably could not carry, it will be reported at the police, then hung up. At this point, if there is no special program adopted to deal with this fault, DBA was in a hurry to restart the database, but the database has been a new flow rate immediately to the killing. This is the cache avalanche.
Avalanche in advance what the cache after the solution is as follows.
- Beforehand: redis availability, master-slave + Sentinel, redis cluster, avoiding total collapse.
- Things in: ehcache local cache + hystrix limiting & downgrade, MySQL avoid being killed.
- Afterwards: redis persistent, once restarted, the data is automatically loaded from disk, rapid recovery of cached data.
The user sends a request, the system A receives the request, will check the local cache ehcache, then check if not found redis. If ehcache and redis are not, then check the database, will result in the database, and write ehcache redis in.
Limiting component, you can set requests per second, the number of components through the remainder of the request does not pass, how do? Go downgrade! You can return some default value, or Tips, or blank values.
benefit:
- Database will never die, limiting the number of components to ensure that only requests per second pass.
- As long as the database die, that is to say, for the user, request 2/5 it is can be handled.
- 2/5 as long as there is a request can be processed, it means that your system is not dead, for users, probably a few clicks brush out the page, but several times more, you can brush it once.
Cache penetration
For System A, assuming one second request 5000, the results of which 4000 requests issued by a malicious hacker attacks. That 4000 issue of hacker attacks, cache finding out, every time you go to the database search, can not find out. For chestnuts. Database id starting from 1, and the results sent me the request id hackers are all negative. In this case, the cache will not be requested every time ", as the cache to nothing", query the database directly. This malicious attacks cache scenario will penetrate directly to the database to the dead.
Solution is very simple, as long as every time the system A is not found from the database, write caching to go to a null value, for example set -999 UNKNOWN. Then set an expiration time, this is the case, the next time the same key to access before a cache miss, you can take data directly from the cache.
Cache breakdown
Cache breakdown, a key that is very hot, very frequently accessed, in the case of a centralized high concurrent access, and when this key moment in the failure of the large number of requests to the breakdown of the cache, direct database requests, like in a barrier on the drilling of a hole.
Solution is simple, hot data can be set to never expire; or redis or zookeeper achieve mutex, after the first request to complete construction of the cache waiting on, and then release the lock, then other requests to access the data through the key.