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.
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.
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.
Solutions different scenarios as follows:
- If the cached data is not updated basic happen, you can try the hot data set to never expire.
- If cached data is not frequently updated, and the case where the cache flush the whole process less time consuming, may be employed based distributed mutual exclusion lock redis, zookeeper a distributed middleware, or local mutex to ensure that only a small the request can request the database and rebuild the cache, then the rest of the threads in the lock release access to the new cache.
- If the cached data is updated frequently or cache refresh process takes longer under the circumstances, you can use regular thread initiative to rebuild the cache before the cache expires or cache expiration time delay to ensure that all requests can have access to the corresponding cache.
